]>
Commit | Line | Data |
---|---|---|
5dad97ed BM |
1 | # |
2 | # Copyright (C) 2014, Simon Glass <sjg@chromium.org> | |
3 | # Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com> | |
4 | # | |
5 | # SPDX-License-Identifier: GPL-2.0+ | |
6 | # | |
7 | ||
8 | U-Boot on x86 | |
9 | ============= | |
10 | ||
11 | This document describes the information about U-Boot running on x86 targets, | |
12 | including supported boards, build instructions, todo list, etc. | |
13 | ||
14 | Status | |
15 | ------ | |
16 | U-Boot supports running as a coreboot [1] payload on x86. So far only Link | |
1ae5b78c BM |
17 | (Chromebook Pixel) and QEMU [2] x86 targets have been tested, but it should |
18 | work with minimal adjustments on other x86 boards since coreboot deals with | |
19 | most of the low-level details. | |
5dad97ed | 20 | |
28a85365 SI |
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 | |
f21069ff SG |
23 | 'bare metal', U-Boot acts like a BIOS replacement. The following platforms |
24 | are supported: | |
25 | ||
26 | - Bayley Bay | |
27 | - Cougar Canyon 2 CRB | |
28 | - Crown Bay CRB | |
29 | - Galileo | |
30 | - Link (Chromebook Pixel) | |
31 | - Minnowboard MAX | |
32 | - Samus (Chromebook Pixel 2015) | |
33 | - QEMU x86 | |
5dad97ed | 34 | |
3a1a18ff SG |
35 | As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit |
36 | Linux kernel as part of a FIT image. It also supports a compressed zImage. | |
3619e94a BM |
37 | U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks |
38 | for more details. | |
5dad97ed | 39 | |
28a85365 SI |
40 | Build Instructions for U-Boot as coreboot payload |
41 | ------------------------------------------------- | |
5dad97ed BM |
42 | Building U-Boot as a coreboot payload is just like building U-Boot for targets |
43 | on other architectures, like below: | |
44 | ||
45 | $ make coreboot-x86_defconfig | |
46 | $ make all | |
47 | ||
1ae5b78c | 48 | Note this default configuration will build a U-Boot payload for the QEMU board. |
617b867f BM |
49 | To build a coreboot payload against another board, you can change the build |
50 | configuration during the 'make menuconfig' process. | |
51 | ||
52 | x86 architecture ---> | |
53 | ... | |
1ae5b78c | 54 | (qemu-x86) Board configuration file |
683b09d7 | 55 | (qemu-x86_i440fx) Board Device Tree Source (dts) file |
1ae5b78c | 56 | (0x01920000) Board specific Cache-As-RAM (CAR) address |
617b867f BM |
57 | (0x4000) Board specific Cache-As-RAM (CAR) size |
58 | ||
59 | Change the 'Board configuration file' and 'Board Device Tree Source (dts) file' | |
60 | to point to a new board. You can also change the Cache-As-RAM (CAR) related | |
61 | settings here if the default values do not fit your new board. | |
62 | ||
28a85365 SI |
63 | Build Instructions for U-Boot as BIOS replacement (bare mode) |
64 | ------------------------------------------------------------- | |
3a1a18ff | 65 | Building a ROM version of U-Boot (hereafter referred to as u-boot.rom) is a |
5dad97ed BM |
66 | little bit tricky, as generally it requires several binary blobs which are not |
67 | shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is | |
68 | not turned on by default in the U-Boot source tree. Firstly, you need turn it | |
eea0f112 | 69 | on by enabling the ROM build: |
5dad97ed | 70 | |
eea0f112 SG |
71 | $ export BUILD_ROM=y |
72 | ||
73 | This tells the Makefile to build u-boot.rom as a target. | |
5dad97ed | 74 | |
28a85365 SI |
75 | --- |
76 | ||
77 | Chromebook Link specific instructions for bare mode: | |
5dad97ed BM |
78 | |
79 | First, you need the following binary blobs: | |
80 | ||
81 | * descriptor.bin - Intel flash descriptor | |
82 | * me.bin - Intel Management Engine | |
83 | * mrc.bin - Memory Reference Code, which sets up SDRAM | |
84 | * video ROM - sets up the display | |
85 | ||
86 | You can get these binary blobs by: | |
87 | ||
88 | $ git clone http://review.coreboot.org/p/blobs.git | |
89 | $ cd blobs | |
90 | ||
91 | Find the following files: | |
92 | ||
93 | * ./mainboard/google/link/descriptor.bin | |
94 | * ./mainboard/google/link/me.bin | |
8712af97 | 95 | * ./northbridge/intel/sandybridge/systemagent-r6.bin |
5dad97ed BM |
96 | |
97 | The 3rd one should be renamed to mrc.bin. | |
786a08e0 | 98 | As for the video ROM, you can get it here [3] and rename it to vga.bin. |
5dad97ed BM |
99 | Make sure all these binary blobs are put in the board directory. |
100 | ||
101 | Now you can build U-Boot and obtain u-boot.rom: | |
102 | ||
103 | $ make chromebook_link_defconfig | |
104 | $ make all | |
105 | ||
28a85365 SI |
106 | --- |
107 | ||
374e78ef SG |
108 | Chromebook Samus (2015 Pixel) instructions for bare mode: |
109 | ||
110 | First, you need the following binary blobs: | |
111 | ||
112 | * descriptor.bin - Intel flash descriptor | |
113 | * me.bin - Intel Management Engine | |
114 | * mrc.bin - Memory Reference Code, which sets up SDRAM | |
115 | * refcode.elf - Additional Reference code | |
116 | * vga.bin - video ROM, which sets up the display | |
117 | ||
118 | If you have a samus you can obtain them from your flash, for example, in | |
119 | developer mode on the Chromebook (use Ctrl-Alt-F2 to obtain a terminal and | |
120 | log in as 'root'): | |
121 | ||
122 | cd /tmp | |
123 | flashrom -w samus.bin | |
124 | scp samus.bin username@ip_address:/path/to/somewhere | |
125 | ||
126 | If not see the coreboot tree [4] where you can use: | |
127 | ||
128 | bash crosfirmware.sh samus | |
129 | ||
130 | to get the image. There is also an 'extract_blobs.sh' scripts that you can use | |
131 | on the 'coreboot-Google_Samus.*' file to short-circuit some of the below. | |
132 | ||
133 | Then 'ifdtool -x samus.bin' on your development machine will produce: | |
134 | ||
135 | flashregion_0_flashdescriptor.bin | |
136 | flashregion_1_bios.bin | |
137 | flashregion_2_intel_me.bin | |
138 | ||
139 | Rename flashregion_0_flashdescriptor.bin to descriptor.bin | |
140 | Rename flashregion_2_intel_me.bin to me.bin | |
141 | You can ignore flashregion_1_bios.bin - it is not used. | |
142 | ||
143 | To get the rest, use 'cbfstool samus.bin print': | |
144 | ||
145 | samus.bin: 8192 kB, bootblocksize 2864, romsize 8388608, offset 0x700000 | |
146 | alignment: 64 bytes, architecture: x86 | |
147 | ||
148 | Name Offset Type Size | |
149 | cmos_layout.bin 0x700000 cmos_layout 1164 | |
150 | pci8086,0406.rom 0x7004c0 optionrom 65536 | |
151 | spd.bin 0x710500 (unknown) 4096 | |
152 | cpu_microcode_blob.bin 0x711540 microcode 70720 | |
153 | fallback/romstage 0x722a00 stage 54210 | |
154 | fallback/ramstage 0x72fe00 stage 96382 | |
155 | config 0x7476c0 raw 6075 | |
156 | fallback/vboot 0x748ec0 stage 15980 | |
157 | fallback/refcode 0x74cd80 stage 75578 | |
158 | fallback/payload 0x75f500 payload 62878 | |
159 | u-boot.dtb 0x76eb00 (unknown) 5318 | |
160 | (empty) 0x770000 null 196504 | |
161 | mrc.bin 0x79ffc0 (unknown) 222876 | |
162 | (empty) 0x7d66c0 null 167320 | |
163 | ||
164 | You can extract what you need: | |
165 | ||
166 | cbfstool samus.bin extract -n pci8086,0406.rom -f vga.bin | |
167 | cbfstool samus.bin extract -n fallback/refcode -f refcode.rmod | |
168 | cbfstool samus.bin extract -n mrc.bin -f mrc.bin | |
169 | cbfstool samus.bin extract -n fallback/refcode -f refcode.bin -U | |
170 | ||
171 | Note that the -U flag is only supported by the latest cbfstool. It unpacks | |
172 | and decompresses the stage to produce a coreboot rmodule. This is a simple | |
173 | representation of an ELF file. You need the patch "Support decoding a stage | |
174 | with compression". | |
175 | ||
176 | Put all 5 files into board/google/chromebook_samus. | |
177 | ||
178 | Now you can build U-Boot and obtain u-boot.rom: | |
179 | ||
180 | $ make chromebook_link_defconfig | |
181 | $ make all | |
182 | ||
183 | If you are using em100, then this command will flash write -Boot: | |
184 | ||
185 | em100 -s -d filename.rom -c W25Q64CV -r | |
186 | ||
187 | --- | |
188 | ||
28a85365 | 189 | Intel Crown Bay specific instructions for bare mode: |
5dad97ed | 190 | |
1ae5b78c BM |
191 | U-Boot support of Intel Crown Bay board [4] relies on a binary blob called |
192 | Firmware Support Package [5] to perform all the necessary initialization steps | |
5dad97ed BM |
193 | as documented in the BIOS Writer Guide, including initialization of the CPU, |
194 | memory controller, chipset and certain bus interfaces. | |
195 | ||
196 | Download the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T, | |
197 | install it on your host and locate the FSP binary blob. Note this platform | |
198 | also requires a Chipset Micro Code (CMC) state machine binary to be present in | |
199 | the SPI flash where u-boot.rom resides, and this CMC binary blob can be found | |
200 | in this FSP package too. | |
201 | ||
202 | * ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd | |
203 | * ./Microcode/C0_22211.BIN | |
204 | ||
205 | Rename the first one to fsp.bin and second one to cmc.bin and put them in the | |
206 | board directory. | |
207 | ||
83d9712e BM |
208 | Note the FSP release version 001 has a bug which could cause random endless |
209 | loop during the FspInit call. This bug was published by Intel although Intel | |
210 | did not describe any details. We need manually apply the patch to the FSP | |
211 | binary using any hex editor (eg: bvi). Go to the offset 0x1fcd8 of the FSP | |
212 | binary, change the following five bytes values from orginally E8 42 FF FF FF | |
213 | to B8 00 80 0B 00. | |
214 | ||
7aaff9bf BM |
215 | As for the video ROM, you need manually extract it from the Intel provided |
216 | BIOS for Crown Bay here [6], using the AMI MMTool [7]. Check PCI option ROM | |
217 | ID 8086:4108, extract and save it as vga.bin in the board directory. | |
218 | ||
617b867f | 219 | Now you can build U-Boot and obtain u-boot.rom |
5dad97ed BM |
220 | |
221 | $ make crownbay_defconfig | |
222 | $ make all | |
223 | ||
28a85365 SI |
224 | --- |
225 | ||
a2e3b05e BM |
226 | Intel Cougar Canyon 2 specific instructions for bare mode: |
227 | ||
228 | This uses Intel FSP for 3rd generation Intel Core and Intel Celeron processors | |
229 | with mobile Intel HM76 and QM77 chipsets platform. Download it from Intel FSP | |
230 | website and put the .fd file (CHIEFRIVER_FSP_GOLD_001_09-OCTOBER-2013.fd at the | |
231 | time of writing) in the board directory and rename it to fsp.bin. | |
232 | ||
233 | Now build U-Boot and obtain u-boot.rom | |
234 | ||
235 | $ make cougarcanyon2_defconfig | |
236 | $ make all | |
237 | ||
238 | The board has two 8MB SPI flashes mounted, which are called SPI-0 and SPI-1 in | |
239 | the board manual. The SPI-0 flash should have flash descriptor plus ME firmware | |
240 | and SPI-1 flash is used to store U-Boot. For convenience, the complete 8MB SPI-0 | |
241 | flash image is included in the FSP package (named Rom00_8M_MB_PPT.bin). Program | |
242 | this image to the SPI-0 flash according to the board manual just once and we are | |
243 | all set. For programming U-Boot we just need to program SPI-1 flash. | |
244 | ||
245 | --- | |
246 | ||
03bfc783 | 247 | Intel Bay Trail based board instructions for bare mode: |
3a1a18ff SG |
248 | |
249 | This uses as FSP as with Crown Bay, except it is for the Atom E3800 series. | |
03bfc783 | 250 | Two boards that use this configuration are Bayley Bay and Minnowboard MAX. |
3a1a18ff | 251 | Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at |
03bfc783 BM |
252 | the time of writing). Put it in the corresponding board directory and rename |
253 | it to fsp.bin. | |
3a1a18ff SG |
254 | |
255 | Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same | |
03bfc783 | 256 | board directory as vga.bin. |
3a1a18ff | 257 | |
03bfc783 BM |
258 | You still need two more binary blobs. For Bayley Bay, they can be extracted |
259 | from the sample SPI image provided in the FSP (SPI.bin at the time of writing). | |
260 | ||
261 | $ ./tools/ifdtool -x BayleyBay/SPI.bin | |
262 | $ cp flashregion_0_flashdescriptor.bin board/intel/bayleybay/descriptor.bin | |
263 | $ cp flashregion_2_intel_me.bin board/intel/bayleybay/me.bin | |
264 | ||
265 | For Minnowboard MAX, we can reuse the same ME firmware above, but for flash | |
266 | descriptor, we need get that somewhere else, as the one above does not seem to | |
267 | work, probably because it is not designed for the Minnowboard MAX. Now download | |
268 | the original firmware image for this board from: | |
68522481 SG |
269 | |
270 | http://firmware.intel.com/sites/default/files/2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip | |
271 | ||
272 | Unzip it: | |
273 | ||
274 | $ unzip 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip | |
3a1a18ff SG |
275 | |
276 | Use ifdtool in the U-Boot tools directory to extract the images from that | |
277 | file, for example: | |
278 | ||
68522481 SG |
279 | $ ./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin |
280 | ||
281 | This will provide the descriptor file - copy this into the correct place: | |
282 | ||
283 | $ cp flashregion_0_flashdescriptor.bin board/intel/minnowmax/descriptor.bin | |
284 | ||
3a1a18ff | 285 | Now you can build U-Boot and obtain u-boot.rom |
03bfc783 | 286 | Note: below are examples/information for Minnowboard MAX. |
3a1a18ff SG |
287 | |
288 | $ make minnowmax_defconfig | |
289 | $ make all | |
290 | ||
df898678 SG |
291 | Checksums are as follows (but note that newer versions will invalidate this): |
292 | ||
293 | $ md5sum -b board/intel/minnowmax/*.bin | |
294 | ffda9a3b94df5b74323afb328d51e6b4 board/intel/minnowmax/descriptor.bin | |
295 | 69f65b9a580246291d20d08cbef9d7c5 board/intel/minnowmax/fsp.bin | |
296 | 894a97d371544ec21de9c3e8e1716c4b board/intel/minnowmax/me.bin | |
297 | a2588537da387da592a27219d56e9962 board/intel/minnowmax/vga.bin | |
298 | ||
537ccba2 SG |
299 | The ROM image is broken up into these parts: |
300 | ||
301 | Offset Description Controlling config | |
302 | ------------------------------------------------------------ | |
303 | 000000 descriptor.bin Hard-coded to 0 in ifdtool | |
304 | 001000 me.bin Set by the descriptor | |
305 | 500000 <spare> | |
638a0589 | 306 | 6f0000 MRC cache CONFIG_ENABLE_MRC_CACHE |
537ccba2 | 307 | 700000 u-boot-dtb.bin CONFIG_SYS_TEXT_BASE |
7f72cdf9 | 308 | 790000 vga.bin CONFIG_VGA_BIOS_ADDR |
537ccba2 SG |
309 | 7c0000 fsp.bin CONFIG_FSP_ADDR |
310 | 7f8000 <spare> (depends on size of fsp.bin) | |
311 | 7fe000 Environment CONFIG_ENV_OFFSET | |
312 | 7ff800 U-Boot 16-bit boot CONFIG_SYS_X86_START16 | |
313 | ||
314 | Overall ROM image size is controlled by CONFIG_ROM_SIZE. | |
315 | ||
28a85365 | 316 | --- |
537ccba2 | 317 | |
28a85365 | 318 | Intel Galileo instructions for bare mode: |
67582c00 BM |
319 | |
320 | Only one binary blob is needed for Remote Management Unit (RMU) within Intel | |
321 | Quark SoC. Not like FSP, U-Boot does not call into the binary. The binary is | |
322 | needed by the Quark SoC itself. | |
323 | ||
324 | You can get the binary blob from Quark Board Support Package from Intel website: | |
325 | ||
326 | * ./QuarkSocPkg/QuarkNorthCluster/Binary/QuarkMicrocode/RMU.bin | |
327 | ||
328 | Rename the file and put it to the board directory by: | |
329 | ||
330 | $ cp RMU.bin board/intel/galileo/rmu.bin | |
331 | ||
332 | Now you can build U-Boot and obtain u-boot.rom | |
333 | ||
334 | $ make galileo_defconfig | |
335 | $ make all | |
3a1a18ff | 336 | |
03bfc783 BM |
337 | --- |
338 | ||
339 | QEMU x86 target instructions for bare mode: | |
1ae5b78c BM |
340 | |
341 | To build u-boot.rom for QEMU x86 targets, just simply run | |
342 | ||
343 | $ make qemu-x86_defconfig | |
344 | $ make all | |
345 | ||
683b09d7 BM |
346 | Note this default configuration will build a U-Boot for the QEMU x86 i440FX |
347 | board. To build a U-Boot against QEMU x86 Q35 board, you can change the build | |
348 | configuration during the 'make menuconfig' process like below: | |
349 | ||
350 | Device Tree Control ---> | |
351 | ... | |
352 | (qemu-x86_q35) Default Device Tree for DT control | |
353 | ||
617b867f BM |
354 | Test with coreboot |
355 | ------------------ | |
356 | For testing U-Boot as the coreboot payload, there are things that need be paid | |
357 | attention to. coreboot supports loading an ELF executable and a 32-bit plain | |
358 | binary, as well as other supported payloads. With the default configuration, | |
359 | U-Boot is set up to use a separate Device Tree Blob (dtb). As of today, the | |
360 | generated u-boot-dtb.bin needs to be packaged by the cbfstool utility (a tool | |
361 | provided by coreboot) manually as coreboot's 'make menuconfig' does not provide | |
362 | this capability yet. The command is as follows: | |
363 | ||
364 | # in the coreboot root directory | |
365 | $ ./build/util/cbfstool/cbfstool build/coreboot.rom add-flat-binary \ | |
330728d7 | 366 | -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x1110000 -e 0x1110000 |
617b867f | 367 | |
330728d7 BM |
368 | Make sure 0x1110000 matches CONFIG_SYS_TEXT_BASE, which is the symbol address |
369 | of _x86boot_start (in arch/x86/cpu/start.S). | |
617b867f BM |
370 | |
371 | If you want to use ELF as the coreboot payload, change U-Boot configuration to | |
eea0f112 | 372 | use CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE. |
617b867f | 373 | |
3a1a18ff SG |
374 | To enable video you must enable these options in coreboot: |
375 | ||
376 | - Set framebuffer graphics resolution (1280x1024 32k-color (1:5:5)) | |
377 | - Keep VESA framebuffer | |
378 | ||
379 | At present it seems that for Minnowboard Max, coreboot does not pass through | |
380 | the video information correctly (it always says the resolution is 0x0). This | |
381 | works correctly for link though. | |
382 | ||
28a85365 SI |
383 | Test with QEMU for bare mode |
384 | ---------------------------- | |
1ae5b78c | 385 | QEMU is a fancy emulator that can enable us to test U-Boot without access to |
9c4f5412 BM |
386 | a real x86 board. Please make sure your QEMU version is 2.3.0 or above test |
387 | U-Boot. To launch QEMU with u-boot.rom, call QEMU as follows: | |
1ae5b78c BM |
388 | |
389 | $ qemu-system-i386 -nographic -bios path/to/u-boot.rom | |
390 | ||
391 | This will instantiate an emulated x86 board with i440FX and PIIX chipset. QEMU | |
392 | also supports emulating an x86 board with Q35 and ICH9 based chipset, which is | |
393 | also supported by U-Boot. To instantiate such a machine, call QEMU with: | |
394 | ||
395 | $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -M q35 | |
396 | ||
397 | Note by default QEMU instantiated boards only have 128 MiB system memory. But | |
398 | it is enough to have U-Boot boot and function correctly. You can increase the | |
399 | system memory by pass '-m' parameter to QEMU if you want more memory: | |
400 | ||
401 | $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 | |
402 | ||
403 | This creates a board with 1 GiB system memory. Currently U-Boot for QEMU only | |
404 | supports 3 GiB maximum system memory and reserves the last 1 GiB address space | |
405 | for PCI device memory-mapped I/O and other stuff, so the maximum value of '-m' | |
406 | would be 3072. | |
3a1a18ff | 407 | |
9c4f5412 BM |
408 | QEMU emulates a graphic card which U-Boot supports. Removing '-nographic' will |
409 | show QEMU's VGA console window. Note this will disable QEMU's serial output. | |
410 | If you want to check both consoles, use '-serial stdio'. | |
411 | ||
a2eb65fc | 412 | Multicore is also supported by QEMU via '-smp n' where n is the number of cores |
5c2ed61c MY |
413 | to instantiate. Note, the maximum supported CPU number in QEMU is 255. |
414 | ||
415 | The fw_cfg interface in QEMU also provides information about kernel data, initrd, | |
416 | command-line arguments and more. U-Boot supports directly accessing these informtion | |
417 | from fw_cfg interface, this saves the time of loading them from hard disk or | |
418 | network again, through emulated devices. To use it , simply providing them in | |
419 | QEMU command line: | |
420 | ||
421 | $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 -kernel /path/to/bzImage | |
422 | -append 'root=/dev/ram console=ttyS0' -initrd /path/to/initrd -smp 8 | |
423 | ||
424 | Note: -initrd and -smp are both optional | |
425 | ||
426 | Then start QEMU, in U-Boot command line use the following U-Boot command to setup kernel: | |
427 | ||
428 | => qfw | |
429 | qfw - QEMU firmware interface | |
430 | ||
431 | Usage: | |
432 | qfw <command> | |
433 | - list : print firmware(s) currently loaded | |
434 | - cpus : print online cpu number | |
435 | - load <kernel addr> <initrd addr> : load kernel and initrd (if any) and setup for zboot | |
436 | ||
437 | => qfw load | |
438 | loading kernel to address 01000000 size 5d9d30 initrd 04000000 size 1b1ab50 | |
439 | ||
440 | Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then, 'zboot' | |
441 | can be used to boot the kernel: | |
442 | ||
443 | => zboot 02000000 - 04000000 1b1ab50 | |
a2eb65fc | 444 | |
5dad97ed BM |
445 | CPU Microcode |
446 | ------------- | |
7aaff9bf | 447 | Modern CPUs usually require a special bit stream called microcode [8] to be |
5dad97ed BM |
448 | loaded on the processor after power up in order to function properly. U-Boot |
449 | has already integrated these as hex dumps in the source tree. | |
450 | ||
1281a1fc BM |
451 | SMP Support |
452 | ----------- | |
453 | On a multicore system, U-Boot is executed on the bootstrap processor (BSP). | |
454 | Additional application processors (AP) can be brought up by U-Boot. In order to | |
455 | have an SMP kernel to discover all of the available processors, U-Boot needs to | |
456 | prepare configuration tables which contain the multi-CPUs information before | |
457 | loading the OS kernel. Currently U-Boot supports generating two types of tables | |
7aaff9bf BM |
458 | for SMP, called Simple Firmware Interface (SFI) [9] and Multi-Processor (MP) |
459 | [10] tables. The writing of these two tables are controlled by two Kconfig | |
460 | options GENERATE_SFI_TABLE and GENERATE_MP_TABLE. | |
1281a1fc | 461 | |
5dad97ed BM |
462 | Driver Model |
463 | ------------ | |
f21069ff SG |
464 | x86 has been converted to use driver model for serial, GPIO, SPI, SPI flash, |
465 | keyboard, real-time clock, USB. Video is in progress. | |
5dad97ed BM |
466 | |
467 | Device Tree | |
468 | ----------- | |
469 | x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to | |
617b867f | 470 | be turned on. Not every device on the board is configured via device tree, but |
5dad97ed BM |
471 | more and more devices will be added as time goes by. Check out the directory |
472 | arch/x86/dts/ for these device tree source files. | |
473 | ||
cb3b2e62 SG |
474 | Useful Commands |
475 | --------------- | |
cb3b2e62 SG |
476 | In keeping with the U-Boot philosophy of providing functions to check and |
477 | adjust internal settings, there are several x86-specific commands that may be | |
478 | useful: | |
479 | ||
62716ebb BM |
480 | fsp - Display information about Intel Firmware Support Package (FSP). |
481 | This is only available on platforms which use FSP, mostly Atom. | |
cb3b2e62 SG |
482 | iod - Display I/O memory |
483 | iow - Write I/O memory | |
484 | mtrr - List and set the Memory Type Range Registers (MTRR). These are used to | |
485 | tell the CPU whether memory is cacheable and if so the cache write | |
486 | mode to use. U-Boot sets up some reasonable values but you can | |
487 | adjust then with this command. | |
488 | ||
7bea5271 SG |
489 | Booting Ubuntu |
490 | -------------- | |
491 | As an example of how to set up your boot flow with U-Boot, here are | |
492 | instructions for starting Ubuntu from U-Boot. These instructions have been | |
493 | tested on Minnowboard MAX with a SATA driver but are equally applicable on | |
494 | other platforms and other media. There are really only four steps and its a | |
495 | very simple script, but a more detailed explanation is provided here for | |
496 | completeness. | |
497 | ||
498 | Note: It is possible to set up U-Boot to boot automatically using syslinux. | |
499 | It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the | |
500 | GUID. If you figure these out, please post patches to this README. | |
501 | ||
502 | Firstly, you will need Ubunutu installed on an available disk. It should be | |
503 | possible to make U-Boot start a USB start-up disk but for now let's assume | |
504 | that you used another boot loader to install Ubuntu. | |
505 | ||
506 | Use the U-Boot command line to find the UUID of the partition you want to | |
507 | boot. For example our disk is SCSI device 0: | |
508 | ||
509 | => part list scsi 0 | |
510 | ||
511 | Partition Map for SCSI device 0 -- Partition Type: EFI | |
512 | ||
513 | Part Start LBA End LBA Name | |
514 | Attributes | |
515 | Type GUID | |
516 | Partition GUID | |
517 | 1 0x00000800 0x001007ff "" | |
518 | attrs: 0x0000000000000000 | |
519 | type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b | |
520 | guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c | |
521 | 2 0x00100800 0x037d8fff "" | |
522 | attrs: 0x0000000000000000 | |
523 | type: 0fc63daf-8483-4772-8e79-3d69d8477de4 | |
524 | guid: 965c59ee-1822-4326-90d2-b02446050059 | |
525 | 3 0x037d9000 0x03ba27ff "" | |
526 | attrs: 0x0000000000000000 | |
527 | type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f | |
528 | guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 | |
529 | => | |
530 | ||
531 | This shows that your SCSI disk has three partitions. The really long hex | |
532 | strings are called Globally Unique Identifiers (GUIDs). You can look up the | |
533 | 'type' ones here [11]. On this disk the first partition is for EFI and is in | |
534 | VFAT format (DOS/Windows): | |
535 | ||
536 | => fatls scsi 0:1 | |
537 | efi/ | |
538 | ||
539 | 0 file(s), 1 dir(s) | |
540 | ||
541 | ||
542 | Partition 2 is 'Linux filesystem data' so that will be our root disk. It is | |
543 | in ext2 format: | |
544 | ||
545 | => ext2ls scsi 0:2 | |
546 | <DIR> 4096 . | |
547 | <DIR> 4096 .. | |
548 | <DIR> 16384 lost+found | |
549 | <DIR> 4096 boot | |
550 | <DIR> 12288 etc | |
551 | <DIR> 4096 media | |
552 | <DIR> 4096 bin | |
553 | <DIR> 4096 dev | |
554 | <DIR> 4096 home | |
555 | <DIR> 4096 lib | |
556 | <DIR> 4096 lib64 | |
557 | <DIR> 4096 mnt | |
558 | <DIR> 4096 opt | |
559 | <DIR> 4096 proc | |
560 | <DIR> 4096 root | |
561 | <DIR> 4096 run | |
562 | <DIR> 12288 sbin | |
563 | <DIR> 4096 srv | |
564 | <DIR> 4096 sys | |
565 | <DIR> 4096 tmp | |
566 | <DIR> 4096 usr | |
567 | <DIR> 4096 var | |
568 | <SYM> 33 initrd.img | |
569 | <SYM> 30 vmlinuz | |
570 | <DIR> 4096 cdrom | |
571 | <SYM> 33 initrd.img.old | |
572 | => | |
573 | ||
574 | and if you look in the /boot directory you will see the kernel: | |
575 | ||
576 | => ext2ls scsi 0:2 /boot | |
577 | <DIR> 4096 . | |
578 | <DIR> 4096 .. | |
579 | <DIR> 4096 efi | |
580 | <DIR> 4096 grub | |
581 | 3381262 System.map-3.13.0-32-generic | |
582 | 1162712 abi-3.13.0-32-generic | |
583 | 165611 config-3.13.0-32-generic | |
584 | 176500 memtest86+.bin | |
585 | 178176 memtest86+.elf | |
586 | 178680 memtest86+_multiboot.bin | |
587 | 5798112 vmlinuz-3.13.0-32-generic | |
588 | 165762 config-3.13.0-58-generic | |
589 | 1165129 abi-3.13.0-58-generic | |
590 | 5823136 vmlinuz-3.13.0-58-generic | |
591 | 19215259 initrd.img-3.13.0-58-generic | |
592 | 3391763 System.map-3.13.0-58-generic | |
593 | 5825048 vmlinuz-3.13.0-58-generic.efi.signed | |
594 | 28304443 initrd.img-3.13.0-32-generic | |
595 | => | |
596 | ||
597 | The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of | |
598 | self-extracting compressed file mixed with some 'setup' configuration data. | |
599 | Despite its size (uncompressed it is >10MB) this only includes a basic set of | |
600 | device drivers, enough to boot on most hardware types. | |
601 | ||
602 | The 'initrd' files contain a RAM disk. This is something that can be loaded | |
603 | into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots | |
604 | of drivers for whatever hardware you might have. It is loaded before the | |
605 | real root disk is accessed. | |
606 | ||
607 | The numbers after the end of each file are the version. Here it is Linux | |
608 | version 3.13. You can find the source code for this in the Linux tree with | |
609 | the tag v3.13. The '.0' allows for additional Linux releases to fix problems, | |
610 | but normally this is not needed. The '-58' is used by Ubuntu. Each time they | |
611 | release a new kernel they increment this number. New Ubuntu versions might | |
612 | include kernel patches to fix reported bugs. Stable kernels can exist for | |
613 | some years so this number can get quite high. | |
614 | ||
615 | The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own | |
616 | secure boot mechanism - see [12] [13] and cannot read .efi files at present. | |
617 | ||
618 | To boot Ubuntu from U-Boot the steps are as follows: | |
619 | ||
620 | 1. Set up the boot arguments. Use the GUID for the partition you want to | |
621 | boot: | |
622 | ||
623 | => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro | |
624 | ||
625 | Here root= tells Linux the location of its root disk. The disk is specified | |
626 | by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory' | |
627 | containing all the GUIDs Linux has found. When it starts up, there will be a | |
628 | file in that directory with this name in it. It is also possible to use a | |
629 | device name here, see later. | |
630 | ||
631 | 2. Load the kernel. Since it is an ext2/4 filesystem we can do: | |
632 | ||
633 | => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic | |
634 | ||
635 | The address 30000000 is arbitrary, but there seem to be problems with using | |
636 | small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into | |
637 | the start of RAM (which is at 0 on x86). | |
638 | ||
639 | 3. Load the ramdisk (to 64MB): | |
640 | ||
641 | => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic | |
642 | ||
643 | 4. Start up the kernel. We need to know the size of the ramdisk, but can use | |
644 | a variable for that. U-Boot sets 'filesize' to the size of the last file it | |
645 | loaded. | |
646 | ||
647 | => zboot 03000000 0 04000000 ${filesize} | |
648 | ||
649 | Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is | |
650 | quite verbose when it boots a kernel. You should see these messages from | |
651 | U-Boot: | |
652 | ||
653 | Valid Boot Flag | |
654 | Setup Size = 0x00004400 | |
655 | Magic signature found | |
656 | Using boot protocol version 2.0c | |
657 | Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 | |
658 | Building boot_params at 0x00090000 | |
659 | Loading bzImage at address 100000 (5805728 bytes) | |
660 | Magic signature found | |
661 | Initial RAM disk at linear address 0x04000000, size 19215259 bytes | |
662 | Kernel command line: "console=ttyS0,115200 root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" | |
663 | ||
664 | Starting kernel ... | |
665 | ||
666 | U-Boot prints out some bootstage timing. This is more useful if you put the | |
667 | above commands into a script since then it will be faster. | |
668 | ||
669 | Timer summary in microseconds: | |
670 | Mark Elapsed Stage | |
671 | 0 0 reset | |
672 | 241,535 241,535 board_init_r | |
673 | 2,421,611 2,180,076 id=64 | |
674 | 2,421,790 179 id=65 | |
675 | 2,428,215 6,425 main_loop | |
676 | 48,860,584 46,432,369 start_kernel | |
677 | ||
678 | Accumulated time: | |
679 | 240,329 ahci | |
680 | 1,422,704 vesa display | |
681 | ||
682 | Now the kernel actually starts: | |
683 | ||
684 | [ 0.000000] Initializing cgroup subsys cpuset | |
685 | [ 0.000000] Initializing cgroup subsys cpu | |
686 | [ 0.000000] Initializing cgroup subsys cpuacct | |
687 | [ 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) | |
688 | [ 0.000000] Command line: console=ttyS0,115200 root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro | |
689 | ||
690 | It continues for a long time. Along the way you will see it pick up your | |
691 | ramdisk: | |
692 | ||
693 | [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff] | |
694 | ... | |
695 | [ 0.788540] Trying to unpack rootfs image as initramfs... | |
696 | [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000) | |
697 | ... | |
698 | ||
699 | Later it actually starts using it: | |
700 | ||
701 | Begin: Running /scripts/local-premount ... done. | |
702 | ||
703 | You should also see your boot disk turn up: | |
704 | ||
705 | [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5 | |
706 | [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) | |
707 | [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0 | |
708 | [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off | |
709 | [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA | |
710 | [ 4.399535] sda: sda1 sda2 sda3 | |
711 | ||
712 | Linux has found the three partitions (sda1-3). Mercifully it doesn't print out | |
713 | the GUIDs. In step 1 above we could have used: | |
714 | ||
715 | setenv bootargs root=/dev/sda2 ro | |
716 | ||
717 | instead of the GUID. However if you add another drive to your board the | |
718 | numbering may change whereas the GUIDs will not. So if your boot partition | |
719 | becomes sdb2, it will still boot. For embedded systems where you just want to | |
720 | boot the first disk, you have that option. | |
721 | ||
722 | The last thing you will see on the console is mention of plymouth (which | |
723 | displays the Ubuntu start-up screen) and a lot of 'Starting' messages: | |
724 | ||
725 | * Starting Mount filesystems on boot [ OK ] | |
726 | ||
727 | After a pause you should see a login screen on your display and you are done. | |
728 | ||
729 | If you want to put this in a script you can use something like this: | |
730 | ||
731 | setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro | |
732 | setenv boot zboot 03000000 0 04000000 \${filesize} | |
733 | 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" | |
734 | saveenv | |
735 | ||
736 | The \ is to tell the shell not to evaluate ${filesize} as part of the setenv | |
737 | command. | |
738 | ||
739 | You will also need to add this to your board configuration file, e.g. | |
740 | include/configs/minnowmax.h: | |
741 | ||
742 | #define CONFIG_BOOTDELAY 2 | |
743 | ||
744 | Now when you reset your board it wait a few seconds (in case you want to | |
745 | interrupt) and then should boot straight into Ubuntu. | |
746 | ||
747 | You can also bake this behaviour into your build by hard-coding the | |
748 | environment variables if you add this to minnowmax.h: | |
749 | ||
750 | #undef CONFIG_BOOTARGS | |
751 | #undef CONFIG_BOOTCOMMAND | |
752 | ||
753 | #define CONFIG_BOOTARGS \ | |
754 | "root=/dev/sda2 ro" | |
755 | #define CONFIG_BOOTCOMMAND \ | |
756 | "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \ | |
757 | "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \ | |
758 | "run boot" | |
759 | ||
760 | #undef CONFIG_EXTRA_ENV_SETTINGS | |
761 | #define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}" | |
762 | ||
2e9ae222 BM |
763 | Test with SeaBIOS |
764 | ----------------- | |
765 | SeaBIOS [14] is an open source implementation of a 16-bit x86 BIOS. It can run | |
766 | in an emulator or natively on x86 hardware with the use of U-Boot. With its | |
767 | help, we can boot some OSes that require 16-bit BIOS services like Windows/DOS. | |
768 | ||
769 | As U-Boot, we have to manually create a table where SeaBIOS gets various system | |
770 | information (eg: E820) from. The table unfortunately has to follow the coreboot | |
771 | table format as SeaBIOS currently supports booting as a coreboot payload. | |
772 | ||
773 | To support loading SeaBIOS, U-Boot should be built with CONFIG_SEABIOS on. | |
774 | Booting SeaBIOS is done via U-Boot's bootelf command, like below: | |
775 | ||
776 | => tftp bios.bin.elf;bootelf | |
777 | Using e1000#0 device | |
778 | TFTP from server 10.10.0.100; our IP address is 10.10.0.108 | |
779 | ... | |
780 | Bytes transferred = 122124 (1dd0c hex) | |
781 | ## Starting application at 0x000ff06e ... | |
782 | SeaBIOS (version rel-1.9.0) | |
783 | ... | |
784 | ||
785 | bios.bin.elf is the SeaBIOS image built from SeaBIOS source tree. | |
786 | Make sure it is built as follows: | |
787 | ||
788 | $ make menuconfig | |
789 | ||
790 | Inside the "General Features" menu, select "Build for coreboot" as the | |
791 | "Build Target". Inside the "Debugging" menu, turn on "Serial port debugging" | |
792 | so that we can see something as soon as SeaBIOS boots. Leave other options | |
793 | as in their default state. Then, | |
794 | ||
795 | $ make | |
796 | ... | |
797 | Total size: 121888 Fixed: 66496 Free: 9184 (used 93.0% of 128KiB rom) | |
798 | Creating out/bios.bin.elf | |
799 | ||
800 | Currently this is tested on QEMU x86 target with U-Boot chain-loading SeaBIOS | |
801 | to install/boot a Windows XP OS (below for example command to install Windows). | |
802 | ||
803 | # Create a 10G disk.img as the virtual hard disk | |
804 | $ qemu-img create -f qcow2 disk.img 10G | |
805 | ||
806 | # Install a Windows XP OS from an ISO image 'winxp.iso' | |
807 | $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -cdrom winxp.iso -smp 2 -m 512 | |
808 | ||
809 | # Boot a Windows XP OS installed on the virutal hard disk | |
810 | $ qemu-system-i386 -serial stdio -bios u-boot.rom -hda disk.img -smp 2 -m 512 | |
811 | ||
812 | This is also tested on Intel Crown Bay board with a PCIe graphics card, booting | |
813 | SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally. | |
814 | ||
7bea5271 | 815 | |
00bdd952 SG |
816 | Development Flow |
817 | ---------------- | |
00bdd952 SG |
818 | These notes are for those who want to port U-Boot to a new x86 platform. |
819 | ||
820 | Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment. | |
821 | The Dediprog em100 can be used on Linux. The em100 tool is available here: | |
822 | ||
823 | http://review.coreboot.org/p/em100.git | |
824 | ||
825 | On Minnowboard Max the following command line can be used: | |
826 | ||
827 | sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r | |
828 | ||
829 | A suitable clip for connecting over the SPI flash chip is here: | |
830 | ||
831 | http://www.dediprog.com/pd/programmer-accessories/EM-TC-8 | |
832 | ||
833 | This allows you to override the SPI flash contents for development purposes. | |
834 | Typically you can write to the em100 in around 1200ms, considerably faster | |
835 | than programming the real flash device each time. The only important | |
836 | limitation of the em100 is that it only supports SPI bus speeds up to 20MHz. | |
837 | This means that images must be set to boot with that speed. This is an | |
838 | Intel-specific feature - e.g. tools/ifttool has an option to set the SPI | |
839 | speed in the SPI descriptor region. | |
840 | ||
841 | If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly | |
842 | easy to fit it in. You can follow the Minnowboard Max implementation, for | |
843 | example. Hopefully you will just need to create new files similar to those | |
844 | in arch/x86/cpu/baytrail which provide Bay Trail support. | |
845 | ||
846 | If you are not using an FSP you have more freedom and more responsibility. | |
847 | The ivybridge support works this way, although it still uses a ROM for | |
848 | graphics and still has binary blobs containing Intel code. You should aim to | |
849 | support all important peripherals on your platform including video and storage. | |
850 | Use the device tree for configuration where possible. | |
851 | ||
852 | For the microcode you can create a suitable device tree file using the | |
853 | microcode tool: | |
854 | ||
03e3c316 | 855 | ./tools/microcode-tool -d microcode.dat -m <model> create |
00bdd952 SG |
856 | |
857 | or if you only have header files and not the full Intel microcode.dat database: | |
858 | ||
859 | ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \ | |
860 | -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h \ | |
03e3c316 | 861 | -m all create |
00bdd952 SG |
862 | |
863 | These are written to arch/x86/dts/microcode/ by default. | |
864 | ||
865 | Note that it is possible to just add the micrcode for your CPU if you know its | |
866 | model. U-Boot prints this information when it starts | |
867 | ||
868 | CPU: x86_64, vendor Intel, device 30673h | |
869 | ||
870 | so here we can use the M0130673322 file. | |
871 | ||
872 | If you platform can display POST codes on two little 7-segment displays on | |
873 | the board, then you can use post_code() calls from C or assembler to monitor | |
874 | boot progress. This can be good for debugging. | |
875 | ||
876 | If not, you can try to get serial working as early as possible. The early | |
d521197d | 877 | debug serial port may be useful here. See setup_internal_uart() for an example. |
00bdd952 | 878 | |
12c7510f BM |
879 | During the U-Boot porting, one of the important steps is to write correct PIRQ |
880 | routing information in the board device tree. Without it, device drivers in the | |
881 | Linux kernel won't function correctly due to interrupt is not working. Please | |
2e9ae222 | 882 | refer to U-Boot doc [15] for the device tree bindings of Intel interrupt router. |
12c7510f BM |
883 | Here we have more details on the intel,pirq-routing property below. |
884 | ||
885 | intel,pirq-routing = < | |
886 | PCI_BDF(0, 2, 0) INTA PIRQA | |
887 | ... | |
888 | >; | |
889 | ||
890 | As you see each entry has 3 cells. For the first one, we need describe all pci | |
891 | devices mounted on the board. For SoC devices, normally there is a chapter on | |
892 | the chipset datasheet which lists all the available PCI devices. For example on | |
893 | Bay Trail, this is chapter 4.3 (PCI configuration space). For the second one, we | |
894 | can get the interrupt pin either from datasheet or hardware via U-Boot shell. | |
895 | The reliable source is the hardware as sometimes chipset datasheet is not 100% | |
896 | up-to-date. Type 'pci header' plus the device's pci bus/device/function number | |
897 | from U-Boot shell below. | |
898 | ||
899 | => pci header 0.1e.1 | |
900 | vendor ID = 0x8086 | |
901 | device ID = 0x0f08 | |
902 | ... | |
903 | interrupt line = 0x09 | |
904 | interrupt pin = 0x04 | |
905 | ... | |
906 | ||
907 | It shows this PCI device is using INTD pin as it reports 4 in the interrupt pin | |
908 | register. Repeat this until you get interrupt pins for all the devices. The last | |
909 | cell is the PIRQ line which a particular interrupt pin is mapped to. On Intel | |
910 | chipset, the power-up default mapping is INTA/B/C/D maps to PIRQA/B/C/D. This | |
911 | can be changed by registers in LPC bridge. So far Intel FSP does not touch those | |
912 | registers so we can write down the PIRQ according to the default mapping rule. | |
913 | ||
914 | Once we get the PIRQ routing information in the device tree, the interrupt | |
915 | allocation and assignment will be done by U-Boot automatically. Now you can | |
916 | enable CONFIG_GENERATE_PIRQ_TABLE for testing Linux kernel using i8259 PIC and | |
917 | CONFIG_GENERATE_MP_TABLE for testing Linux kernel using local APIC and I/O APIC. | |
918 | ||
590870e7 SG |
919 | This script might be useful. If you feed it the output of 'pci long' from |
920 | U-Boot then it will generate a device tree fragment with the interrupt | |
921 | configuration for each device (note it needs gawk 4.0.0): | |
922 | ||
923 | $ cat console_output |awk '/PCI/ {device=$4} /interrupt line/ {line=$4} \ | |
924 | /interrupt pin/ {pin = $4; if (pin != "0x00" && pin != "0xff") \ | |
925 | {patsplit(device, bdf, "[0-9a-f]+"); \ | |
926 | printf "PCI_BDF(%d, %d, %d) INT%c PIRQ%c\n", strtonum("0x" bdf[1]), \ | |
927 | strtonum("0x" bdf[2]), bdf[3], strtonum(pin) + 64, 64 + strtonum(pin)}}' | |
928 | ||
929 | Example output: | |
930 | PCI_BDF(0, 2, 0) INTA PIRQA | |
931 | PCI_BDF(0, 3, 0) INTA PIRQA | |
932 | ... | |
933 | ||
448719c5 BM |
934 | Porting Hints |
935 | ------------- | |
936 | ||
937 | Quark-specific considerations: | |
938 | ||
939 | To port U-Boot to other boards based on the Intel Quark SoC, a few things need | |
940 | to be taken care of. The first important part is the Memory Reference Code (MRC) | |
941 | parameters. Quark MRC supports memory-down configuration only. All these MRC | |
942 | parameters are supplied via the board device tree. To get started, first copy | |
943 | the MRC section of arch/x86/dts/galileo.dts to your board's device tree, then | |
944 | change these values by consulting board manuals or your hardware vendor. | |
945 | Available MRC parameter values are listed in include/dt-bindings/mrc/quark.h. | |
946 | The other tricky part is with PCIe. Quark SoC integrates two PCIe root ports, | |
947 | but by default they are held in reset after power on. In U-Boot, PCIe | |
948 | initialization is properly handled as per Quark's firmware writer guide. | |
949 | In your board support codes, you need provide two routines to aid PCIe | |
950 | initialization, which are board_assert_perst() and board_deassert_perst(). | |
951 | The two routines need implement a board-specific mechanism to assert/deassert | |
952 | PCIe PERST# pin. Care must be taken that in those routines that any APIs that | |
953 | may trigger PCI enumeration process are strictly forbidden, as any access to | |
954 | PCIe root port's configuration registers will cause system hang while it is | |
955 | held in reset. For more details, check how they are implemented by the Intel | |
956 | Galileo board support codes in board/intel/galileo/galileo.c. | |
957 | ||
e28fcb22 SG |
958 | coreboot: |
959 | ||
960 | See scripts/coreboot.sed which can assist with porting coreboot code into | |
961 | U-Boot drivers. It will not resolve all build errors, but will perform common | |
962 | transformations. Remember to add attribution to coreboot for new files added | |
963 | to U-Boot. This should go at the top of each file and list the coreboot | |
964 | filename where the code originated. | |
965 | ||
966 | ||
5dad97ed BM |
967 | TODO List |
968 | --------- | |
5dad97ed BM |
969 | - Audio |
970 | - Chrome OS verified boot | |
971 | - SMI and ACPI support, to provide platform info and facilities to Linux | |
972 | ||
973 | References | |
974 | ---------- | |
975 | [1] http://www.coreboot.org | |
1ae5b78c BM |
976 | [2] http://www.qemu.org |
977 | [3] http://www.coreboot.org/~stepan/pci8086,0166.rom | |
978 | [4] http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-platforms/atom-e660-eg20t-development-kit.html | |
979 | [5] http://www.intel.com/fsp | |
7aaff9bf BM |
980 | [6] http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/e6xx-35-b1-cmc22211.html |
981 | [7] http://www.ami.com/products/bios-uefi-tools-and-utilities/bios-uefi-utilities/ | |
982 | [8] http://en.wikipedia.org/wiki/Microcode | |
983 | [9] http://simplefirmware.org | |
984 | [10] http://www.intel.com/design/archives/processors/pro/docs/242016.htm | |
7bea5271 SG |
985 | [11] https://en.wikipedia.org/wiki/GUID_Partition_Table |
986 | [12] http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf | |
987 | [13] http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf | |
2e9ae222 BM |
988 | [14] http://www.seabios.org/SeaBIOS |
989 | [15] doc/device-tree-bindings/misc/intel,irq-router.txt |