Mainline U-Boot with SPI, NVMe and SATA boot support
#41
Let me know if you need someone to test the u-boot Smile
Sorry for any mistakes. English is not my native language

1. RP64 v2.1 / PCIe SATA JMS585 Chipsatz / Booting from an 2,5 Zoll SSD on port 5/ 2 * 3,5 Zoll 4TB HDD (raid1) md0 / 2 * 2,5 Zoll 2TB HDD (raid1) md1 / using as NAS / Kernel 5.6.0-1137-ayufan-ge57f05e7bf8f

2. RP64 v2.1 / testing.....testing....testing 

https://forum.frank-mankel.org/category/14/rockpro64
  Reply
#42
(07-11-2020, 10:21 AM)sigmaris Wrote:
(07-07-2020, 02:33 PM)ChrisS Wrote: ...
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?   Undecided Of course I will Big Grin
  Reply
#43
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.
  Reply
#44
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?
  Reply
#45
(07-26-2020, 05:33 AM)sigmaris Wrote: 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?


Attached Files
.zip   u-boot log-USB3.zip (Size: 2.14 KB / Downloads: 5)
  Reply
#46
(07-26-2020, 05:20 PM)belfastraven Wrote:
(07-26-2020, 05:33 AM)sigmaris Wrote: 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.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  4pin Connector for dual SATA m.ekstrom 4 377 07-28-2020, 07:07 AM
Last Post: mabs
  RockPro64 eMMC boot euu 2 418 07-22-2020, 11:44 PM
Last Post: euu
  RockPro64 so problematic! Boot issues PorterDon 1 310 06-04-2020, 12:25 PM
Last Post: dukla2000
  Failure to boot atcwells 1 247 05-10-2020, 03:06 PM
Last Post: atcwells
  RockPro 64 V2.1 Boot problem only DDR Version ... message nutilius 5 630 05-02-2020, 03:26 AM
Last Post: freeviv
  micro SD Card Slot Spring not working, Cant boot mjembd 1 188 04-16-2020, 12:30 AM
Last Post: mjembd
  sw4 jumper for disabling eMMC boot / multiboot ChriChri 0 209 03-09-2020, 08:54 AM
Last Post: ChriChri
  Defective? PCI-E -> SATA card no work good unregisteredidiot 11 2,250 02-19-2020, 09:08 AM
Last Post: fysa
  USB Type-C Display cable support (for 2 in 1: Video + Power) Paprika88 0 211 02-12-2020, 06:47 AM
Last Post: Paprika88
  rockpro64 support in the rockchip uboot dedoz 0 291 01-13-2020, 01:51 PM
Last Post: dedoz

Forum Jump:


Users browsing this thread: 1 Guest(s)