[U-Boot] [PATCH] cros: Expand the Chromium OS documentation

[Tristan Bastian]

Hi Simon,

I'm using the nyan-big chromebook (tegra124).
Is it possible to replace coreboot + depthcharge with just u-boot on the internal spi flash?
If so, do you have some instructions for that?

At the moment I'm chainloading u-boot, but this is causing some issues with not working LPAE so I'm only getting 2 of my 4GB of memory..
So I would like to try and run u-boot natively to see if chainloading is the problem or u-boot itself..
Or maybe you have some instructions to run coreboot + u-boot without depthcharge?

Thanks,
Tristan


Simon Glass – Thu, 31. January 2019 4:52
> 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 at 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:
> + 
> sites.google.com/a/chromium.org/dev/chromium-os/poking-around-your-chrome-os-device
> 
> + - 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
> +-------------------------------------
> 
> - drive.google.com/open
> +To obtain:
> 
> + git clone 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
> 
> -
> 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:
> -lists.denx.de/pipermail/u-boot/2015-March/209530.html
> -git.collabora.com/cgit/user/tomeu/u-boot.git/commit/
> -lists.denx.de/pipermail/u-boot/2017-May/289491.html
> -github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13
> -
> -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 at 700b0000: 2, sdhci at 700b0400: 1, sdhci at 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:
> 
> + 
> www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery
> 
> -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: 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 at 1 FIT
> node
> -(see above) must start at the same address as U-Boot's CONFIG_SYS_TEXT_BASE.
> +Simon Glass
> +sjg at 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:
> +
> + drive.google.com/open
> +
> +
> +Snow (Samsung ARM Chromebook)
> +-----------------------------
> +
> +See here:
> +
> +
> www.chromium.org/chromium-os/firmware-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook
> +
> +
> +Nyan-big
> +--------
> +
> +Compiled based on information here:
> +lists.denx.de/pipermail/u-boot/2015-March/209530.html
> +git.collabora.com/cgit/user/tomeu/u-boot.git/commit/
> +lists.denx.de/pipermail/u-boot/2017-May/289491.html
> +github.com/chromeos-nvidia-androidtv/gnu-linux-on-acer-chromebook-13
> +
> +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 at 700b0000: 2, sdhci at 700b0400: 1, sdhci at 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: 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 at 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
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> lists.denx.de/listinfo/u-boot