Mainline U-Boot with SPI, NVMe and SATA boot support

[ChrisS]

...
Update 09/07/20:  Werhoo!!!  Having copied the prebuilt mmc_idbloader.img and mmc_u-boot.itb files from the link below:

              https://github.com/sigmaris/u-boot/relea...2020.01-ci

I can now boot from the NVMe drive, which by the way is a 250GB Kingston A2000.  So I guess that I have made a mistake with my copy of the build, which is not surprising given that I wasn't too sure how to use the azure-pipelines.yml script so I carried out my interpretation of it. Any tips on how to run this script would be greatly appreciated.  If I manage to get my copy of the build sorted then I shall look to try kicking things off from the SPI.

U-Boot mainline 2020.07 was released recently, and I've been working on an updated branch based on the mainline 2020.07 release: ci-2020.07-rockpro64-v3

Compared to 2020.01, more RK3399 drivers are in mainline now, including the PCI driver and NVMe support. The few patches I have added on top of 2020.07 are to enable serial console in TF-A, support booting from SATA AHCI, defining partitions of the SPI flash for Linux, and some scripts to erase or flash U-boot to the SPI.

The simplified gist of how the azure-pipelines.yml tells Azure how to build this branch would be

Code:

# clone arm-trusted-firmware from ARM
git clone https://github.com/ARM-software/arm-trusted-firmware.git
cd arm-trusted-firmware

# Clean and Build arm-trusted-firmware bl31.elf
make realclean
make -j$(getconf _NPROCESSORS_ONLN) CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31

# export environment variable BL31 containing the path to the built bl31.elf
export BL31=$(realpath build/rk3399/release/bl31/bl31.elf)

# change dir out of arm-trusted-firmware directory
cd ..

# clone my u-boot branch
git clone --single-branch --branch ci-2020.07-rockpro64-v3 https://github.com/sigmaris/u-boot.git

# change dir into u-boot
cd u-boot

# Clean and Configure U-Boot with rockpro64 default config
make mrproper
make rockpro64-rk3399_defconfig

# Build U-Boot
make -j$(getconf _NPROCESSORS_ONLN) CROSS_COMPILE=aarch64-linux-gnu-

# Make idbloader.img for MMC/SD
tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin mmc_idbloader.img

# Make idbloader.img for SPI
tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin spi_idbloader.img

At the end of this, you'll have three useful files: mmc_idbloader.img, spi_idbloader.img and u-boot.itb. These are to be written to MMC/SD or SPI flash as described in the first post in this thread (in 2020.07 there is no difference between the SPI and MMC u-boot.itb - the built u-boot.itb can be used in either).

One caveat about mainline U-Boot is that it requires the Linux kernel image to be uncompressed. Default builds of upstream Linux build a gzipped kernel, and you must gunzip it or patch the kernel to not build a gzipped kernel, like ayufan's kernel does here.

Thanks for taking the time to clarify the build steps.  Having carried out the above I can now report that I successfully booted from the NVMe drive via the SD u-bootloader.  At least I think that is what I did.  It is all so confusing lol.  Now, will I dare to try writing u-boot to the SPI flash?   Of course I will