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