Eric Lee / smarc-uboot

Download as
Browse Code ยป

Commit a70e2aceeb273c9725c916019c24fecd398d9d97

Authored by Bin Meng
Committed by Tom Rini
1 parent e3b800a117
Exists in smarc_8mq_lf_v2020.04 and in 9 other branches 8qm-imx_v2020.04_5.4.70_2.3.0, emb_lf_v2022.04, pitx_8mp_lf_v2020.04, smarc-8m-android-10.0.0_2.6.0, smarc-8m-android-11.0.0_2.0.0, smarc-8mp-android-11.0.0_2.0.0, smarc_8mm-imx_v2020.04_5.4.24_2.1.0, smarc_8mp_lf_v2020.04, smarc_8mq-imx_v2020.04_5.4.24_2.1.0

doc: arch: Convert README.x86 to reST 

Convert plain text documentation to reStructuredText format and add
it to Sphinx TOC tree. No essential content change.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Showing 3 changed files with 729 additions and 722 deletions Side-by-side Diff

doc/README.x86
View file @ a70e2ac
1   -# SPDX-License-Identifier: GPL-2.0+
2   -#
3   -# Copyright (C) 2014, Simon Glass <sjg@chromium.org>
4   -# Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com>
5   -
6   -U-Boot on x86
7   -=============
8   -
9   -This document describes the information about U-Boot running on x86 targets,
10   -including supported boards, build instructions, todo list, etc.
11   -
12   -Status
13   -------
14   -U-Boot supports running as a coreboot [1] payload on x86. So far only Link
15   -(Chromebook Pixel) and QEMU [2] x86 targets have been tested, but it should
16   -work with minimal adjustments on other x86 boards since coreboot deals with
17   -most of the low-level details.
18   -
19   -U-Boot is a main bootloader on Intel Edison board.
20   -
21   -U-Boot also supports booting directly from x86 reset vector, without coreboot.
22   -In this case, known as bare mode, from the fact that it runs on the
23   -'bare metal', U-Boot acts like a BIOS replacement. The following platforms
24   -are supported:
25   -
26   - - Bayley Bay CRB
27   - - Cherry Hill CRB
28   - - Congatec QEVAL 2.0 & conga-QA3/E3845
29   - - Cougar Canyon 2 CRB
30   - - Crown Bay CRB
31   - - Galileo
32   - - Link (Chromebook Pixel)
33   - - Minnowboard MAX
34   - - Samus (Chromebook Pixel 2015)
35   - - QEMU x86 (32-bit & 64-bit)
36   -
37   -As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
38   -Linux kernel as part of a FIT image. It also supports a compressed zImage.
39   -U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks
40   -for more details.
41   -
42   -Build Instructions for U-Boot as BIOS replacement (bare mode)
43   --------------------------------------------------------------
44   -Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a
45   -little bit tricky, as generally it requires several binary blobs which are not
46   -shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is
47   -not turned on by default in the U-Boot source tree. Firstly, you need turn it
48   -on by enabling the ROM build either via an environment variable
49   -
50   - $ export BUILD_ROM=y
51   -
52   -or via configuration
53   -
54   - CONFIG_BUILD_ROM=y
55   -
56   -Both tell the Makefile to build u-boot.rom as a target.
57   -
58   ----
59   -
60   -CPU Microcode
61   --------------
62   -Modern CPUs usually require a special bit stream called microcode [8] to be
63   -loaded on the processor after power up in order to function properly. U-Boot
64   -has already integrated these as hex dumps in the source tree.
65   -
66   -SMP Support
67   ------------
68   -On a multicore system, U-Boot is executed on the bootstrap processor (BSP).
69   -Additional application processors (AP) can be brought up by U-Boot. In order to
70   -have an SMP kernel to discover all of the available processors, U-Boot needs to
71   -prepare configuration tables which contain the multi-CPUs information before
72   -loading the OS kernel. Currently U-Boot supports generating two types of tables
73   -for SMP, called Simple Firmware Interface (SFI) [9] and Multi-Processor (MP)
74   -[10] tables. The writing of these two tables are controlled by two Kconfig
75   -options GENERATE_SFI_TABLE and GENERATE_MP_TABLE.
76   -
77   -Driver Model
78   -------------
79   -x86 has been converted to use driver model for serial, GPIO, SPI, SPI flash,
80   -keyboard, real-time clock, USB. Video is in progress.
81   -
82   -Device Tree
83   ------------
84   -x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to
85   -be turned on. Not every device on the board is configured via device tree, but
86   -more and more devices will be added as time goes by. Check out the directory
87   -arch/x86/dts/ for these device tree source files.
88   -
89   -Useful Commands
90   ----------------
91   -In keeping with the U-Boot philosophy of providing functions to check and
92   -adjust internal settings, there are several x86-specific commands that may be
93   -useful:
94   -
95   -fsp - Display information about Intel Firmware Support Package (FSP).
96   - This is only available on platforms which use FSP, mostly Atom.
97   -iod - Display I/O memory
98   -iow - Write I/O memory
99   -mtrr - List and set the Memory Type Range Registers (MTRR). These are used to
100   - tell the CPU whether memory is cacheable and if so the cache write
101   - mode to use. U-Boot sets up some reasonable values but you can
102   - adjust then with this command.
103   -
104   -Booting Ubuntu
105   ---------------
106   -As an example of how to set up your boot flow with U-Boot, here are
107   -instructions for starting Ubuntu from U-Boot. These instructions have been
108   -tested on Minnowboard MAX with a SATA drive but are equally applicable on
109   -other platforms and other media. There are really only four steps and it's a
110   -very simple script, but a more detailed explanation is provided here for
111   -completeness.
112   -
113   -Note: It is possible to set up U-Boot to boot automatically using syslinux.
114   -It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the
115   -GUID. If you figure these out, please post patches to this README.
116   -
117   -Firstly, you will need Ubuntu installed on an available disk. It should be
118   -possible to make U-Boot start a USB start-up disk but for now let's assume
119   -that you used another boot loader to install Ubuntu.
120   -
121   -Use the U-Boot command line to find the UUID of the partition you want to
122   -boot. For example our disk is SCSI device 0:
123   -
124   -=> part list scsi 0
125   -
126   -Partition Map for SCSI device 0 -- Partition Type: EFI
127   -
128   - Part Start LBA End LBA Name
129   - Attributes
130   - Type GUID
131   - Partition GUID
132   - 1 0x00000800 0x001007ff ""
133   - attrs: 0x0000000000000000
134   - type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
135   - guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c
136   - 2 0x00100800 0x037d8fff ""
137   - attrs: 0x0000000000000000
138   - type: 0fc63daf-8483-4772-8e79-3d69d8477de4
139   - guid: 965c59ee-1822-4326-90d2-b02446050059
140   - 3 0x037d9000 0x03ba27ff ""
141   - attrs: 0x0000000000000000
142   - type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
143   - guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17
144   - =>
145   -
146   -This shows that your SCSI disk has three partitions. The really long hex
147   -strings are called Globally Unique Identifiers (GUIDs). You can look up the
148   -'type' ones here [11]. On this disk the first partition is for EFI and is in
149   -VFAT format (DOS/Windows):
150   -
151   - => fatls scsi 0:1
152   - efi/
153   -
154   - 0 file(s), 1 dir(s)
155   -
156   -
157   -Partition 2 is 'Linux filesystem data' so that will be our root disk. It is
158   -in ext2 format:
159   -
160   - => ext2ls scsi 0:2
161   - <DIR> 4096 .
162   - <DIR> 4096 ..
163   - <DIR> 16384 lost+found
164   - <DIR> 4096 boot
165   - <DIR> 12288 etc
166   - <DIR> 4096 media
167   - <DIR> 4096 bin
168   - <DIR> 4096 dev
169   - <DIR> 4096 home
170   - <DIR> 4096 lib
171   - <DIR> 4096 lib64
172   - <DIR> 4096 mnt
173   - <DIR> 4096 opt
174   - <DIR> 4096 proc
175   - <DIR> 4096 root
176   - <DIR> 4096 run
177   - <DIR> 12288 sbin
178   - <DIR> 4096 srv
179   - <DIR> 4096 sys
180   - <DIR> 4096 tmp
181   - <DIR> 4096 usr
182   - <DIR> 4096 var
183   - <SYM> 33 initrd.img
184   - <SYM> 30 vmlinuz
185   - <DIR> 4096 cdrom
186   - <SYM> 33 initrd.img.old
187   - =>
188   -
189   -and if you look in the /boot directory you will see the kernel:
190   -
191   - => ext2ls scsi 0:2 /boot
192   - <DIR> 4096 .
193   - <DIR> 4096 ..
194   - <DIR> 4096 efi
195   - <DIR> 4096 grub
196   - 3381262 System.map-3.13.0-32-generic
197   - 1162712 abi-3.13.0-32-generic
198   - 165611 config-3.13.0-32-generic
199   - 176500 memtest86+.bin
200   - 178176 memtest86+.elf
201   - 178680 memtest86+_multiboot.bin
202   - 5798112 vmlinuz-3.13.0-32-generic
203   - 165762 config-3.13.0-58-generic
204   - 1165129 abi-3.13.0-58-generic
205   - 5823136 vmlinuz-3.13.0-58-generic
206   - 19215259 initrd.img-3.13.0-58-generic
207   - 3391763 System.map-3.13.0-58-generic
208   - 5825048 vmlinuz-3.13.0-58-generic.efi.signed
209   - 28304443 initrd.img-3.13.0-32-generic
210   - =>
211   -
212   -The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of
213   -self-extracting compressed file mixed with some 'setup' configuration data.
214   -Despite its size (uncompressed it is >10MB) this only includes a basic set of
215   -device drivers, enough to boot on most hardware types.
216   -
217   -The 'initrd' files contain a RAM disk. This is something that can be loaded
218   -into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots
219   -of drivers for whatever hardware you might have. It is loaded before the
220   -real root disk is accessed.
221   -
222   -The numbers after the end of each file are the version. Here it is Linux
223   -version 3.13. You can find the source code for this in the Linux tree with
224   -the tag v3.13. The '.0' allows for additional Linux releases to fix problems,
225   -but normally this is not needed. The '-58' is used by Ubuntu. Each time they
226   -release a new kernel they increment this number. New Ubuntu versions might
227   -include kernel patches to fix reported bugs. Stable kernels can exist for
228   -some years so this number can get quite high.
229   -
230   -The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own
231   -secure boot mechanism - see [12] [13] and cannot read .efi files at present.
232   -
233   -To boot Ubuntu from U-Boot the steps are as follows:
234   -
235   -1. Set up the boot arguments. Use the GUID for the partition you want to
236   -boot:
237   -
238   - => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro
239   -
240   -Here root= tells Linux the location of its root disk. The disk is specified
241   -by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory'
242   -containing all the GUIDs Linux has found. When it starts up, there will be a
243   -file in that directory with this name in it. It is also possible to use a
244   -device name here, see later.
245   -
246   -2. Load the kernel. Since it is an ext2/4 filesystem we can do:
247   -
248   - => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic
249   -
250   -The address 30000000 is arbitrary, but there seem to be problems with using
251   -small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into
252   -the start of RAM (which is at 0 on x86).
253   -
254   -3. Load the ramdisk (to 64MB):
255   -
256   - => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic
257   -
258   -4. Start up the kernel. We need to know the size of the ramdisk, but can use
259   -a variable for that. U-Boot sets 'filesize' to the size of the last file it
260   -loaded.
261   -
262   - => zboot 03000000 0 04000000 ${filesize}
263   -
264   -Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is
265   -quite verbose when it boots a kernel. You should see these messages from
266   -U-Boot:
267   -
268   - Valid Boot Flag
269   - Setup Size = 0x00004400
270   - Magic signature found
271   - Using boot protocol version 2.0c
272   - Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015
273   - Building boot_params at 0x00090000
274   - Loading bzImage at address 100000 (5805728 bytes)
275   - Magic signature found
276   - Initial RAM disk at linear address 0x04000000, size 19215259 bytes
277   - Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro"
278   -
279   - Starting kernel ...
280   -
281   -U-Boot prints out some bootstage timing. This is more useful if you put the
282   -above commands into a script since then it will be faster.
283   -
284   - Timer summary in microseconds:
285   - Mark Elapsed Stage
286   - 0 0 reset
287   - 241,535 241,535 board_init_r
288   - 2,421,611 2,180,076 id=64
289   - 2,421,790 179 id=65
290   - 2,428,215 6,425 main_loop
291   - 48,860,584 46,432,369 start_kernel
292   -
293   - Accumulated time:
294   - 240,329 ahci
295   - 1,422,704 vesa display
296   -
297   -Now the kernel actually starts: (if you want to examine kernel boot up message
298   -on the serial console, append "console=ttyS0,115200" to the kernel command line)
299   -
300   - [ 0.000000] Initializing cgroup subsys cpuset
301   - [ 0.000000] Initializing cgroup subsys cpu
302   - [ 0.000000] Initializing cgroup subsys cpuacct
303   - [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22)
304   - [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200
305   -
306   -It continues for a long time. Along the way you will see it pick up your
307   -ramdisk:
308   -
309   - [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff]
310   -...
311   - [ 0.788540] Trying to unpack rootfs image as initramfs...
312   - [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000)
313   -...
314   -
315   -Later it actually starts using it:
316   -
317   - Begin: Running /scripts/local-premount ... done.
318   -
319   -You should also see your boot disk turn up:
320   -
321   - [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5
322   - [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
323   - [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0
324   - [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off
325   - [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
326   - [ 4.399535] sda: sda1 sda2 sda3
327   -
328   -Linux has found the three partitions (sda1-3). Mercifully it doesn't print out
329   -the GUIDs. In step 1 above we could have used:
330   -
331   - setenv bootargs root=/dev/sda2 ro
332   -
333   -instead of the GUID. However if you add another drive to your board the
334   -numbering may change whereas the GUIDs will not. So if your boot partition
335   -becomes sdb2, it will still boot. For embedded systems where you just want to
336   -boot the first disk, you have that option.
337   -
338   -The last thing you will see on the console is mention of plymouth (which
339   -displays the Ubuntu start-up screen) and a lot of 'Starting' messages:
340   -
341   - * Starting Mount filesystems on boot [ OK ]
342   -
343   -After a pause you should see a login screen on your display and you are done.
344   -
345   -If you want to put this in a script you can use something like this:
346   -
347   - setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro
348   - setenv boot zboot 03000000 0 04000000 \${filesize}
349   - setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot"
350   - saveenv
351   -
352   -The \ is to tell the shell not to evaluate ${filesize} as part of the setenv
353   -command.
354   -
355   -You can also bake this behaviour into your build by hard-coding the
356   -environment variables if you add this to minnowmax.h:
357   -
358   -#undef CONFIG_BOOTCOMMAND
359   -#define CONFIG_BOOTCOMMAND \
360   - "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \
361   - "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \
362   - "run boot"
363   -
364   -#undef CONFIG_EXTRA_ENV_SETTINGS
365   -#define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}"
366   -
367   -and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to:
368   -
369   -CONFIG_BOOTARGS="root=/dev/sda2 ro"
370   -
371   -Test with SeaBIOS
372   ------------------
373   -SeaBIOS [14] is an open source implementation of a 16-bit x86 BIOS. It can run
374   -in an emulator or natively on x86 hardware with the use of U-Boot. With its
375   -help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS.
376   -
377   -As U-Boot, we have to manually create a table where SeaBIOS gets various system
378   -information (eg: E820) from. The table unfortunately has to follow the coreboot
379   -table format as SeaBIOS currently supports booting as a coreboot payload.
380   -
381   -To support loading SeaBIOS, U-Boot should be built with CONFIG_SEABIOS on.
382   -Booting SeaBIOS is done via U-Boot's bootelf command, like below:
383   -
384   - => tftp bios.bin.elf;bootelf
385   - Using e1000#0 device
386   - TFTP from server 10.10.0.100; our IP address is 10.10.0.108
387   - ...
388   - Bytes transferred = 122124 (1dd0c hex)
389   - ## Starting application at 0x000ff06e ...
390   - SeaBIOS (version rel-1.9.0)
391   - ...
392   -
393   -bios.bin.elf is the SeaBIOS image built from SeaBIOS source tree.
394   -Make sure it is built as follows:
395   -
396   - $ make menuconfig
397   -
398   -Inside the "General Features" menu, select "Build for coreboot" as the
399   -"Build Target". Inside the "Debugging" menu, turn on "Serial port debugging"
400   -so that we can see something as soon as SeaBIOS boots. Leave other options
401   -as in their default state. Then,
402   -
403   - $ make
404   - ...
405   - Total size: 121888 Fixed: 66496 Free: 9184 (used 93.0% of 128KiB rom)
406   - Creating out/bios.bin.elf
407   -
408   -Currently this is tested on QEMU x86 target with U-Boot chain-loading SeaBIOS
409   -to install/boot a Windows XP OS (below for example command to install Windows).
410   -
411   - # Create a 10G disk.img as the virtual hard disk
412   - $ qemu-img create -f qcow2 disk.img 10G
413   -
414   - # Install a Windows XP OS from an ISO image 'winxp.iso'
415   - $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -cdrom winxp.iso -smp 2 -m 512
416   -
417   - # Boot a Windows XP OS installed on the virutal hard disk
418   - $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -smp 2 -m 512
419   -
420   -This is also tested on Intel Crown Bay board with a PCIe graphics card, booting
421   -SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally.
422   -
423   -If you are using Intel Integrated Graphics Device (IGD) as the primary display
424   -device on your board, SeaBIOS needs to be patched manually to get its VGA ROM
425   -loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM
426   -register, but IGD device does not have its VGA ROM mapped by this register.
427   -Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address
428   -which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below:
429   -
430   -diff --git a/src/optionroms.c b/src/optionroms.c
431   -index 65f7fe0..c7b6f5e 100644
432   ---- a/src/optionroms.c
433   -+++ b/src/optionroms.c
434   -@@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources)
435   - rom = deploy_romfile(file);
436   - else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga))
437   - rom = map_pcirom(pci);
438   -+ if (pci->bdf == pci_to_bdf(0, 2, 0))
439   -+ rom = (struct rom_header *)0xfff90000;
440   - if (! rom)
441   - // No ROM present.
442   - return;
443   -
444   -Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM
445   -is at 0xfff90000 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX.
446   -Change these two accordingly if this is not the case on your board.
447   -
448   -Development Flow
449   -----------------
450   -These notes are for those who want to port U-Boot to a new x86 platform.
451   -
452   -Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment.
453   -The Dediprog em100 can be used on Linux. The em100 tool is available here:
454   -
455   - http://review.coreboot.org/p/em100.git
456   -
457   -On Minnowboard Max the following command line can be used:
458   -
459   - sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r
460   -
461   -A suitable clip for connecting over the SPI flash chip is here:
462   -
463   - http://www.dediprog.com/pd/programmer-accessories/EM-TC-8
464   -
465   -This allows you to override the SPI flash contents for development purposes.
466   -Typically you can write to the em100 in around 1200ms, considerably faster
467   -than programming the real flash device each time. The only important
468   -limitation of the em100 is that it only supports SPI bus speeds up to 20MHz.
469   -This means that images must be set to boot with that speed. This is an
470   -Intel-specific feature - e.g. tools/ifttool has an option to set the SPI
471   -speed in the SPI descriptor region.
472   -
473   -If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly
474   -easy to fit it in. You can follow the Minnowboard Max implementation, for
475   -example. Hopefully you will just need to create new files similar to those
476   -in arch/x86/cpu/baytrail which provide Bay Trail support.
477   -
478   -If you are not using an FSP you have more freedom and more responsibility.
479   -The ivybridge support works this way, although it still uses a ROM for
480   -graphics and still has binary blobs containing Intel code. You should aim to
481   -support all important peripherals on your platform including video and storage.
482   -Use the device tree for configuration where possible.
483   -
484   -For the microcode you can create a suitable device tree file using the
485   -microcode tool:
486   -
487   - ./tools/microcode-tool -d microcode.dat -m <model> create
488   -
489   -or if you only have header files and not the full Intel microcode.dat database:
490   -
491   - ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \
492   - -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h \
493   - -m all create
494   -
495   -These are written to arch/x86/dts/microcode/ by default.
496   -
497   -Note that it is possible to just add the micrcode for your CPU if you know its
498   -model. U-Boot prints this information when it starts
499   -
500   - CPU: x86_64, vendor Intel, device 30673h
501   -
502   -so here we can use the M0130673322 file.
503   -
504   -If you platform can display POST codes on two little 7-segment displays on
505   -the board, then you can use post_code() calls from C or assembler to monitor
506   -boot progress. This can be good for debugging.
507   -
508   -If not, you can try to get serial working as early as possible. The early
509   -debug serial port may be useful here. See setup_internal_uart() for an example.
510   -
511   -During the U-Boot porting, one of the important steps is to write correct PIRQ
512   -routing information in the board device tree. Without it, device drivers in the
513   -Linux kernel won't function correctly due to interrupt is not working. Please
514   -refer to U-Boot doc [15] for the device tree bindings of Intel interrupt router.
515   -Here we have more details on the intel,pirq-routing property below.
516   -
517   - intel,pirq-routing = <
518   - PCI_BDF(0, 2, 0) INTA PIRQA
519   - ...
520   - >;
521   -
522   -As you see each entry has 3 cells. For the first one, we need describe all pci
523   -devices mounted on the board. For SoC devices, normally there is a chapter on
524   -the chipset datasheet which lists all the available PCI devices. For example on
525   -Bay Trail, this is chapter 4.3 (PCI configuration space). For the second one, we
526   -can get the interrupt pin either from datasheet or hardware via U-Boot shell.
527   -The reliable source is the hardware as sometimes chipset datasheet is not 100%
528   -up-to-date. Type 'pci header' plus the device's pci bus/device/function number
529   -from U-Boot shell below.
530   -
531   - => pci header 0.1e.1
532   - vendor ID = 0x8086
533   - device ID = 0x0f08
534   - ...
535   - interrupt line = 0x09
536   - interrupt pin = 0x04
537   - ...
538   -
539   -It shows this PCI device is using INTD pin as it reports 4 in the interrupt pin
540   -register. Repeat this until you get interrupt pins for all the devices. The last
541   -cell is the PIRQ line which a particular interrupt pin is mapped to. On Intel
542   -chipset, the power-up default mapping is INTA/B/C/D maps to PIRQA/B/C/D. This
543   -can be changed by registers in LPC bridge. So far Intel FSP does not touch those
544   -registers so we can write down the PIRQ according to the default mapping rule.
545   -
546   -Once we get the PIRQ routing information in the device tree, the interrupt
547   -allocation and assignment will be done by U-Boot automatically. Now you can
548   -enable CONFIG_GENERATE_PIRQ_TABLE for testing Linux kernel using i8259 PIC and
549   -CONFIG_GENERATE_MP_TABLE for testing Linux kernel using local APIC and I/O APIC.
550   -
551   -This script might be useful. If you feed it the output of 'pci long' from
552   -U-Boot then it will generate a device tree fragment with the interrupt
553   -configuration for each device (note it needs gawk 4.0.0):
554   -
555   - $ cat console_output |awk '/PCI/ {device=$4} /interrupt line/ {line=$4} \
556   - /interrupt pin/ {pin = $4; if (pin != "0x00" && pin != "0xff") \
557   - {patsplit(device, bdf, "[0-9a-f]+"); \
558   - printf "PCI_BDF(%d, %d, %d) INT%c PIRQ%c\n", strtonum("0x" bdf[1]), \
559   - strtonum("0x" bdf[2]), bdf[3], strtonum(pin) + 64, 64 + strtonum(pin)}}'
560   -
561   -Example output:
562   - PCI_BDF(0, 2, 0) INTA PIRQA
563   - PCI_BDF(0, 3, 0) INTA PIRQA
564   -...
565   -
566   -Porting Hints
567   --------------
568   -
569   -Quark-specific considerations:
570   -
571   -To port U-Boot to other boards based on the Intel Quark SoC, a few things need
572   -to be taken care of. The first important part is the Memory Reference Code (MRC)
573   -parameters. Quark MRC supports memory-down configuration only. All these MRC
574   -parameters are supplied via the board device tree. To get started, first copy
575   -the MRC section of arch/x86/dts/galileo.dts to your board's device tree, then
576   -change these values by consulting board manuals or your hardware vendor.
577   -Available MRC parameter values are listed in include/dt-bindings/mrc/quark.h.
578   -The other tricky part is with PCIe. Quark SoC integrates two PCIe root ports,
579   -but by default they are held in reset after power on. In U-Boot, PCIe
580   -initialization is properly handled as per Quark's firmware writer guide.
581   -In your board support codes, you need provide two routines to aid PCIe
582   -initialization, which are board_assert_perst() and board_deassert_perst().
583   -The two routines need implement a board-specific mechanism to assert/deassert
584   -PCIe PERST# pin. Care must be taken that in those routines that any APIs that
585   -may trigger PCI enumeration process are strictly forbidden, as any access to
586   -PCIe root port's configuration registers will cause system hang while it is
587   -held in reset. For more details, check how they are implemented by the Intel
588   -Galileo board support codes in board/intel/galileo/galileo.c.
589   -
590   -coreboot:
591   -
592   -See scripts/coreboot.sed which can assist with porting coreboot code into
593   -U-Boot drivers. It will not resolve all build errors, but will perform common
594   -transformations. Remember to add attribution to coreboot for new files added
595   -to U-Boot. This should go at the top of each file and list the coreboot
596   -filename where the code originated.
597   -
598   -Debugging ACPI issues with Windows:
599   -
600   -Windows might cache system information and only detect ACPI changes if you
601   -modify the ACPI table versions. So tweak them liberally when debugging ACPI
602   -issues with Windows.
603   -
604   -ACPI Support Status
605   --------------------
606   -Advanced Configuration and Power Interface (ACPI) [16] aims to establish
607   -industry-standard interfaces enabling OS-directed configuration, power
608   -management, and thermal management of mobile, desktop, and server platforms.
609   -
610   -Linux can boot without ACPI with "acpi=off" command line parameter, but
611   -with ACPI the kernel gains the capabilities to handle power management.
612   -For Windows, ACPI is a must-have firmware feature since Windows Vista.
613   -CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in
614   -U-Boot. This requires Intel ACPI compiler to be installed on your host to
615   -compile ACPI DSDT table written in ASL format to AML format. You can get
616   -the compiler via "apt-get install iasl" if you are on Ubuntu or download
617   -the source from [17] to compile one by yourself.
618   -
619   -Current ACPI support in U-Boot is basically complete. More optional features
620   -can be added in the future. The status as of today is:
621   -
622   - * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables.
623   - * Support one static DSDT table only, compiled by Intel ACPI compiler.
624   - * Support S0/S3/S4/S5, reboot and shutdown from OS.
625   - * Support booting a pre-installed Ubuntu distribution via 'zboot' command.
626   - * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with
627   - the help of SeaBIOS using legacy interface (non-UEFI mode).
628   - * Support installing and booting Windows 8.1/10 from U-Boot with the help
629   - of SeaBIOS using legacy interface (non-UEFI mode).
630   - * Support ACPI interrupts with SCI only.
631   -
632   -Features that are optional:
633   - * Dynamic AML bytecodes insertion at run-time. We may need this to support
634   - SSDT table generation and DSDT fix up.
635   - * SMI support. Since U-Boot is a modern bootloader, we don't want to bring
636   - those legacy stuff into U-Boot. ACPI spec allows a system that does not
637   - support SMI (a legacy-free system).
638   -
639   -ACPI was initially enabled on BayTrail based boards. Testing was done by booting
640   -a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and
641   -Windows 8.1/10 to a SATA drive and booting from there is also tested. Most
642   -devices seem to work correctly and the board can respond a reboot/shutdown
643   -command from the OS.
644   -
645   -For other platform boards, ACPI support status can be checked by examining their
646   -board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y.
647   -
648   -The S3 sleeping state is a low wake latency sleeping state defined by ACPI
649   -spec where all system context is lost except system memory. To test S3 resume
650   -with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will
651   -put the board to S3 state where the power is off. So when the power button is
652   -pressed again, U-Boot runs as it does in cold boot and detects the sleeping
653   -state via ACPI register to see if it is S3, if yes it means we are waking up.
654   -U-Boot is responsible for restoring the machine state as it is before sleep.
655   -When everything is done, U-Boot finds out the wakeup vector provided by OSes
656   -and jump there. To determine whether ACPI S3 resume is supported, check to
657   -see if CONFIG_HAVE_ACPI_RESUME is set for that specific board.
658   -
659   -Note for testing S3 resume with Windows, correct graphics driver must be
660   -installed for your platform, otherwise you won't find "Sleep" option in
661   -the "Power" submenu from the Windows start menu.
662   -
663   -EFI Support
664   ------------
665   -U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
666   -This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
667   -UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
668   -The CONFIG_EFI_LOADER option, where U-Boot provides an EFI environment to
669   -the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
670   -services) is supported too. For example, we can even use 'bootefi' command
671   -to load a 'u-boot-payload.efi', see below test logs on QEMU.
672   -
673   - => load ide 0 3000000 u-boot-payload.efi
674   - 489787 bytes read in 138 ms (3.4 MiB/s)
675   - => bootefi 3000000
676   - Scanning disk ide.blk#0...
677   - Found 2 disks
678   - WARNING: booting without device tree
679   - ## Starting EFI application at 03000000 ...
680   - U-Boot EFI Payload
681   -
682   -
683   - U-Boot 2018.07-rc2 (Jun 23 2018 - 17:12:58 +0800)
684   -
685   - CPU: x86_64, vendor AMD, device 663h
686   - DRAM: 2 GiB
687   - MMC:
688   - Video: 1024x768x32
689   - Model: EFI x86 Payload
690   - Net: e1000: 52:54:00:12:34:56
691   -
692   - Warning: e1000#0 using MAC address from ROM
693   - eth0: e1000#0
694   - No controllers found
695   - Hit any key to stop autoboot: 0
696   -
697   -See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.
698   -
699   -TODO List
700   ----------
701   -- Audio
702   -- Chrome OS verified boot
703   -
704   -References
705   -----------
706   -[1] http://www.coreboot.org
707   -[2] http://www.qemu.org
708   -[3] http://www.coreboot.org/~stepan/pci8086,0166.rom
709   -[4] http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-platforms/atom-e660-eg20t-development-kit.html
710   -[5] http://www.intel.com/fsp
711   -[6] http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/e6xx-35-b1-cmc22211.html
712   -[7] http://www.ami.com/products/bios-uefi-tools-and-utilities/bios-uefi-utilities/
713   -[8] http://en.wikipedia.org/wiki/Microcode
714   -[9] http://simplefirmware.org
715   -[10] http://www.intel.com/design/archives/processors/pro/docs/242016.htm
716   -[11] https://en.wikipedia.org/wiki/GUID_Partition_Table
717   -[12] http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf
718   -[13] http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf
719   -[14] http://www.seabios.org/SeaBIOS
720   -[15] doc/device-tree-bindings/misc/intel,irq-router.txt
721   -[16] http://www.acpi.info
722   -[17] https://www.acpica.org/downloads
... ... @@ -7,4 +7,5 @@
7 7 :maxdepth: 2
8 8  
9 9 mips
  10 + x86
  1 +.. SPDX-License-Identifier: GPL-2.0+
  2 +.. Copyright (C) 2014, Simon Glass <sjg@chromium.org>
  3 +.. Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com>
  4 +
  5 +x86
  6 +===
  7 +
  8 +This document describes the information about U-Boot running on x86 targets,
  9 +including supported boards, build instructions, todo list, etc.
  10 +
  11 +Status
  12 +------
  13 +U-Boot supports running as a `coreboot`_ payload on x86. So far only Link
  14 +(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should
  15 +work with minimal adjustments on other x86 boards since coreboot deals with
  16 +most of the low-level details.
  17 +
  18 +U-Boot is a main bootloader on Intel Edison board.
  19 +
  20 +U-Boot also supports booting directly from x86 reset vector, without coreboot.
  21 +In this case, known as bare mode, from the fact that it runs on the
  22 +'bare metal', U-Boot acts like a BIOS replacement. The following platforms
  23 +are supported:
  24 +
  25 + - Bayley Bay CRB
  26 + - Cherry Hill CRB
  27 + - Congatec QEVAL 2.0 & conga-QA3/E3845
  28 + - Cougar Canyon 2 CRB
  29 + - Crown Bay CRB
  30 + - Galileo
  31 + - Link (Chromebook Pixel)
  32 + - Minnowboard MAX
  33 + - Samus (Chromebook Pixel 2015)
  34 + - QEMU x86 (32-bit & 64-bit)
  35 +
  36 +As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
  37 +Linux kernel as part of a FIT image. It also supports a compressed zImage.
  38 +U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks
  39 +for more details.
  40 +
  41 +Build Instructions for U-Boot as BIOS replacement (bare mode)
  42 +-------------------------------------------------------------
  43 +Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a
  44 +little bit tricky, as generally it requires several binary blobs which are not
  45 +shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is
  46 +not turned on by default in the U-Boot source tree. Firstly, you need turn it
  47 +on by enabling the ROM build either via an environment variable::
  48 +
  49 + $ export BUILD_ROM=y
  50 +
  51 +or via configuration::
  52 +
  53 + CONFIG_BUILD_ROM=y
  54 +
  55 +Both tell the Makefile to build u-boot.rom as a target.
  56 +
  57 +CPU Microcode
  58 +-------------
  59 +Modern CPUs usually require a special bit stream called `microcode`_ to be
  60 +loaded on the processor after power up in order to function properly. U-Boot
  61 +has already integrated these as hex dumps in the source tree.
  62 +
  63 +SMP Support
  64 +-----------
  65 +On a multicore system, U-Boot is executed on the bootstrap processor (BSP).
  66 +Additional application processors (AP) can be brought up by U-Boot. In order to
  67 +have an SMP kernel to discover all of the available processors, U-Boot needs to
  68 +prepare configuration tables which contain the multi-CPUs information before
  69 +loading the OS kernel. Currently U-Boot supports generating two types of tables
  70 +for SMP, called Simple Firmware Interface (`SFI`_) and Multi-Processor (`MP`_)
  71 +tables. The writing of these two tables are controlled by two Kconfig
  72 +options GENERATE_SFI_TABLE and GENERATE_MP_TABLE.
  73 +
  74 +Driver Model
  75 +------------
  76 +x86 has been converted to use driver model for serial, GPIO, SPI, SPI flash,
  77 +keyboard, real-time clock, USB. Video is in progress.
  78 +
  79 +Device Tree
  80 +-----------
  81 +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to
  82 +be turned on. Not every device on the board is configured via device tree, but
  83 +more and more devices will be added as time goes by. Check out the directory
  84 +arch/x86/dts/ for these device tree source files.
  85 +
  86 +Useful Commands
  87 +---------------
  88 +In keeping with the U-Boot philosophy of providing functions to check and
  89 +adjust internal settings, there are several x86-specific commands that may be
  90 +useful:
  91 +
  92 +fsp
  93 + Display information about Intel Firmware Support Package (FSP).
  94 + This is only available on platforms which use FSP, mostly Atom.
  95 +iod
  96 + Display I/O memory
  97 +iow
  98 + Write I/O memory
  99 +mtrr
  100 + List and set the Memory Type Range Registers (MTRR). These are used to
  101 + tell the CPU whether memory is cacheable and if so the cache write
  102 + mode to use. U-Boot sets up some reasonable values but you can
  103 + adjust then with this command.
  104 +
  105 +Booting Ubuntu
  106 +--------------
  107 +As an example of how to set up your boot flow with U-Boot, here are
  108 +instructions for starting Ubuntu from U-Boot. These instructions have been
  109 +tested on Minnowboard MAX with a SATA drive but are equally applicable on
  110 +other platforms and other media. There are really only four steps and it's a
  111 +very simple script, but a more detailed explanation is provided here for
  112 +completeness.
  113 +
  114 +Note: It is possible to set up U-Boot to boot automatically using syslinux.
  115 +It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the
  116 +GUID. If you figure these out, please post patches to this README.
  117 +
  118 +Firstly, you will need Ubuntu installed on an available disk. It should be
  119 +possible to make U-Boot start a USB start-up disk but for now let's assume
  120 +that you used another boot loader to install Ubuntu.
  121 +
  122 +Use the U-Boot command line to find the UUID of the partition you want to
  123 +boot. For example our disk is SCSI device 0::
  124 +
  125 + => part list scsi 0
  126 +
  127 + Partition Map for SCSI device 0 -- Partition Type: EFI
  128 +
  129 + Part Start LBA End LBA Name
  130 + Attributes
  131 + Type GUID
  132 + Partition GUID
  133 + 1 0x00000800 0x001007ff ""
  134 + attrs: 0x0000000000000000
  135 + type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
  136 + guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c
  137 + 2 0x00100800 0x037d8fff ""
  138 + attrs: 0x0000000000000000
  139 + type: 0fc63daf-8483-4772-8e79-3d69d8477de4
  140 + guid: 965c59ee-1822-4326-90d2-b02446050059
  141 + 3 0x037d9000 0x03ba27ff ""
  142 + attrs: 0x0000000000000000
  143 + type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
  144 + guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17
  145 + =>
  146 +
  147 +This shows that your SCSI disk has three partitions. The really long hex
  148 +strings are called Globally Unique Identifiers (GUIDs). You can look up the
  149 +'type' ones `here`_. On this disk the first partition is for EFI and is in
  150 +VFAT format (DOS/Windows)::
  151 +
  152 + => fatls scsi 0:1
  153 + efi/
  154 +
  155 + 0 file(s), 1 dir(s)
  156 +
  157 +
  158 +Partition 2 is 'Linux filesystem data' so that will be our root disk. It is
  159 +in ext2 format::
  160 +
  161 + => ext2ls scsi 0:2
  162 + <DIR> 4096 .
  163 + <DIR> 4096 ..
  164 + <DIR> 16384 lost+found
  165 + <DIR> 4096 boot
  166 + <DIR> 12288 etc
  167 + <DIR> 4096 media
  168 + <DIR> 4096 bin
  169 + <DIR> 4096 dev
  170 + <DIR> 4096 home
  171 + <DIR> 4096 lib
  172 + <DIR> 4096 lib64
  173 + <DIR> 4096 mnt
  174 + <DIR> 4096 opt
  175 + <DIR> 4096 proc
  176 + <DIR> 4096 root
  177 + <DIR> 4096 run
  178 + <DIR> 12288 sbin
  179 + <DIR> 4096 srv
  180 + <DIR> 4096 sys
  181 + <DIR> 4096 tmp
  182 + <DIR> 4096 usr
  183 + <DIR> 4096 var
  184 + <SYM> 33 initrd.img
  185 + <SYM> 30 vmlinuz
  186 + <DIR> 4096 cdrom
  187 + <SYM> 33 initrd.img.old
  188 + =>
  189 +
  190 +and if you look in the /boot directory you will see the kernel::
  191 +
  192 + => ext2ls scsi 0:2 /boot
  193 + <DIR> 4096 .
  194 + <DIR> 4096 ..
  195 + <DIR> 4096 efi
  196 + <DIR> 4096 grub
  197 + 3381262 System.map-3.13.0-32-generic
  198 + 1162712 abi-3.13.0-32-generic
  199 + 165611 config-3.13.0-32-generic
  200 + 176500 memtest86+.bin
  201 + 178176 memtest86+.elf
  202 + 178680 memtest86+_multiboot.bin
  203 + 5798112 vmlinuz-3.13.0-32-generic
  204 + 165762 config-3.13.0-58-generic
  205 + 1165129 abi-3.13.0-58-generic
  206 + 5823136 vmlinuz-3.13.0-58-generic
  207 + 19215259 initrd.img-3.13.0-58-generic
  208 + 3391763 System.map-3.13.0-58-generic
  209 + 5825048 vmlinuz-3.13.0-58-generic.efi.signed
  210 + 28304443 initrd.img-3.13.0-32-generic
  211 + =>
  212 +
  213 +The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of
  214 +self-extracting compressed file mixed with some 'setup' configuration data.
  215 +Despite its size (uncompressed it is >10MB) this only includes a basic set of
  216 +device drivers, enough to boot on most hardware types.
  217 +
  218 +The 'initrd' files contain a RAM disk. This is something that can be loaded
  219 +into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots
  220 +of drivers for whatever hardware you might have. It is loaded before the
  221 +real root disk is accessed.
  222 +
  223 +The numbers after the end of each file are the version. Here it is Linux
  224 +version 3.13. You can find the source code for this in the Linux tree with
  225 +the tag v3.13. The '.0' allows for additional Linux releases to fix problems,
  226 +but normally this is not needed. The '-58' is used by Ubuntu. Each time they
  227 +release a new kernel they increment this number. New Ubuntu versions might
  228 +include kernel patches to fix reported bugs. Stable kernels can exist for
  229 +some years so this number can get quite high.
  230 +
  231 +The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own
  232 +secure boot mechanism - see `this`_ & `that`_. It cannot read .efi files
  233 +at present.
  234 +
  235 +To boot Ubuntu from U-Boot the steps are as follows:
  236 +
  237 +1. Set up the boot arguments. Use the GUID for the partition you want to boot::
  238 +
  239 + => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro
  240 +
  241 +Here root= tells Linux the location of its root disk. The disk is specified
  242 +by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory'
  243 +containing all the GUIDs Linux has found. When it starts up, there will be a
  244 +file in that directory with this name in it. It is also possible to use a
  245 +device name here, see later.
  246 +
  247 +2. Load the kernel. Since it is an ext2/4 filesystem we can do::
  248 +
  249 + => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic
  250 +
  251 +The address 30000000 is arbitrary, but there seem to be problems with using
  252 +small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into
  253 +the start of RAM (which is at 0 on x86).
  254 +
  255 +3. Load the ramdisk (to 64MB)::
  256 +
  257 + => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic
  258 +
  259 +4. Start up the kernel. We need to know the size of the ramdisk, but can use
  260 + a variable for that. U-Boot sets 'filesize' to the size of the last file it
  261 + loaded::
  262 +
  263 + => zboot 03000000 0 04000000 ${filesize}
  264 +
  265 +Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is
  266 +quite verbose when it boots a kernel. You should see these messages from
  267 +U-Boot::
  268 +
  269 + Valid Boot Flag
  270 + Setup Size = 0x00004400
  271 + Magic signature found
  272 + Using boot protocol version 2.0c
  273 + Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015
  274 + Building boot_params at 0x00090000
  275 + Loading bzImage at address 100000 (5805728 bytes)
  276 + Magic signature found
  277 + Initial RAM disk at linear address 0x04000000, size 19215259 bytes
  278 + Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro"
  279 +
  280 + Starting kernel ...
  281 +
  282 +U-Boot prints out some bootstage timing. This is more useful if you put the
  283 +above commands into a script since then it will be faster::
  284 +
  285 + Timer summary in microseconds:
  286 + Mark Elapsed Stage
  287 + 0 0 reset
  288 + 241,535 241,535 board_init_r
  289 + 2,421,611 2,180,076 id=64
  290 + 2,421,790 179 id=65
  291 + 2,428,215 6,425 main_loop
  292 + 48,860,584 46,432,369 start_kernel
  293 +
  294 + Accumulated time:
  295 + 240,329 ahci
  296 + 1,422,704 vesa display
  297 +
  298 +Now the kernel actually starts (if you want to examine kernel boot up message on
  299 +the serial console, append "console=ttyS0,115200" to the kernel command line)::
  300 +
  301 + [ 0.000000] Initializing cgroup subsys cpuset
  302 + [ 0.000000] Initializing cgroup subsys cpu
  303 + [ 0.000000] Initializing cgroup subsys cpuacct
  304 + [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22)
  305 + [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200
  306 +
  307 +It continues for a long time. Along the way you will see it pick up your
  308 +ramdisk::
  309 +
  310 + [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff]
  311 + ...
  312 + [ 0.788540] Trying to unpack rootfs image as initramfs...
  313 + [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000)
  314 + ...
  315 +
  316 +Later it actually starts using it::
  317 +
  318 + Begin: Running /scripts/local-premount ... done.
  319 +
  320 +You should also see your boot disk turn up::
  321 +
  322 + [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5
  323 + [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
  324 + [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0
  325 + [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off
  326 + [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
  327 + [ 4.399535] sda: sda1 sda2 sda3
  328 +
  329 +Linux has found the three partitions (sda1-3). Mercifully it doesn't print out
  330 +the GUIDs. In step 1 above we could have used::
  331 +
  332 + setenv bootargs root=/dev/sda2 ro
  333 +
  334 +instead of the GUID. However if you add another drive to your board the
  335 +numbering may change whereas the GUIDs will not. So if your boot partition
  336 +becomes sdb2, it will still boot. For embedded systems where you just want to
  337 +boot the first disk, you have that option.
  338 +
  339 +The last thing you will see on the console is mention of plymouth (which
  340 +displays the Ubuntu start-up screen) and a lot of 'Starting' messages::
  341 +
  342 + * Starting Mount filesystems on boot [ OK ]
  343 +
  344 +After a pause you should see a login screen on your display and you are done.
  345 +
  346 +If you want to put this in a script you can use something like this::
  347 +
  348 + setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro
  349 + setenv boot zboot 03000000 0 04000000 \${filesize}
  350 + setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot"
  351 + saveenv
  352 +
  353 +The \ is to tell the shell not to evaluate ${filesize} as part of the setenv
  354 +command.
  355 +
  356 +You can also bake this behaviour into your build by hard-coding the
  357 +environment variables if you add this to minnowmax.h:
  358 +
  359 +.. code-block:: c
  360 +
  361 + #undef CONFIG_BOOTCOMMAND
  362 + #define CONFIG_BOOTCOMMAND \
  363 + "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \
  364 + "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \
  365 + "run boot"
  366 +
  367 + #undef CONFIG_EXTRA_ENV_SETTINGS
  368 + #define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}"
  369 +
  370 +and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to::
  371 +
  372 + CONFIG_BOOTARGS="root=/dev/sda2 ro"
  373 +
  374 +Test with SeaBIOS
  375 +-----------------
  376 +`SeaBIOS`_ is an open source implementation of a 16-bit x86 BIOS. It can run
  377 +in an emulator or natively on x86 hardware with the use of U-Boot. With its
  378 +help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS.
  379 +
  380 +As U-Boot, we have to manually create a table where SeaBIOS gets various system
  381 +information (eg: E820) from. The table unfortunately has to follow the coreboot
  382 +table format as SeaBIOS currently supports booting as a coreboot payload.
  383 +
  384 +To support loading SeaBIOS, U-Boot should be built with CONFIG_SEABIOS on.
  385 +Booting SeaBIOS is done via U-Boot's bootelf command, like below::
  386 +
  387 + => tftp bios.bin.elf;bootelf
  388 + Using e1000#0 device
  389 + TFTP from server 10.10.0.100; our IP address is 10.10.0.108
  390 + ...
  391 + Bytes transferred = 122124 (1dd0c hex)
  392 + ## Starting application at 0x000ff06e ...
  393 + SeaBIOS (version rel-1.9.0)
  394 + ...
  395 +
  396 +bios.bin.elf is the SeaBIOS image built from SeaBIOS source tree.
  397 +Make sure it is built as follows::
  398 +
  399 + $ make menuconfig
  400 +
  401 +Inside the "General Features" menu, select "Build for coreboot" as the
  402 +"Build Target". Inside the "Debugging" menu, turn on "Serial port debugging"
  403 +so that we can see something as soon as SeaBIOS boots. Leave other options
  404 +as in their default state. Then::
  405 +
  406 + $ make
  407 + ...
  408 + Total size: 121888 Fixed: 66496 Free: 9184 (used 93.0% of 128KiB rom)
  409 + Creating out/bios.bin.elf
  410 +
  411 +Currently this is tested on QEMU x86 target with U-Boot chain-loading SeaBIOS
  412 +to install/boot a Windows XP OS (below for example command to install Windows).
  413 +
  414 +.. code-block:: none
  415 +
  416 + # Create a 10G disk.img as the virtual hard disk
  417 + $ qemu-img create -f qcow2 disk.img 10G
  418 +
  419 + # Install a Windows XP OS from an ISO image 'winxp.iso'
  420 + $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -cdrom winxp.iso -smp 2 -m 512
  421 +
  422 + # Boot a Windows XP OS installed on the virutal hard disk
  423 + $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -smp 2 -m 512
  424 +
  425 +This is also tested on Intel Crown Bay board with a PCIe graphics card, booting
  426 +SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally.
  427 +
  428 +If you are using Intel Integrated Graphics Device (IGD) as the primary display
  429 +device on your board, SeaBIOS needs to be patched manually to get its VGA ROM
  430 +loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM
  431 +register, but IGD device does not have its VGA ROM mapped by this register.
  432 +Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address
  433 +which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below:
  434 +
  435 +.. code-block:: none
  436 +
  437 + diff --git a/src/optionroms.c b/src/optionroms.c
  438 + index 65f7fe0..c7b6f5e 100644
  439 + --- a/src/optionroms.c
  440 + +++ b/src/optionroms.c
  441 + @@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources)
  442 + rom = deploy_romfile(file);
  443 + else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga))
  444 + rom = map_pcirom(pci);
  445 + + if (pci->bdf == pci_to_bdf(0, 2, 0))
  446 + + rom = (struct rom_header *)0xfff90000;
  447 + if (! rom)
  448 + // No ROM present.
  449 + return;
  450 +
  451 +Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM
  452 +is at 0xfff90000 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX.
  453 +Change these two accordingly if this is not the case on your board.
  454 +
  455 +Development Flow
  456 +----------------
  457 +These notes are for those who want to port U-Boot to a new x86 platform.
  458 +
  459 +Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment.
  460 +The Dediprog em100 can be used on Linux.
  461 +
  462 +The em100 tool is available here: http://review.coreboot.org/p/em100.git
  463 +
  464 +On Minnowboard Max the following command line can be used::
  465 +
  466 + sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r
  467 +
  468 +A suitable clip for connecting over the SPI flash chip is here:
  469 +http://www.dediprog.com/pd/programmer-accessories/EM-TC-8.
  470 +
  471 +This allows you to override the SPI flash contents for development purposes.
  472 +Typically you can write to the em100 in around 1200ms, considerably faster
  473 +than programming the real flash device each time. The only important
  474 +limitation of the em100 is that it only supports SPI bus speeds up to 20MHz.
  475 +This means that images must be set to boot with that speed. This is an
  476 +Intel-specific feature - e.g. tools/ifttool has an option to set the SPI
  477 +speed in the SPI descriptor region.
  478 +
  479 +If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly
  480 +easy to fit it in. You can follow the Minnowboard Max implementation, for
  481 +example. Hopefully you will just need to create new files similar to those
  482 +in arch/x86/cpu/baytrail which provide Bay Trail support.
  483 +
  484 +If you are not using an FSP you have more freedom and more responsibility.
  485 +The ivybridge support works this way, although it still uses a ROM for
  486 +graphics and still has binary blobs containing Intel code. You should aim to
  487 +support all important peripherals on your platform including video and storage.
  488 +Use the device tree for configuration where possible.
  489 +
  490 +For the microcode you can create a suitable device tree file using the
  491 +microcode tool::
  492 +
  493 + ./tools/microcode-tool -d microcode.dat -m <model> create
  494 +
  495 +or if you only have header files and not the full Intel microcode.dat database::
  496 +
  497 + ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \
  498 + -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h -m all create
  499 +
  500 +These are written to arch/x86/dts/microcode/ by default.
  501 +
  502 +Note that it is possible to just add the micrcode for your CPU if you know its
  503 +model. U-Boot prints this information when it starts::
  504 +
  505 + CPU: x86_64, vendor Intel, device 30673h
  506 +
  507 +so here we can use the M0130673322 file.
  508 +
  509 +If you platform can display POST codes on two little 7-segment displays on
  510 +the board, then you can use post_code() calls from C or assembler to monitor
  511 +boot progress. This can be good for debugging.
  512 +
  513 +If not, you can try to get serial working as early as possible. The early
  514 +debug serial port may be useful here. See setup_internal_uart() for an example.
  515 +
  516 +During the U-Boot porting, one of the important steps is to write correct PIRQ
  517 +routing information in the board device tree. Without it, device drivers in the
  518 +Linux kernel won't function correctly due to interrupt is not working. Please
  519 +refer to U-Boot `doc <doc/device-tree-bindings/misc/intel,irq-router.txt>`_ for
  520 +the device tree bindings of Intel interrupt router. Here we have more details
  521 +on the intel,pirq-routing property below.
  522 +
  523 +.. code-block:: none
  524 +
  525 + intel,pirq-routing = <
  526 + PCI_BDF(0, 2, 0) INTA PIRQA
  527 + ...
  528 + >;
  529 +
  530 +As you see each entry has 3 cells. For the first one, we need describe all pci
  531 +devices mounted on the board. For SoC devices, normally there is a chapter on
  532 +the chipset datasheet which lists all the available PCI devices. For example on
  533 +Bay Trail, this is chapter 4.3 (PCI configuration space). For the second one, we
  534 +can get the interrupt pin either from datasheet or hardware via U-Boot shell.
  535 +The reliable source is the hardware as sometimes chipset datasheet is not 100%
  536 +up-to-date. Type 'pci header' plus the device's pci bus/device/function number
  537 +from U-Boot shell below::
  538 +
  539 + => pci header 0.1e.1
  540 + vendor ID = 0x8086
  541 + device ID = 0x0f08
  542 + ...
  543 + interrupt line = 0x09
  544 + interrupt pin = 0x04
  545 + ...
  546 +
  547 +It shows this PCI device is using INTD pin as it reports 4 in the interrupt pin
  548 +register. Repeat this until you get interrupt pins for all the devices. The last
  549 +cell is the PIRQ line which a particular interrupt pin is mapped to. On Intel
  550 +chipset, the power-up default mapping is INTA/B/C/D maps to PIRQA/B/C/D. This
  551 +can be changed by registers in LPC bridge. So far Intel FSP does not touch those
  552 +registers so we can write down the PIRQ according to the default mapping rule.
  553 +
  554 +Once we get the PIRQ routing information in the device tree, the interrupt
  555 +allocation and assignment will be done by U-Boot automatically. Now you can
  556 +enable CONFIG_GENERATE_PIRQ_TABLE for testing Linux kernel using i8259 PIC and
  557 +CONFIG_GENERATE_MP_TABLE for testing Linux kernel using local APIC and I/O APIC.
  558 +
  559 +This script might be useful. If you feed it the output of 'pci long' from
  560 +U-Boot then it will generate a device tree fragment with the interrupt
  561 +configuration for each device (note it needs gawk 4.0.0)::
  562 +
  563 + $ cat console_output |awk '/PCI/ {device=$4} /interrupt line/ {line=$4} \
  564 + /interrupt pin/ {pin = $4; if (pin != "0x00" && pin != "0xff") \
  565 + {patsplit(device, bdf, "[0-9a-f]+"); \
  566 + printf "PCI_BDF(%d, %d, %d) INT%c PIRQ%c\n", strtonum("0x" bdf[1]), \
  567 + strtonum("0x" bdf[2]), bdf[3], strtonum(pin) + 64, 64 + strtonum(pin)}}'
  568 +
  569 +Example output::
  570 +
  571 + PCI_BDF(0, 2, 0) INTA PIRQA
  572 + PCI_BDF(0, 3, 0) INTA PIRQA
  573 + ...
  574 +
  575 +Porting Hints
  576 +-------------
  577 +
  578 +Quark-specific considerations
  579 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  580 +
  581 +To port U-Boot to other boards based on the Intel Quark SoC, a few things need
  582 +to be taken care of. The first important part is the Memory Reference Code (MRC)
  583 +parameters. Quark MRC supports memory-down configuration only. All these MRC
  584 +parameters are supplied via the board device tree. To get started, first copy
  585 +the MRC section of arch/x86/dts/galileo.dts to your board's device tree, then
  586 +change these values by consulting board manuals or your hardware vendor.
  587 +Available MRC parameter values are listed in include/dt-bindings/mrc/quark.h.
  588 +The other tricky part is with PCIe. Quark SoC integrates two PCIe root ports,
  589 +but by default they are held in reset after power on. In U-Boot, PCIe
  590 +initialization is properly handled as per Quark's firmware writer guide.
  591 +In your board support codes, you need provide two routines to aid PCIe
  592 +initialization, which are board_assert_perst() and board_deassert_perst().
  593 +The two routines need implement a board-specific mechanism to assert/deassert
  594 +PCIe PERST# pin. Care must be taken that in those routines that any APIs that
  595 +may trigger PCI enumeration process are strictly forbidden, as any access to
  596 +PCIe root port's configuration registers will cause system hang while it is
  597 +held in reset. For more details, check how they are implemented by the Intel
  598 +Galileo board support codes in board/intel/galileo/galileo.c.
  599 +
  600 +coreboot
  601 +^^^^^^^^
  602 +
  603 +See scripts/coreboot.sed which can assist with porting coreboot code into
  604 +U-Boot drivers. It will not resolve all build errors, but will perform common
  605 +transformations. Remember to add attribution to coreboot for new files added
  606 +to U-Boot. This should go at the top of each file and list the coreboot
  607 +filename where the code originated.
  608 +
  609 +Debugging ACPI issues with Windows
  610 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  611 +
  612 +Windows might cache system information and only detect ACPI changes if you
  613 +modify the ACPI table versions. So tweak them liberally when debugging ACPI
  614 +issues with Windows.
  615 +
  616 +ACPI Support Status
  617 +-------------------
  618 +Advanced Configuration and Power Interface (`ACPI`_) aims to establish
  619 +industry-standard interfaces enabling OS-directed configuration, power
  620 +management, and thermal management of mobile, desktop, and server platforms.
  621 +
  622 +Linux can boot without ACPI with "acpi=off" command line parameter, but
  623 +with ACPI the kernel gains the capabilities to handle power management.
  624 +For Windows, ACPI is a must-have firmware feature since Windows Vista.
  625 +CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in
  626 +U-Boot. This requires Intel ACPI compiler to be installed on your host to
  627 +compile ACPI DSDT table written in ASL format to AML format. You can get
  628 +the compiler via "apt-get install iasl" if you are on Ubuntu or download
  629 +the source from https://www.acpica.org/downloads to compile one by yourself.
  630 +
  631 +Current ACPI support in U-Boot is basically complete. More optional features
  632 +can be added in the future. The status as of today is:
  633 +
  634 + * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables.
  635 + * Support one static DSDT table only, compiled by Intel ACPI compiler.
  636 + * Support S0/S3/S4/S5, reboot and shutdown from OS.
  637 + * Support booting a pre-installed Ubuntu distribution via 'zboot' command.
  638 + * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with
  639 + the help of SeaBIOS using legacy interface (non-UEFI mode).
  640 + * Support installing and booting Windows 8.1/10 from U-Boot with the help
  641 + of SeaBIOS using legacy interface (non-UEFI mode).
  642 + * Support ACPI interrupts with SCI only.
  643 +
  644 +Features that are optional:
  645 +
  646 + * Dynamic AML bytecodes insertion at run-time. We may need this to support
  647 + SSDT table generation and DSDT fix up.
  648 + * SMI support. Since U-Boot is a modern bootloader, we don't want to bring
  649 + those legacy stuff into U-Boot. ACPI spec allows a system that does not
  650 + support SMI (a legacy-free system).
  651 +
  652 +ACPI was initially enabled on BayTrail based boards. Testing was done by booting
  653 +a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and
  654 +Windows 8.1/10 to a SATA drive and booting from there is also tested. Most
  655 +devices seem to work correctly and the board can respond a reboot/shutdown
  656 +command from the OS.
  657 +
  658 +For other platform boards, ACPI support status can be checked by examining their
  659 +board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y.
  660 +
  661 +The S3 sleeping state is a low wake latency sleeping state defined by ACPI
  662 +spec where all system context is lost except system memory. To test S3 resume
  663 +with a Linux kernel, simply run "echo mem > /sys/power/state" and kernel will
  664 +put the board to S3 state where the power is off. So when the power button is
  665 +pressed again, U-Boot runs as it does in cold boot and detects the sleeping
  666 +state via ACPI register to see if it is S3, if yes it means we are waking up.
  667 +U-Boot is responsible for restoring the machine state as it is before sleep.
  668 +When everything is done, U-Boot finds out the wakeup vector provided by OSes
  669 +and jump there. To determine whether ACPI S3 resume is supported, check to
  670 +see if CONFIG_HAVE_ACPI_RESUME is set for that specific board.
  671 +
  672 +Note for testing S3 resume with Windows, correct graphics driver must be
  673 +installed for your platform, otherwise you won't find "Sleep" option in
  674 +the "Power" submenu from the Windows start menu.
  675 +
  676 +EFI Support
  677 +-----------
  678 +U-Boot supports booting as a 32-bit or 64-bit EFI payload, e.g. with UEFI.
  679 +This is enabled with CONFIG_EFI_STUB to boot from both 32-bit and 64-bit
  680 +UEFI BIOS. U-Boot can also run as an EFI application, with CONFIG_EFI_APP.
  681 +The CONFIG_EFI_LOADER option, where U-Boot provides an EFI environment to
  682 +the kernel (i.e. replaces UEFI completely but provides the same EFI run-time
  683 +services) is supported too. For example, we can even use 'bootefi' command
  684 +to load a 'u-boot-payload.efi', see below test logs on QEMU.
  685 +
  686 +.. code-block:: none
  687 +
  688 + => load ide 0 3000000 u-boot-payload.efi
  689 + 489787 bytes read in 138 ms (3.4 MiB/s)
  690 + => bootefi 3000000
  691 + Scanning disk ide.blk#0...
  692 + Found 2 disks
  693 + WARNING: booting without device tree
  694 + ## Starting EFI application at 03000000 ...
  695 + U-Boot EFI Payload
  696 +
  697 +
  698 + U-Boot 2018.07-rc2 (Jun 23 2018 - 17:12:58 +0800)
  699 +
  700 + CPU: x86_64, vendor AMD, device 663h
  701 + DRAM: 2 GiB
  702 + MMC:
  703 + Video: 1024x768x32
  704 + Model: EFI x86 Payload
  705 + Net: e1000: 52:54:00:12:34:56
  706 +
  707 + Warning: e1000#0 using MAC address from ROM
  708 + eth0: e1000#0
  709 + No controllers found
  710 + Hit any key to stop autoboot: 0
  711 +
  712 +See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot.
  713 +
  714 +TODO List
  715 +---------
  716 +- Audio
  717 +- Chrome OS verified boot
  718 +
  719 +.. _coreboot: http://www.coreboot.org
  720 +.. _QEMU: http://www.qemu.org
  721 +.. _microcode: http://en.wikipedia.org/wiki/Microcode
  722 +.. _SFI: http://simplefirmware.org
  723 +.. _MP: http://www.intel.com/design/archives/processors/pro/docs/242016.htm
  724 +.. _here: https://en.wikipedia.org/wiki/GUID_Partition_Table
  725 +.. _this: http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf
  726 +.. _that: http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf
  727 +.. _SeaBIOS: http://www.seabios.org/SeaBIOS
  728 +.. _ACPI: http://www.acpi.info