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. Quartz64 Model B, 4GB RAM

2. Quartz64 Model A, 4GB RAM

3. RockPro64 v2.1

https://linux-nerds.org/
  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: 283)
  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
#47
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
  Reply
#48
(02-02-2020, 03:59 PM)sigmaris Wrote: It would be cool to see a similar mainline U-Boot project for Pinebook Pro.

(02-20-2020, 05:50 PM)Thovthe Wrote: 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.
  Reply
#49
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?
  Reply
#50
(09-17-2020, 11:45 AM)jja2000 Wrote: 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.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  enble boot after power loss/restore dkebler 18 8,944 12-04-2023, 12:14 PM
Last Post: ok38
Bug Broken boot: What am I missing? mkosarek 1 607 09-08-2023, 08:14 AM
Last Post: wdt
  Unable to boot Armbian on new RockPro64 mooseball 5 4,086 07-14-2023, 08:59 AM
Last Post: rockjonn
  no boot white led flashing moserwi 7 4,108 05-18-2023, 10:46 AM
Last Post: wdt
  u-boot locked on pine64pro ljones 1 1,477 09-06-2022, 10:32 AM
Last Post: ljones
  Cannot get my board to boot deutschlmao 11 7,829 09-05-2022, 04:23 PM
Last Post: ljones
  U-BOOT Tutorial hazz 0 1,109 07-19-2022, 10:48 PM
Last Post: hazz
  Installation Debian on emmc: which U-Boot and where? vongillus 3 2,676 07-02-2022, 09:24 AM
Last Post: dkebler
  ROCKPRO64 PCI SSD SD-boot Install pspgarret 0 1,116 06-09-2022, 10:56 AM
Last Post: pspgarret
  Support says "regulator" on the SBC burned out; how to fix? dmos 0 873 06-02-2022, 02:20 AM
Last Post: dmos

Forum Jump:


Users browsing this thread: 1 Guest(s)