Orange pi 5B - install to emmc doesnt work anymore. Armbian-install behaves oddly

[chall88]

I have attempted this with the vendor kernels and the mainline kernels, and they both do the same thing. The vendor kernel cannot see the EMMC at all after running updates on it. So that version would kill itself when updated even if it did install and boot off the emmc. The wifi also doesnt work on the mainline, so the options are mainline with no wifi or vendor with no emmc.


Install to SD card --> to through setup wizard --> change firmware to 5b instead of 5.-->  reboot --> armbian-install --> boot from emmc, system on emmc ---> spends a long time on counting files ---> file transfer screen flashes by in 1 second. --> shutdown ---> boot from emmc. ---> completely dead, the lights on the board never even flash green like they do with an SD inserted

This has worked in the past, many many versions ago, but it did not do this when it worked "spends a long time on counting files ---> file transfer screen flashes by in 1 second"

Files appear to be there though when mounting the filesystem. Correct uuids in the armbianEnv and fstab

I also attempted to just burn it from the sd to the emmc with dd, but that also didnt work

How can I load a current version of amrbian onto my emmc for the orange pi 5b?

[allatutti]

"spends a long time on counting files ---> file transfer screen flashes by in 1 second"
I will say is normal behaviour, I have same symptoms when moving sd 2 usb, but files are moved to usb.
In your case what will happen if your do change dtb from 5 to 5b and do reboot still with SD card, will it boot?

[chall88]

I always had the dtb set to 5b


I did manage to get it onto the emmc manually by using 2 SD cards

1. manually creating an ext4 on the emmc
2. I installed to SD
3. Installed again on a second SD

4. Booted off second SD
3. Attached the usb to SD reader
3. made a /mnt/old /mnt/new and rsync'ed the entire filesystem over to the emmc

4. adjusted the /boot/armbianEnv.txt on the booting SD card and the fstab on the emmc to point to the UUID of the emmc storage.

I cant boot off just the emmc, but this sort of uses the sd card as a springboard to load the stuff in emmc.

Anyways, armbian-install doesnt work on the 5b. The part that is failing seems to be the bootloading part. Whatever happens before /boot/armbianENV.txt is loaded, that part's broke for emmc 

Edited November 5, 2024 by chall88
me and the guy above posted at the same time

[chall88]

Downgrading the kernel from current or vender to the legacy-5.10.160 makes everything work properly.

By everything working i mean the wifi and the emmc, and the install to emmc.

I also discovered in my poking around that the current kernel regularly locks up the orange pi5b. It wont even respond to network traffic when it locks up.

Edited November 6, 2024 by chall88
more detail.

[Gerbil42]

I'm stuck in this same situation with the 5B.  Which image did you use with the legacy 5.10 kernel?

[chall88]

I loaded the vendor kernel(6.1) one, then I used armbian config to roll back to the 5.10 legacy kernel and then proceeded from there

IDK what happened but stuff really seemed to go off the rails with armbian on this specific board variant on the newer kernels

[chall88]

I did hook up a serial to it after installing to emmc. It's not lying in theis message. You have to flash it with the RKDEVTOOL in order to ahve any kind of functionality back from the emmc

 

[linhz0hz]

Can confirm the same issue.

[Matthijs Kooijman]

I'm also running into some issues with the eMMC. My path was a bit different: I was running some 24.x legacy version from eMMC. Because that had issues on reboot (related to some boot-from-usb changes I made to the u-boot script), I tried upgrading the bootloader to `linux-u-boot-orangepi5-current` (after setting `FORCE_UBOOT_UPDATE=yes` in `/etc/armbian-release` so the bootloader was actually installed - this worked ok for upgrading to the latest `linux-u-boot-orangepi5-legacy` version). After that, booting from eMMC no longer works:

 

DDR d5483af87d cym 23/11/23-16:15:24,fwver: v1.15
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
Manufacturer ID:0x1
CH0 RX Vref:29.3%, TX Vref:22.8%,21.8%
CH1 RX Vref:29.3%, TX Vref:20.8%,20.8%
CH2 RX Vref:29.7%, TX Vref:22.8%,22.8%
CH3 RX Vref:27.1%, TX Vref:22.8%,23.8%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out
U-Boot SPL board init
U-Boot SPL 2017.09 (Feb 25 2025 - 08:48:59)
sfc cmd=9fH(6BH-x4)
unrecognized JEDEC id bytes: ff, ff, ff
unknown raw ID ff ff ff
Trying to boot from MMC2
MMC: no card present
mmc_init: -123, time 0
spl: mmc init failed with error: -123
Trying to boot from MMC1
Card did not respond to voltage select!
mmc_init: -95, time 14
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
# Reset the board to bootrom #

 

Which seems to be the same output as posted by @chall88 above.

 

I thought this would be a matter of reinstalling the older bootloader onto the eMMC, but after booting a clean Armbian from SD-card (which works as expected), I noticed I could not actually access the eMMC anymore (yes, I set the dtb to orangepi5b, and even tried downgrading kernel and dtb to legacy by installing `linux-image-legacy-rk35xx linux-dtb-legacy-rk35xx`). Even an SD-card that I had lying around from earlier which I am certain could install to eMMC beforfe no longer saw it (no `/dev/mmcblk0` present).

 

I am quite surprised that writing data to the eMMC can prevent it from being recognized completely (on closer inspection I also see in the output above that the MMC1 (which I think is the eMMC, MMC2 is the SD-card) is actually not detected at all - "did not respond to voltage select"). However, I do see output from the SPL (which is the u-boot secondary program loader), meaning that the hardware *is* successful in loading the SPL from the eMMC, but then the SPL fails to init the eMMC/MMC1 somehow.

 

  On 11/9/2024 at 2:28 AM, chall88 said:

. You have to flash it with the RKDEVTOOL in order to ahve any kind of functionality back from the emmc

Expand  

 

I can't quite understand why, but maybe some low-level recovery of the eMMC contents is indeed needed as you also suggest here. Do you have any more pointers about this process? I found https://roc-rk3328-cc.readthedocs.io/en/latest/flash_emmc.html which seems like it could be relevant (it is about 3328, but I suspect it will also apply to 3588?).

 

I tried getting the board into rockusb mode with the recovery button, but that still showed the above output on serial. I did get it into maskrom mode by pressing the maskrom button on the board during powerup, and then I get a USB device when I connect to the OTG port (USB-C port on the corner for power, USB-C port in the middle for OTG connected to my PC).

 

I then tried the `rkdeveloptool` to try and replace the u-boot I messed up, but that tool sees the device, but then fails to send any commands to it it seems:

 

matthijs@zozo:/media/matthijs/armbi_root/usr/lib/linux-u-boot-legacy-orangepi5$ sudo ~/bin/rkdeveloptool ld
DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=304    Maskrom
matthijs@zozo:/media/matthijs/armbi_root/usr/lib/linux-u-boot-legacy-orangepi5$ sudo ~/bin/rkdeveloptool rci
Read Chip Info failed!
matthijs@zozo:/media/matthijs/armbi_root/usr/lib/linux-u-boot-legacy-orangepi5$ sudo ~/bin/rkdeveloptool wl 0x40 idbloader.img
Write LBA failed!
matthijs@zozo:/media/matthijs/armbi_root/usr/lib/linux-u-boot-legacy-orangepi5$ sudo ~/bin/rkdeveloptool wl 0x4000 u-boot.itb
Write LBA failed!

 

The commands above are based on https://roc-rk3328-cc.readthedocs.io/en/latest/flash_emmc.html#id5 and the `/usr/lib/u-boot$ cat platform_install.sh` script that messed up the u-boot install.

 

I skipped the `rkdeveloptool db` (DownloadBoot) command, which I originally thought might write the first 0x40 bytes, but reading on I actually suspect it would download a small bootloader to RAM that further handles initialization and processes commands. On the https://roc-rk3328-cc.readthedocs.io/en/latest/flash_emmc.html#id4 they talk about a rk3328_loader_xxx.bin image that is generated by the u-boot compilation, but it is not present in the Armbian u-boot packages it seems. It does link to the `rkbin` repo and looking around I did find this directory with rk3588 images: https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35 Based on the [README of rkdeveloptool](https://github.com/rockchip-linux/rkdeveloptool) which mentions "usbplug", I tried the rk3588_usbplug_v1.11.bin file, but that seems to fail:
 

~/bin/rkdeveloptool db rk3588_usbplug_v1.11.bin
Opening loader failed, exiting download boot!

 

It seems to fail to load the .bin file. Looking at the source, it likely does not find the appropriate signatures (see https://github.com/rockchip-linux/rkdeveloptool/blob/304f073752fd25c854e1bcf05d8e7f925b1f4e14/RKBoot.cpp#L244) in the first four bytes (assuming byte-swapping due to little endianness, the valid signatures would be "BOOT" and "LDR "). Looking through all rk3588 files in the rkbin repo, I find none with such signatures.

 

So I am a bit at a dead end here...

 

Anyone know what loader bin to use for the orangepi5? Or is there another route to recovering the eMMC contents?

 

And does anyone know *why* all eMMC access fails even from a booted SD card? Is this because even when running from SD, u-boot SPL still runs from eMMC and u-boot SPL is responsible for initializating eMMC (linux just assumes it is already initialized) or something?