Hi Simon, On Fri, Dec 5, 2014 at 8:03 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 4 December 2014 at 08:04, Bin Meng <bmeng...@gmail.com> wrote: >> Signed-off-by: Bin Meng <bmeng...@gmail.com> >> --- >> doc/README.x86 | 123 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 123 insertions(+) >> create mode 100644 doc/README.x86 >> >> diff --git a/doc/README.x86 b/doc/README.x86 >> new file mode 100644 >> index 0000000..a79f510 >> --- /dev/null >> +++ b/doc/README.x86 >> @@ -0,0 +1,123 @@ >> +# >> +# Copyright (C) 2014, Simon Glass <s...@chromium.org> >> +# Copyright (C) 2014, Bin Meng <bmeng...@gmail.com> >> +# >> +# SPDX-License-Identifier: GPL-2.0+ >> +# >> + >> +U-Boot on x86 >> +============= > > Very nice! > >> + >> +This document describes the information about U-Boot running on x86 targets, >> +including supported boards, build instructions, todo list, etc. >> + >> +Status >> +------ >> +U-Boot supports running as a coreboot [1] payload on x86. So far only link >> +(Chromebook pixel) has been tested, but it should work with minimal >> adjustments >> +on other x86 boards since coreboot deals with most of the low-level details. >> + >> +U-Boot also supports booting directly from x86 reset vector without >> coreboot, >> +aka raw support or bare support. Currently Google Chromebook link and Intel >> +Crown Bay board support running U-Boot 'bare metal'. >> + >> +As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux >> +kernel as part of a FIT image. It also supports a compressed zImage. >> + >> +Build Instructions >> +------------------ >> +Building U-Boot as a coreboot payload is just like building U-Boot for >> targets >> +on other architectures, like below: >> + >> +$ make coreboot-x86_defconfig >> +$ make all >> + >> +Building rom version U-Boot (hereafter referred to as u-boot.rom) is a >> little >> +bit tricky, as generally it requires several binary blobs which are not >> shipped >> +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not >> +turned on by default in the U-Boot source tree. Firstly, you need turn it on >> +by uncommenting the following line in the main U-Boot Makefile: >> + >> +# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom >> + >> +Google Chromebook link specific instructions: >> + >> +Firstly, you need the following binary blobs: >> + >> +* descriptor.bin - Intel flash descriptor >> +* me.bin - Intel Management Engine >> +* mrc.bin - Memory Reference Code, which sets up SDRAM >> +* video ROM - sets up the display >> + >> +You can get these binary blobs by: >> + >> +$ git clone http://review.coreboot.org/p/blobs.git >> +$ cd blobs >> + >> +Find the following files: >> + >> +* ./mainboard/google/link/descriptor.bin >> +* ./mainboard/google/link/me.bin >> +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin >> + >> +The 3rd one should be renamed to mrc.bin. >> +As for the video ROM, you can get it here [2]. >> + >> +Now you can build U-Boot and obtain u-boot.rom: >> + >> +$ make chromebook_link_defconfig >> +$ make all >> + >> +Intel Crown Bay specific instructions: >> + >> +U-Boot support of Intel Crown Bay board [3] relies on a binary blob called >> +Firmware Support Package [4] to perform all the necessary initialization >> steps >> +as documented in the BIOS Writer Guide including initialization of the CPU, >> +memory controller, chipset and certain bus interfaces. >> + >> +Downalod the Intel FSP for Atom E6xx series and Platform Controller Hub >> EG20T, >> +install it on your host and locate the FSP binary blob. Note this platform >> +also requires a Chipset Micro Code (CMC) state machine binary to be present >> in >> +the SPI flash where u-boot.rom resides, and this CMC binary blob can be >> found >> +in this FSP package too. > > Can we just put them in the board directory with standard names?
Yes, will do it in v2. >> + >> +* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd >> +* ./Microcode/C0_22211.BIN >> + >> +Now you can build U-Boot and obtaim u-boot.rom >> + >> +$ make crownbay_defconfig >> +$ make menuconfig # points FSP and CMC binary path to the correct one > > Best if we can avoid that step. I will update the instructions to use the standard binary blob names, so that this step can be omitted. >> +$ make all >> + >> +CPU Microcode >> +------------- >> +Modern CPU usually requires a special bit stream called microcode [5] to be >> +loaded on the processor after power up in order to function properly. U-Boot >> +has already integrated these as hex dumps in the source tree. >> + >> +Driver Model >> +------------ >> +x86 has been converted to use driver model for serial and GPIO. >> + >> +Device Tree >> +----------- >> +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL >> to >> +be turned on. Not every device on the board is configured via devie tree, >> but >> +more and more devices will be added as time goes by. Check out the directory >> +arch/x86/dts/ for these device tree source files. >> + >> +TODO List >> +--------- >> +- MTRR support (for performance) > > I'm interested - does the lack of this make your board slow? > I believe the FSP binary blob already has the MTRR support, and U-Boot running on my board is pretty fast. [snip] Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot