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

[LMM]

you have not disabled emmc by jumpering the sw4 switch https://wiki.pine64.org/index.php/ROCKPr...sable_eMMC?
irrelevant because kernel 4.4 works

you could eventually erase the spi with the ayufan spi or sigmaris erase image.

[MisterA]

you have not disabled emmc by jumpering the sw4 switch https://wiki.pine64.org/index.php/ROCKPr...sable_eMMC?
irrelevant because kernel 4.4 works

you could eventually erase the spi with the ayufan spi or sigmaris erase image.

I erased the spi and get the same result trying to boot from eMMC.
As expected booting from USB doesn't work anymore either.

reflashed the spi and:
- boot from eMMC fails again
- boot from USB works

[LMM]

you have not disabled emmc by jumpering the sw4 switch https://wiki.pine64.org/index.php/ROCKPr...sable_eMMC?
irrelevant because kernel 4.4 works

you could eventually erase the spi with the ayufan spi or sigmaris erase image.

I erased the spi and get the same result trying to boot from eMMC.
As expected booting from USB doesn't work anymore either.

reflashed the spi and:
- boot from eMMC fails again
- boot from USB works

Last try, after i am stuck (but I am really pessimistic):
- launch armbian kernel 4.4 which is working
- copy u-boot to spi :
launch armbian-config
    in menu : system > hardware > Install >    Install/update the bootloader on spi flash

In this case the board will use the 4.4 bootloader since it is in written in the spi and then boot the 5.x kernel

An other try is to use the ayufan u-boot if the problem comes from the bootloader

my board version is v2.1 2018-07-02 which is newer than yours

You also may try with nvme if you have one (usb works, perhaps nvme also works). The ssd nvme speed is higher than emmc speed. But ssd nvme 256G is around 30$-40$ and the pcie adapter card is around 10$ ... and is is not sure it will work ! I tried samsung evo, and pny xlr8 they work well with the pine64 pcie adapter. I am not sure it worth trying.

[Mentaluproar]

I managed to build mainline 2021.07 boot and get it running on the rockpro64.  Unfortunately, I'm not smart enough to tie in your features with the mainline (SATA boot, HDMI console support, etc).  Any pointers while I try to learn this?

[runyor]

I have an AHCI adapter with two SSDs mounted on it. Eventually I want to set them in RAID1.
Debian installation was flawless, installed on sda, sdb was available as well.
After rebooting post installation, when u-boot starts I get this output and an infinite boot loop:



Any idea what is going on? Thanks!

[i3master]

I have an AHCI adapter with two SSDs mounted on it. Eventually I want to set them in RAID1.
Debian installation was flawless, installed on sda, sdb was available as well.
After rebooting post installation, when u-boot starts I get this output and an infinite boot loop:



Any idea what is going on? Thanks!

I encountered this issue using the SATA adapter ASMedia Technology Inc. Device 1064 (rev 02) on a ROCKPRO64. However, it seems that compiling the latest version of u-boot fixed this issue (specifically, it worked in version 2023.04).
It is fairly easy to compile this on Manjaro ARM on the ROCKPRO64 itself (because I believe all dependencies are in the official repos). On Arch Linux ARM, you will have to compile arm-none-eabi-gcc and arm-none-eabi-newlib on your own, which is not very easy, but is possible (let me know if you want instructions on this).

1. So, to compile on Manjaro, install the following packages:

Code:

sudo pacman -S bc git arm-none-eabi-gcc arm-none-eabi-newlib python-setuptools swig dtc python-pyelftools

2. Download and compile the ARM Trusted Firmware (start in some known folder, like your home directory):

Code:

wget https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/snapshot/trusted-firmware-a-lts-v2.8.6.tar.gz
tar -xvf trusted-firmware-a-lts-v2.8.6.tar.gz
cd trusted-firmware-a-lts-v2.8.6
make distclean
make -j6 PLAT=rk3399 bl31

3. Download and compile u-boot (start in the same known folder, like your home directory):

Code:

wget https://ftp.denx.de/pub/u-boot/u-boot-2023.04.tar.bz2
tar -xvf u-boot-2023.04.tar.bz2
# Copy over the bl31 file from the ARM Trusted Firmware and rename to atf-bl31 since that is what u-boot looks for.
cp trusted-firmware-a-ltx-v2.8.6/build/rk3399/release/bl31/bl31.elf u-boot-2023.04/atf-bl31
cd u-boot-2023.04
make distclean

# set some custom config options in u-boot
make rockpro64-rk3399_defconfig

# For Arch Linux ARM, but you can set a custom string if you want.
echo 'CONFIG_IDENT_STRING=" Arch Linux ARM"' >> .config

# Enable support for device tree overlay files. You can skip this if you don't use device tree overlays.
echo 'CONFIG_OF_LIBFDT_OVERLAY=y' >> .config

# Enable SATA support (specifically the 'sata' command in the u-boot command line).
echo 'CONFIG_CMD_SATA=y' >> .config

# Test flags - I enabled these during build because they seemed interesting, but I don't think they do anything useful here.
echo 'CONFIG_SATA_BOOT=y' >> .config
#echo 'CONFIG_SPL_SATA=y' >> .config
echo 'CONFIG_SYS_SATA_MAX_DEVICE=10' >> .config

make -j6 EXTRAVERSION=-1

4. Install u-boot to your ROCKPRO64. In the code below, I copy u-boot to the emmc module. This will overwrite the existing version on the emmc module. You can restore it later by reflashing an OS (from another PC) to the emmc module or Micro SD card (if you are using one) or just be re-copying the original u-boot.itb and idbloader.img to the emmc module and Micro SD card. The following commands assume you start out in the same known folder, which could be your home directory.

Code:

cd u-boot-2023.04

# These require root permission because you are directly writing to blocks on the emmc module.
sudo dd if=idbloader.img of=/dev/mmcblk2 seek=64 conv=notrunc
sudo dd if=u-boot.itb of=/dev/mmcblk2 seek=16384 conv=notrunc

Note that if you are using a Micro SD card, then I assume the 'of=' part would be 'of=/dev/mmcblk1'. You can check what is currently available by running 'lsblk'.

5. Now, reboot your ROCKPRO64. Keep pressing keys on your keyboard until you get a u-boot command line prompt. Run the 'pci' command to initialize the pci interface. Now, run the 'scsi scan' command to list scsi devices. The system should now not crash. If your SATA drive shows up, then you are good to continue booting (run the 'boot' command to continue booting as normal - you don't need to normally run these commands but it can be helpful when debugging).

[diederik]

I have an AHCI adapter with two SSDs mounted on it. Eventually I want to set them in RAID1.
Debian installation was flawless, installed on sda, sdb was available as well.
After rebooting post installation, when u-boot starts I get this output and an infinite boot loop:


Any idea what is going on? Thanks!

That looks like an odd u-boot version to me (for a Debian system). Where did it come from?
If you installed Debian Bullseye, it may be useful to try Debian Bookworm. While it's technically still Testing, we're about a month away from it becoming the new Stable.
At https://deb.debian.org/debian/dists/test...rd-images/ you can find Debian Installer Bookworm RC 2

[xlx]

Hello,

I tried to flash both this u-boot and also Tow-Boot to the spi of my RP64 v 2.1 but on both I have an issue that is very annoying. HDMI audio just doesn't work, which is very bad considering I basically use this RP64 as a little multimedia center connected to the TV. It boots without errors, I see the list of audio outputs detected (my HDMI TV among them and I'm using the last LibreELEC stable version, by the way) but there's no audio no matter if I boot LE from PXE or SD. If I just plug a phone on the RP64 audio output I get audio, which I believe proves that its something wrong related to the HDMI.

Video works right.

Is there anything I can do in order to fix it?

Any help would be appreciated.

[ChriChri]

I came across this post while looking for information on howto migrate my RockPro64 from booting off eMMC to booting off software raid on sata disks.

For whatever reason the version of u-boot mentioned here didn't work for me and I did some research into the topic until I ended up with a howto for myself to get this right without needing to have physical access to my RockPro64.

The part "without physical access" didn't work, because of a hardware issue and a weird software raid setup.

You can read about all this and here:

https://git.sr.ht/~chrichri/RockPro64_u-...RAID_howto

Following this guide you'd configure a software raid level 1, you'd install a version of u-boot into SPI that worked for one of my sata pcie adapters, you'd learn how to setup u-boot from within a running linux system and you'd get your RockPro64 to boot from a software raid.