July 2019 - U-Boot

[U-Boot] [PATCH] ARM: omap3: overo: Fix MMC init for SPL
by anselm.busse＠outlook.com 13 Aug '19

13 Aug '19

From: Anselm Busse <anselm.busse(a)outlook.com> The SPL for the Overo board does not initialise the MMC. Hence, it cannot load the main boot loader from the SD card susequently. This Patch moves the initialisation code for the MMC so it gets included in the SPL. --- board/overo/common.c | 25 +++++++++++++++++++++++++ board/overo/overo.c | 14 -------------- 2 files changed, 25 insertions(+), 14 deletions(-) diff --git a/board/overo/common.c b/board/overo/common.c index fc02d66d53..851f55d43c 100644 --- a/board/overo/common.c +++ b/board/overo/common.c @@ -38,6 +38,31 @@ int board_init(void) return 0; } +#if defined(CONFIG_MMC) +int board_mmc_init(bd_t *bis) +{ + return omap_mmc_init(0, 0, 0, -1, -1); +} +#endif + +#if defined(CONFIG_MMC) +void board_mmc_power_init(void) +{ + twl4030_power_mmc_init(0); +} +#endif + +#if defined(CONFIG_SPL_OS_BOOT) +int spl_start_uboot(void) +{ + /* break into full u-boot on 'c' */ + if (serial_tstc() && serial_getc() == 'c') + return 1; + + return 0; +} +#endif /* CONFIG_SPL_OS_BOOT */ + #define MUX_OVERO() \ /*SDRC*/\ MUX_VAL(CP(SDRC_D0), (IEN | PTD | DIS | M0)) /*SDRC_D0*/\ diff --git a/board/overo/overo.c b/board/overo/overo.c index 8fa41f8155..3d57f945f4 100644 --- a/board/overo/overo.c +++ b/board/overo/overo.c @@ -376,20 +376,6 @@ int board_eth_init(bd_t *bis) } #endif -#if defined(CONFIG_MMC) -int board_mmc_init(bd_t *bis) -{ - return omap_mmc_init(0, 0, 0, -1, -1); -} -#endif - -#if defined(CONFIG_MMC) -void board_mmc_power_init(void) -{ - twl4030_power_mmc_init(0); -} -#endif - #if defined(CONFIG_USB_EHCI_HCD) static struct omap_usbhs_board_data usbhs_bdata = { .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED, -- 2.22.0

2 1

[U-Boot] [PATCH 1/2] board: siemens: adapt factoryset reading for DM_I2C enabled boards
by Anatolij Gustschin 13 Aug '19

13 Aug '19

For new boards we always enable DM_I2C. Extend factoryset functions to support EEPROM reading on these boards. Signed-off-by: Anatolij Gustschin <agust(a)denx.de> --- board/siemens/common/factoryset.c | 45 +++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/board/siemens/common/factoryset.c b/board/siemens/common/factoryset.c index 96615424f6..1dda897f18 100644 --- a/board/siemens/common/factoryset.c +++ b/board/siemens/common/factoryset.c @@ -8,6 +8,7 @@ #if !defined(CONFIG_SPL_BUILD) #include <common.h> +#include <dm.h> #include <environment.h> #include <i2c.h> #include <asm/io.h> @@ -143,16 +144,39 @@ int factoryset_read_eeprom(int i2c_addr) int i, pages = 0, size = 0; unsigned char eeprom_buf[0x3c00], hdr[4], buf[MAX_STRING_LENGTH]; unsigned char *cp, *cp1; +#if CONFIG_IS_ENABLED(DM_I2C) + struct udevice *bus, *dev; + int ret; +#endif #if defined(CONFIG_DFU_OVER_USB) factory_dat.usb_vendor_id = CONFIG_USB_GADGET_VENDOR_NUM; factory_dat.usb_product_id = CONFIG_USB_GADGET_PRODUCT_NUM; #endif + +#if CONFIG_IS_ENABLED(DM_I2C) + ret = uclass_get_device_by_seq(UCLASS_I2C, EEPROM_I2C_BUS, &bus); + if (ret) + goto err; + + ret = dm_i2c_probe(bus, i2c_addr, 0, &dev); + if (ret) + goto err; + + ret = i2c_set_chip_offset_len(dev, 2); + if (ret) + goto err; + + ret = dm_i2c_read(dev, EEPROM_FATORYSET_OFFSET, hdr, sizeof(hdr)); + if (ret) + goto err; +#else if (i2c_probe(i2c_addr)) goto err; if (i2c_read(i2c_addr, EEPROM_FATORYSET_OFFSET, 2, hdr, sizeof(hdr))) goto err; +#endif if ((hdr[0] != 0x99) || (hdr[1] != 0x80)) { printf("FactorySet is not right in eeprom.\n"); @@ -173,16 +197,33 @@ int factoryset_read_eeprom(int i2c_addr) * data after every time we got a record from eeprom */ debug("Read eeprom page :\n"); - for (i = 0; i < pages; i++) + for (i = 0; i < pages; i++) { +#if CONFIG_IS_ENABLED(DM_I2C) + ret = dm_i2c_read(dev, (OFF_PG + i) * EEPR_PG_SZ, + eeprom_buf + (i * EEPR_PG_SZ), EEPR_PG_SZ); + if (ret) + goto err; +#else if (i2c_read(i2c_addr, (OFF_PG + i) * EEPR_PG_SZ, 2, eeprom_buf + (i * EEPR_PG_SZ), EEPR_PG_SZ)) goto err; +#endif + } - if (size % EEPR_PG_SZ) + if (size % EEPR_PG_SZ) { +#if CONFIG_IS_ENABLED(DM_I2C) + ret = dm_i2c_read(dev, (OFF_PG + pages) * EEPR_PG_SZ, + eeprom_buf + (pages * EEPR_PG_SZ), + size % EEPR_PG_SZ); + if (ret) + goto err; +#else if (i2c_read(i2c_addr, (OFF_PG + pages) * EEPR_PG_SZ, 2, eeprom_buf + (pages * EEPR_PG_SZ), (size % EEPR_PG_SZ))) goto err; +#endif + } /* we do below just for eeprom align */ for (i = 0; i < size; i++) -- 2.17.1

2 3

[U-Boot] x86 FSP 2
by Simon Glass 13 Aug '19

13 Aug '19

Hi Bin, I'm looking at Apollo Lake and it seems to use a newer FSP version (2.0). The API differences seem to be fairly minor but the packaging seems a little more complicated. I'm thinking of introducing a Kconfig for this and moving the existing fsp implementation into an arch/x86/lib/fsp1 directory and adding an fsp2 there also. What do you think? Have you done anything with this newer version? Regards, Simon

2 4

[U-Boot] Verified boot of images without signatures
by Patrick Doyle 13 Aug '19

13 Aug '19

I am looking at enabling verified boot in the v2019.04-rc4 tag of u-boot. I was pleased when I learned how to embed the public authentication key in my u-boot device tree, sign my kernel using my private authentication key, and see u-boot validate the signature on boot. But then I was very surprised to learn that I could still boot an unsigned image. So I started looking at the code and I found `fit_image_verify_with_data() in "common/image_fit.c", which does: if (IMAGE_ENABLE_VERIFY && fit_image_verify_required_sigs(fit, image_noffset, data, size, gd_fdt_blob(), &verify_all)) { err_msg = "Unable to verify required signature"; goto error; } /* Process all hash subnodes of the component image node */ fdt_for_each_subnode(noffset, fit, image_noffset) { const char *name = fit_get_name(fit, noffset, NULL); /* * Check subnode name, must be equal to "hash". * Multiple hash nodes require unique unit node * names, e.g. hash-1, hash-2, etc. */ if (!strncmp(name, FIT_HASH_NODENAME, strlen(FIT_HASH_NODENAME))) { if (fit_image_check_hash(fit, noffset, data, size, &err_msg)) goto error; puts("+ "); } else if (IMAGE_ENABLE_VERIFY && verify_all && !strncmp(name, FIT_SIG_NODENAME, strlen(FIT_SIG_NODENAME))) { ret = fit_image_check_sig(fit, noffset, data, size, -1, &err_msg); /* * Show an indication on failure, but do not return * an error. Only keys marked 'required' can cause * an image validation failure. See the call to * fit_image_verify_required_sigs() above. */ if (ret) puts("- "); else puts("+ "); } } I see that if I create a "required" property in my signature block, then u-boot will require that the signature match. But if I don't have that, then it will happily boot an unsigned image (or even one that doesn't have any signature blocks). Am I missing something here? Has this been improved/addressed since v2019.04-rc4? If the answers are "No" and "No", then I will go in and address it myself. I welcome any tips folks might care to give me in advance of me just submitting a patch to address this. --wpd

3 3

[U-Boot] [PATCH v2 0/3] Enable spl relocation on arm
by Andy Yan 13 Aug '19

13 Aug '19

Some times we want to relocate spl code to dram after dram initialization or relocate spl code to a high memory to avoid code overid. For example on Rockchip armv8 platform, we run with boot flow TPL->SPL->ATF->U-Boot. TPL run in sram and is responsible for dram initialization. SPL run from the start address of dram and is responsible for loading ATF and U-Boot. The case here is that the ATF load address is from 64KB of dram, which overlaps with spl code itself. So we want to relocate spl itself to high memory to aovid this. When look the code, I found powerpc use the spl relocation. So I dicide share the config with powerpc. Changes in v2: - Move Kconfig modification to PATCH 1/3 - Add more detial commit message Andy Yan (3): powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig spl: add relocation support arm: add spl relocation support for arm arch/arm/config.mk | 6 +++ arch/arm/cpu/armv8/start.S | 4 ++ arch/arm/cpu/armv8/u-boot-spl.lds | 17 ++++++ arch/arm/lib/Makefile | 2 +- arch/arm/lib/crt0_64.S | 3 +- common/spl/Kconfig | 13 +++++ common/spl/spl.c | 55 ++++++++++++++++++++ configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 2 + configs/BSC9131RDB_NAND_defconfig | 2 + configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 2 + configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 2 + configs/C29XPCIE_NAND_defconfig | 2 + configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 + configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 2 + configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 + configs/P1010RDB-PA_NAND_defconfig | 2 + configs/P1010RDB-PA_SDCARD_defconfig | 2 + configs/P1010RDB-PA_SPIFLASH_defconfig | 2 + configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 + configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 2 + configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 + configs/P1010RDB-PB_NAND_defconfig | 2 + configs/P1010RDB-PB_SDCARD_defconfig | 2 + configs/P1010RDB-PB_SPIFLASH_defconfig | 2 + configs/P1020MBG-PC_36BIT_SDCARD_defconfig | 2 + configs/P1020MBG-PC_SDCARD_defconfig | 2 + configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 + configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 + configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + configs/P1020RDB-PC_NAND_defconfig | 2 + configs/P1020RDB-PC_SDCARD_defconfig | 2 + configs/P1020RDB-PC_SPIFLASH_defconfig | 2 + configs/P1020RDB-PD_NAND_defconfig | 2 + configs/P1020RDB-PD_SDCARD_defconfig | 2 + configs/P1020RDB-PD_SPIFLASH_defconfig | 2 + configs/P1020UTM-PC_36BIT_SDCARD_defconfig | 2 + configs/P1020UTM-PC_SDCARD_defconfig | 2 + configs/P1021RDB-PC_36BIT_NAND_defconfig | 2 + configs/P1021RDB-PC_36BIT_SDCARD_defconfig | 2 + configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig | 2 + configs/P1021RDB-PC_NAND_defconfig | 2 + configs/P1021RDB-PC_SDCARD_defconfig | 2 + configs/P1021RDB-PC_SPIFLASH_defconfig | 2 + configs/P1022DS_36BIT_NAND_defconfig | 2 + configs/P1022DS_36BIT_SDCARD_defconfig | 2 + configs/P1022DS_36BIT_SPIFLASH_defconfig | 2 + configs/P1022DS_NAND_defconfig | 2 + configs/P1022DS_SDCARD_defconfig | 2 + configs/P1022DS_SPIFLASH_defconfig | 2 + configs/P1024RDB_NAND_defconfig | 2 + configs/P1024RDB_SDCARD_defconfig | 2 + configs/P1024RDB_SPIFLASH_defconfig | 2 + configs/P1025RDB_NAND_defconfig | 2 + configs/P1025RDB_SDCARD_defconfig | 2 + configs/P1025RDB_SPIFLASH_defconfig | 2 + configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 + configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 + configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 2 + configs/P2020RDB-PC_NAND_defconfig | 2 + configs/P2020RDB-PC_SDCARD_defconfig | 2 + configs/P2020RDB-PC_SPIFLASH_defconfig | 2 + include/configs/BSC9131RDB.h | 1 - include/configs/BSC9132QDS.h | 1 - include/configs/C29XPCIE.h | 3 -- include/configs/P1010RDB.h | 4 -- include/configs/P1022DS.h | 3 -- include/configs/p1_p2_rdb_pc.h | 3 -- 67 files changed, 206 insertions(+), 17 deletions(-) -- 2.17.1

6 24

[U-Boot] [RFC] usb: ehci-mx6: Create MISC USB device wrapper
by Adam Ford 13 Aug '19

13 Aug '19

In preparation to support DM_USB_GADGET, this creates a misc device which binds the host. This is necessary because U_BOOT_DRIVER(usb_mx6) is currently hard coded to UCLASS_USB and if we want to support UCLASS_USB_GADGET_GENERIC we'll need to bind a separate device in the future. Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index ba1e6bfa43..25c7e2d6a1 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -134,6 +134,7 @@ config USB_EHCI_MARVELL config USB_EHCI_MX6 bool "Support for i.MX6 on-chip EHCI USB controller" + select MISC depends on ARCH_MX6 default y ---help--- diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c index 16abeef3b2..4003b8616f 100644 --- a/drivers/usb/host/ehci-mx6.c +++ b/drivers/usb/host/ehci-mx6.c @@ -19,6 +19,7 @@ #include <asm/mach-types.h> #include <power/regulator.h> #include <linux/usb/otg.h> +#include <dm/lists.h> #include "ehci.h" @@ -567,7 +568,6 @@ static const struct udevice_id mx6_usb_ids[] = { U_BOOT_DRIVER(usb_mx6) = { .name = "ehci_mx6", .id = UCLASS_USB, - .of_match = mx6_usb_ids, .ofdata_to_platdata = ehci_usb_ofdata_to_platdata, .probe = ehci_usb_probe, .remove = ehci_deregister, @@ -576,4 +576,30 @@ U_BOOT_DRIVER(usb_mx6) = { .priv_auto_alloc_size = sizeof(struct ehci_mx6_priv_data), .flags = DM_FLAG_ALLOC_PRIV_DMA, }; + +static int mx6_usb_wrapper_bind(struct udevice *dev) +{ + const void *fdt = gd->fdt_blob; + int node = dev_of_offset(dev); + const char *name = fdt_get_name(fdt, node, NULL); + int ret; + + ret = device_bind_driver_to_node(dev, + "ehci_mx6", + name, + offset_to_ofnode(node), + &dev); + if (ret) + pr_err("mx6_usb - Unable to bind USB host node\n"); + + return ret; +} + +U_BOOT_DRIVER(usb_mx6_wrapper) = { + .name = "mx6-usb-wrapper", + .id = UCLASS_MISC, + .of_match = mx6_usb_ids, + .bind = mx6_usb_wrapper_bind, +}; + #endif -- 2.17.1

2 2

[U-Boot] [PATCH 0/2] usb: kbd: implement special keys
by Heinrich Schuchardt 13 Aug '19

13 Aug '19

GRUB uses function keys. So we should support these with an USB keyboard. Provide support for F1-F12, Insert, Delete, Home, End, Page Up, Page Down. Simplify the code beforehand. Heinrich Schuchardt (2): usb: kbd: simplify coding for arrow keys usb: kbd: implement special keys common/usb_kbd.c | 81 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 61 insertions(+), 20 deletions(-) -- 2.20.1

3 7

[U-Boot] OMAP GPMC Controller U-Boot Class Type
by Adam Ford 13 Aug '19

13 Aug '19

I was curious to know if there is a recommendation for for what class should be used for the OMAP3's general purpose memory controller. It it a bus that is memory addressed with chip selects for various parts and has a variety of registers setup to determine the timings for the communication. Several OMAP3 devices use this bus for the NAND and NOR addressing as well as Ethernet. I'm considering adding some code to read the timings from the device tree to change the GPMC bus timings to match. The U-Boot defaults work, but I think they are a bit conservative, and I'd like to optimize the performance. Thanks, adam

2 1

[U-Boot] [PATCH] cros: Expand the Chromium OS documentation
by Simon Glass 13 Aug '19

13 Aug '19

The current documentation only covers how to chain-load U-Boot on a Chromebook. Add more information about the other ways to use U-Boot on Chromebooks. In particular it is again possible to build it with Chromium OS verified boot. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- doc/README.chromium | 296 ++++++++++++++-------------------- doc/README.chromium-chainload | 239 +++++++++++++++++++++++++++ 2 files changed, 356 insertions(+), 179 deletions(-) create mode 100644 doc/README.chromium-chainload diff --git a/doc/README.chromium b/doc/README.chromium index 45eaeced2d..096bc4f1f7 100644 --- a/doc/README.chromium +++ b/doc/README.chromium @@ -1,239 +1,177 @@ -Running U-Boot from coreboot on Chromebooks -=========================================== +Chromium OS Support in U-Boot +============================= -U-Boot can be used as a secondary boot loader in a few situations such as from -UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on -ARM platforms to start up the machine. +Introduction +------------ -This document aims to provide a guide to booting U-Boot on a Chromebook. It -is only a starting point, and there are many guides on the interwebs. But -placing this information in the U-Boot tree should make it easier to find for -those who use U-Boot habitually. +This describes how to use U-Boot with Chromium OS. Several options are +available: -Most of these platforms are supported by U-Boot natively, but it is risky to -replace the ROM unless you have a servo board and cable to restore it with. + - Running U-Boot from the 'altfw' feature, which is available on selected + Chromebooks from 2019 onwards (initially Grunt). Press '1' from the + developer-mode screen to get into U-Boot. See here for details: + https://sites.google.com/a/chromium.org/dev/chromium-os/poking-around-your-… + - Running U-Boot from the disk partition. This involves signing U-Boot and + placing it on the disk, for booting as a 'kernel'. See + README.chromium-chainload for information on this. This is the only + option on non-U-Boot Chromebooks from 2013 to 2018 and is somewhat + more involved. -For all of these the standard U-Boot build instructions apply. For example on -ARM: + - Running U-Boot with Chromium OS verified boot. This allows U-Boot to be + used instead of either or both of depthcharge (a bootloader which forked + from U-Boot in 2013) and coreboot. See below for more information on + this. - sudo apt install gcc-arm-linux-gnueabi - mkdir b - make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all -You can obtain the vbutil_kernel utility here: +U-Boot with Chromium OS verified boot +------------------------------------- - https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U +To obtain: + git clone https://github.com/sglass68/u-boot.git + cd u-boot + git checkout cros-master -Snow (Samsung ARM Chromebook) ------------------------------ +To build for sandbox: -See here: + UB=/tmp/b/chromeos_sandbox # U-Boot build directory + CROS=/home/sglass/cosarm # Chromium OS directory + make O=$UB/chromeos_sandbox_defconfig + make O=$UB -j20 -s VBOOT_SOURCE=$CROS/src/platform/vboot_reference \ + MAKEFLAGS_VBOOT=DEBUG=1 QUIET=1 -https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook +Replace sandbox with another supported target. +This produces $UB/image.bin which contains the firmware binaries in a SPI +flash image. -Nyan-big --------- - -Compiled based on information here: -https://lists.denx.de/pipermail/u-boot/2015-March/209530.html -https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big -https://lists.denx.de/pipermail/u-boot/2017-May/289491.html -https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card - -1. Build U-Boot - - mkdir b - make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all - - -2. Select a .its file - -Select something from doc/chromium which matches your board, or create your -own. - -Note that the device tree node is required, even though it is not actually -used by U-Boot. This is because the Chromebook expects to pass it to the -kernel, and crashes if it is not present. - - -3. Build and sign an image - - ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit - echo test >dummy.txt - vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ - --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ - --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ - --bootloader dummy.txt --pack u-boot.kpart - - -4. Prepare an SD card - - DISK=/dev/sdc # Replace with your actual SD card device - sudo cgpt create $DISK - sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK - sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK - sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk - - -5. Write U-Boot to the SD card +To run on sandbox: - sudo dd if=u-boot.kpart of=/dev/sdc1; sync + $UB/tpl/u-boot-tpl -d $UB/u-boot.dtb.out \ + -L6 -c "host bind 0 $CROS/src/build/images/cheza/latest/chromiumos_image.bin; vboot go auto" \ + -l -w -s state.dtb -r +To run on other boards: + Install image.bin in the SPI flash of your device + Boot your system -6. Start it up -Reboot the device in dev mode. Make sure that you have USB booting enabled. To -do this, login as root (via Ctrl-Alt-forward_arrow) and type -'enable_dev_usb_boot'. You only need to do this once. +Sandbox +------- -Reboot the device with the SD card inserted. Press Clrl-U at the developer -mode screen. It should show something like the following on the display: +Most Chromium OS development with U-Boot is undertaken using sandbox. There is +a sandbox target available (chromeos_sandbox) which allows running U-Boot on +a Linux machine completion with emulations of the display, TPM, disk, etc. - U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) +Running sandbox starts TPL, which contains the first phase of vboot, providing +a device tree and binding a Chromium OS disk image for use to find kernels +(any Chromium OS image will do). It also saves driver state between U-Boot +phases into state.dtb and will automatically ensure that memory is shared +between all phases. TPL will jump to SPL and then on to U-Boot proper. - Model: Acer Chromebook 13 CB5-311 - Board: Google/NVIDIA Nyan-big, ID: 1 +It is possible to run with debugging on, e.g. - Net: No ethernet found. - Hit any key to stop autoboot: 0 - Tegra124 (Nyan-big) # + gdb --args $UB/tpl/u-boot-tpl -d .... +Breakpoints can be set in any U-Boot phase. Overall this is a good debugging +environment for new verified-boot features. -7. Known problems -On the serial console the word MMC is chopped at the start of the line: +Samus +----- -C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 +Basic support is available for samus, using the chromeos_samus target. If you +have an em100, use: -This is likely due to some problem with change-over of the serial driver -during relocation (or perhaps updating the clock setup in board_init()). + sudo em100 -s -c W25Q128FW -d $UB/image.bin -t -r +to write the image and then boot samus (Power-Refresh). -9. Notes -To check that you copied the u-boot.its file correctly, use these commands. -You should see that the data at 0x100 in u-boot-chromium.fit is the first few -bytes of U-Boot: +Boot flow +--------- - hd u-boot-chromium.fit |head -20 - ... - 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +Verified boot starts in TPL, which selects the A or B SPL, which in turn selects +the A or B U-Boot. Then this jumps to the selected kernel. If anything goes +wrong, the device reboots and the recovery SPL and U-Boot are used instead. - hd b/nyan-big/u-boot.bin |head - 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| +More details are available here: + https://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-a… -The 'data' property of the FIT is set up to start at offset 0x100 bytes into -the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes -from the load address. If this changes, you either need to modify U-Boot to be -fully relocatable, or expect it to hang. +New uclasses +------------ -chromebook_jerry ----------------- +Several uclasses are provided in cros/: -The instruction are similar to those for Nyan with changes as noted below: + UCLASS_CROS_AUX_FW Chrome OS auxiliary firmware + UCLASS_CROS_FWSTORE Chrome OS firmware storage + UCLASS_CROS_NVDATA Chrome OS non-volatile data device + UCLASS_CROS_VBOOT_EC Chrome OS vboot EC operations + UCLASS_CROS_VBOOT_FLAG Chrome OS verified boot flag -1. Patch U-Boot +The existing UCLASS_CROS_EC is also used. -Open include/configs/rk3288_common.h -Change: - -#define CONFIG_SYS_TEXT_BASE 0x00100000 - -to: - -#define CONFIG_SYS_TEXT_BASE 0x02000100 - - - -2. Build U-Boot - - mkdir b - make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ - chromebook_jerry_defconfig all - - -3. See above - -4. Build and sign an image - - ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ - u-boot-chromium.fit - echo test >dummy.txt - vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ - --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ - --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ - --bootloader dummy.txt --pack u-boot.kpart - - -5. See above +Commands +-------- -6. See above +A new 'vboot' command is provided to run particular vboot stages. The most +useful command is 'vboot go auto', which continues where the last stage left +off. -7. Start it up +Note that TPL and SPL do not supports commands as yet, so the vboot code is +called directly from the SPL boot devices (BOOT_DEVICE_CROS_VBOOT). See +cros_load_image_tpl() and cros_load_image_spl() which both call +vboot_run_auto(). -Reboot the device in dev mode. Make sure that you have USB booting enabled. To -do this, login as root (via Ctrl-Alt-forward_arrow) and type -'enable_dev_usb_boot'. You only need to do this once. -Reboot the device with the SD card inserted. Press Clrl-U at the developer -mode screen. It should show something like the following on the display: +Config options +-------------- - U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) +The main option is CONFIG_CHROMEOS, which enables a wide array of other options +so that the required features are present. - Model: Google Jerry - Net: Net Initialization Skipped - No ethernet found. - Hit any key to stop autoboot: 0 +Device-tree config +------------------ -8. Known problems +Various options are available which control the operation of verified boot. +See cros/dts/bindings/config.txt for details. Most config is handled at run- +time, although build-time config (with Kconfig) could also be added fairly +easily. -None as yet. +Porting to other hardware +------------------------- -9. Notes +A basic port to samus (Chromebook Pixel 2015) is in a basic working state, +using the chromeos_samus target. Patches will likely be forthcoming in early +2019. Ports to an ARM board and coreboot (for x86 Chromebooks) are in the +dreaming state. -None as yet. +Tests +----- -Other notes -=========== +Chromium OS firmware has a very limited set of tests. The tests that originally +existed in U-Boot were not brought over to coreboot or depthcharge. -flashrom --------- +The U-Boot tests ('make check') do operate, but at present there are no +Chromium OS tests available. These will hopefully come together over time. Of +course the above sandbox feature provides a sort of functional test and can +detecte problems that affect the flow or particular vboot features. - Used to make a backup of your firmware, or to replace it. - See: https://www.chromium.org/chromium-os/packages/cros-flashrom +TO DO +----- +- Support for booting from coreboot (patches expected March 2019) +- Support for booting from an ARM board, e.g. bob -coreboot --------- -Coreboot itself is not designed to actually boot an OS. Instead, a program -called Depthcharge is used. This originally came out of U-Boot and was then -heavily hacked and modified such that is is almost unrecognisable. It does -include a very small part of the U-Boot command-line interface but is not -usable as a general-purpose boot loader. - -In addition, it has a very unusual design in that it does not do device init -itself, but instead relies on coreboot. This is similar to (in U-Boot) having -a SPI driver with an empty probe() method, relying on whatever was set up -beforehand. It can be quite hard to figure out between these two code bases -what settings are actually used. When chain-loading into U-Boot we must be -careful to reinit anything that U-Boot expects. If not, some peripherals (or -the whole machine) may not work. This makes the process of chainloading more -complicated than it could be on some platforms. - -Finally, it supports only a subset of the U-Boot's FIT format. In particular -it uses a fixed address to load the FIT and does not support load/exec -addresses. This means that U-Boot must be able to boot from whatever -address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting -in Depthcharge). In practice this means that the data in the kernel@1 FIT node -(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. +Simon Glass +sjg(a)chromium.org +7 October 2018 diff --git a/doc/README.chromium-chainload b/doc/README.chromium-chainload new file mode 100644 index 0000000000..45eaeced2d --- /dev/null +++ b/doc/README.chromium-chainload @@ -0,0 +1,239 @@ +Running U-Boot from coreboot on Chromebooks +=========================================== + +U-Boot can be used as a secondary boot loader in a few situations such as from +UEFI and coreboot (see README.x86). Recent Chromebooks use coreboot even on +ARM platforms to start up the machine. + +This document aims to provide a guide to booting U-Boot on a Chromebook. It +is only a starting point, and there are many guides on the interwebs. But +placing this information in the U-Boot tree should make it easier to find for +those who use U-Boot habitually. + +Most of these platforms are supported by U-Boot natively, but it is risky to +replace the ROM unless you have a servo board and cable to restore it with. + + +For all of these the standard U-Boot build instructions apply. For example on +ARM: + + sudo apt install gcc-arm-linux-gnueabi + mkdir b + make O=b/nyan_big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all + +You can obtain the vbutil_kernel utility here: + + https://drive.google.com/open?id=0B7WYZbZ9zd-3dHlVVXo4VXE2T0U + + +Snow (Samsung ARM Chromebook) +----------------------------- + +See here: + +https://www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook + + +Nyan-big +-------- + +Compiled based on information here: +https://lists.denx.de/pipermail/u-boot/2015-March/209530.html +https://git.collabora.com/cgit/user/tomeu/u-boot.git/commit/?h=nyan-big +https://lists.denx.de/pipermail/u-boot/2017-May/289491.html +https://github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13#copy-data-to-the-sd-card + +1. Build U-Boot + + mkdir b + make -j8 O=b/nyan-big CROSS_COMPILE=arm-linux-gnueabi- nyan-big_defconfig all + + +2. Select a .its file + +Select something from doc/chromium which matches your board, or create your +own. + +Note that the device tree node is required, even though it is not actually +used by U-Boot. This is because the Chromebook expects to pass it to the +kernel, and crashes if it is not present. + + +3. Build and sign an image + + ./b/nyan-big/tools/mkimage -f doc/chromium/nyan-big.its u-boot-chromium.fit + echo test >dummy.txt + vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ + --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ + --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ + --bootloader dummy.txt --pack u-boot.kpart + + +4. Prepare an SD card + + DISK=/dev/sdc # Replace with your actual SD card device + sudo cgpt create $DISK + sudo cgpt add -b 34 -s 32768 -P 1 -S 1 -t kernel $DISK + sudo cgpt add -b 32802 -s 2000000 -t rootfs $DISK + sudo gdisk $DISK # Enter command 'w' to write a protective MBR to the disk + + +5. Write U-Boot to the SD card + + sudo dd if=u-boot.kpart of=/dev/sdc1; sync + + +6. Start it up + +Reboot the device in dev mode. Make sure that you have USB booting enabled. To +do this, login as root (via Ctrl-Alt-forward_arrow) and type +'enable_dev_usb_boot'. You only need to do this once. + +Reboot the device with the SD card inserted. Press Clrl-U at the developer +mode screen. It should show something like the following on the display: + + U-Boot 2017.07-00637-g242eb42-dirty (May 22 2017 - 06:14:21 -0600) + + Model: Acer Chromebook 13 CB5-311 + Board: Google/NVIDIA Nyan-big, ID: 1 + + Net: No ethernet found. + Hit any key to stop autoboot: 0 + Tegra124 (Nyan-big) # + + +7. Known problems + +On the serial console the word MMC is chopped at the start of the line: + +C: sdhci@700b0000: 2, sdhci@700b0400: 1, sdhci@700b0600: 0 + +This is likely due to some problem with change-over of the serial driver +during relocation (or perhaps updating the clock setup in board_init()). + + +9. Notes + +To check that you copied the u-boot.its file correctly, use these commands. +You should see that the data at 0x100 in u-boot-chromium.fit is the first few +bytes of U-Boot: + + hd u-boot-chromium.fit |head -20 + ... + 00000100 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| + + hd b/nyan-big/u-boot.bin |head + 00000000 b8 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 |................| + + +The 'data' property of the FIT is set up to start at offset 0x100 bytes into +the file. The change to CONFIG_SYS_TEXT_BASE is also an offset of 0x100 bytes +from the load address. If this changes, you either need to modify U-Boot to be +fully relocatable, or expect it to hang. + + +chromebook_jerry +---------------- + +The instruction are similar to those for Nyan with changes as noted below: + +1. Patch U-Boot + +Open include/configs/rk3288_common.h + +Change: + +#define CONFIG_SYS_TEXT_BASE 0x00100000 + +to: + +#define CONFIG_SYS_TEXT_BASE 0x02000100 + + + +2. Build U-Boot + + mkdir b + make -j8 O=b/chromebook_jerry CROSS_COMPILE=arm-linux-gnueabi- \ + chromebook_jerry_defconfig all + + +3. See above + +4. Build and sign an image + + ./b/chromebook_jerry/tools/mkimage -f doc/chromium/chromebook_jerry.its \ + u-boot-chromium.fit + echo test >dummy.txt + vbutil_kernel --arch arm --keyblock doc/chromium/devkeys/kernel.keyblock \ + --signprivate doc/chromium/devkeys/kernel_data_key.vbprivk \ + --version 1 --config dummy.txt --vmlinuz u-boot-chromium.fit \ + --bootloader dummy.txt --pack u-boot.kpart + + +5. See above + +6. See above + +7. Start it up + +Reboot the device in dev mode. Make sure that you have USB booting enabled. To +do this, login as root (via Ctrl-Alt-forward_arrow) and type +'enable_dev_usb_boot'. You only need to do this once. + +Reboot the device with the SD card inserted. Press Clrl-U at the developer +mode screen. It should show something like the following on the display: + + U-Boot 2017.05-00649-g72acdbf-dirty (May 29 2017 - 14:57:05 -0600) + + Model: Google Jerry + Net: Net Initialization Skipped + No ethernet found. + Hit any key to stop autoboot: 0 + + +8. Known problems + +None as yet. + + +9. Notes + +None as yet. + + +Other notes +=========== + +flashrom +-------- + + Used to make a backup of your firmware, or to replace it. + + See: https://www.chromium.org/chromium-os/packages/cros-flashrom + + +coreboot +-------- + +Coreboot itself is not designed to actually boot an OS. Instead, a program +called Depthcharge is used. This originally came out of U-Boot and was then +heavily hacked and modified such that is is almost unrecognisable. It does +include a very small part of the U-Boot command-line interface but is not +usable as a general-purpose boot loader. + +In addition, it has a very unusual design in that it does not do device init +itself, but instead relies on coreboot. This is similar to (in U-Boot) having +a SPI driver with an empty probe() method, relying on whatever was set up +beforehand. It can be quite hard to figure out between these two code bases +what settings are actually used. When chain-loading into U-Boot we must be +careful to reinit anything that U-Boot expects. If not, some peripherals (or +the whole machine) may not work. This makes the process of chainloading more +complicated than it could be on some platforms. + +Finally, it supports only a subset of the U-Boot's FIT format. In particular +it uses a fixed address to load the FIT and does not support load/exec +addresses. This means that U-Boot must be able to boot from whatever +address Depthcharge happens to use (it is the CONFIG_KERNEL_START setting +in Depthcharge). In practice this means that the data in the kernel@1 FIT node +(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE. -- 2.20.1.495.gaa96b0ce6b-goog

2 4

[U-Boot] [PATCH v2 1/3] spl: mmc: support uboot image offset on main partition
by Baruch Siach 13 Aug '19

13 Aug '19

On Armada 38x platforms the ROM code loads SPL from offset 0 of eMMC hardware boot partitions. When there are no boot partitions (i.e. SD card) the ROM skips the first sector that usually contains the (logical) partition table. Since the generated .kwb image contains the main U-Boot image in a fixed location (0x140 sectors by default), we end up with the main U-Boot image in offset of 1 sector. The current workaround is to manually set CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR to 0x141 to compensate for that. This patch uses the run-time detected boot partition to determine the right offset of the main U-Boot partition. The generated .kwb image is now compatible with both eMMC boot partition, and SD card main data partition. Signed-off-by: Baruch Siach <baruch(a)tkos.co.il> --- v2: Rebase on top of current master --- common/spl/Kconfig | 12 ++++++++++++ common/spl/spl_mmc.c | 15 +++++++++++++-- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 5d6da5db89bc..e43eefe046bc 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -293,6 +293,18 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR Address on the MMC to load U-Boot from, when the MMC is being used in raw mode. Units: MMC sectors (1 sector = 512 bytes). +config SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET + hex "U-Boot main hardware partition image offset" + depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR + default 0x0 + help + On some platforms SPL location depends on hardware partition. The ROM + code skips the MBR sector when loading SPL from main hardware data + partition. This adds offset to the main U-Boot image. Set this symbol + to the number of skipped sectors. + + If unsure, leave the default. + config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION bool "MMC Raw mode: by partition" help diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index b3619889f794..72439c029f4a 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -49,6 +49,16 @@ static ulong h_spl_load_read(struct spl_load_info *load, ulong sector, return blk_dread(mmc_get_blk_desc(mmc), sector, count, buf); } +static __maybe_unused unsigned long spl_mmc_raw_uboot_offset(int part) +{ +#if IS_ENABLED(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR) + if (part == 0) + return CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET; +#endif + + return 0; +} + static __maybe_unused int mmc_load_image_raw_sector(struct spl_image_info *spl_image, struct mmc *mmc, unsigned long sector) @@ -312,7 +322,7 @@ int spl_mmc_load(struct spl_image_info *spl_image, static struct mmc *mmc; u32 boot_mode; int err = 0; - __maybe_unused int part; + __maybe_unused int part = 0; /* Perform peripheral init only once */ if (!mmc) { @@ -371,7 +381,8 @@ int spl_mmc_load(struct spl_image_info *spl_image, return err; #endif #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR - err = mmc_load_image_raw_sector(spl_image, mmc, raw_sect); + err = mmc_load_image_raw_sector(spl_image, mmc, + raw_sect + spl_mmc_raw_uboot_offset(part)); if (!err) return err; #endif -- 2.20.1

2 10