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

[Bullet64]

Let me know if you need someone to test the u-boot

[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

[sigmaris]

I've made another build based on 2020.07 using this branch, with a couple of additional patches:

Patch from Tian Yuanhao which allows compressed (gzip, etc) kernels to be loaded. No need to gunzip the default arm64 kernels to load them with u-boot anymore.
Patch from Jagan Teki which is supposed to enable USB-3 support on the USB-3.0 type A port. When testing this with the one USB-3 disk drive I have, it didn't seem to work, the disk drive wasn't detected in the USB-3.0 port. I'd be interested to hear if anyone else has success in using USB-3.0 devices in USB-3.0 mode with this. Note the USB Type C port is configured as OTG mode by default in the DTS, and so won't be used as a host port, so only the Type A port should be used for USB-3.0.

Build artifacts for MMC and SPI installation from this branch can be found here.

[Mentaluproar]

Is it possible to throw this work into some software repos so a Pacman or apt update could keep our bootloaders up to date with everything else?

[belfastraven]

I've made another build based on 2020.07 using this branch, with a couple of additional patches:

Patch from Tian Yuanhao which allows compressed (gzip, etc) kernels to be loaded. No need to gunzip the default arm64 kernels to load them with u-boot anymore.
Patch from Jagan Teki which is supposed to enable USB-3 support on the USB-3.0 type A port. When testing this with the one USB-3 disk drive I have, it didn't seem to work, the disk drive wasn't detected in the USB-3.0 port. I'd be interested to hear if anyone else has success in using USB-3.0 devices in USB-3.0 mode with this. Note the USB Type C port is configured as OTG mode by default in the DTS, and so won't be used as a host port, so only the Type A port should be used for USB-3.0.

Build artifacts for MMC and SPI installation from this branch can be found here.

This works fine for me with USB3--  I  have attached the u-boot logs from booting a SANDISK extreme stick and then a Samsung portable ssd T150.  I was booting from SPI .  I also booted my NVME,  which I removed in order to boot the other devices,  since that is first in the boot order.   When not booting from the USB3,  the kernel recognizes the USB3 devices, just FYI.   Is there anything in particular I could do to help you debug your issue?

[Mentaluproar]

I've made another build based on 2020.07 using this branch, with a couple of additional patches:

Patch from Tian Yuanhao which allows compressed (gzip, etc) kernels to be loaded. No need to gunzip the default arm64 kernels to load them with u-boot anymore.
Patch from Jagan Teki which is supposed to enable USB-3 support on the USB-3.0 type A port. When testing this with the one USB-3 disk drive I have, it didn't seem to work, the disk drive wasn't detected in the USB-3.0 port. I'd be interested to hear if anyone else has success in using USB-3.0 devices in USB-3.0 mode with this. Note the USB Type C port is configured as OTG mode by default in the DTS, and so won't be used as a host port, so only the Type A port should be used for USB-3.0.

Build artifacts for MMC and SPI installation from this branch can be found here.

This works fine for me with USB3--  I  have attached the u-boot logs from booting a SANDISK extreme stick and then a Samsung portable ssd T150.  I was booting from SPI .  I also booted my NVME,  which I removed in order to boot the other devices,  since that is first in the boot order.   When not booting from the USB3,  the kernel recognizes the USB3 devices, just FYI.   Is there anything in particular I could do to help you debug your issue?

Opposite experience for me here.  I did a fresh install of manjaro on a USB flash drive, ran all the updates and then installed from the link above.  Sata boot still works, but this breaks USB boot.  Not even USB2 boots properly now.  Both stick at "Booting using fdtblob at 0x1f0000000"

Was seeing this on the screen something we could have turned on before?  I prefer it to the blindly waiting for the OS to load.

[Mentaluproar]

Is there a way to get uboot to check all SATA devices for extlinux.conf? Right now, it only checks for the file on the first connected drive but for my setup, I need it to check the 3rd.

EDIT: Ayufan's mainline uboot does this. nvm

[clover]

It would be cool to see a similar mainline U-Boot project for Pinebook Pro.

Looking forward to seeing this come to the PBP

I patched sigmaris' project to support pinebook pro. I have the built binaries here: https://www.ironrobin.net/clover/droppy/...kPro/uboot
the source code is here: https://github.com/alexr4535/u-boot/tree...bookpro-v1

EDIT: LED on early boot now works and I haven't tested an SPI flash because i am not interested in that. SD card works, which is what I wanted.

[jja2000]

So from what I can tell the HDMI patch for u-boot has been merged. Is hdmi actually working now @sigmaris ? How about the usb-keyboard driver? What would need to be done to get that working?

[sigmaris]

So from what I can tell the HDMI patch for u-boot has been merged. Is hdmi actually working now @sigmaris ? How about the usb-keyboard driver? What would need to be done to get that working?

HDMI output and USB keyboard support are both enabled in mainline U-Boot.