Matthijs Kooijman

FYI: I managed to fix my eMMC again, I found a working spl_loader bin file to flash with rkdeveloptool. See the following post for details:

To add a datapoint: In the past, I've been succesfully installing to eMMC using `armbian-install` using an Armbian 24.2.1 Jammy image. IIRC I had to change the `ftdfile=` line in `/boot/armbianEnv.txt` (as documented at https://www.armbian.com/orangepi-5/) but it otherwise worked right away. Now recently I have been playing with newer bootloaders and images and kernels (in order to fix an issue where a reboot hangs), and in that process I updated the U-boot on the eMMC, which caused booting from eMMC to fail, and when booting from SD card, I no longer have the eMMC device so I cannot fix this (I think this might be exactly what @sns1081 describes in the first post of this topic). I've been trying to fix this (see this post for details), but on my previous attempt I could not get `rkdeveloptool` to work: it kept giving "Write LBA failed!" errors on on the `wl` command. I suspected this was because I needed the `db` (download bootloader) command first to download and run a bootloader to then handle the `wl` command, but I could not find the right spl_loader file. But with this thread (and in particular this post by @Andrius Vainorius) offered a filename I could google and then found it here: https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/ With that, at least the db and wl commands work: ❯ sudo ~/bin/rkdeveloptool db ~/Downloads/rk3588_spl_loader_v1.15.113.bin Downloading bootloader succeeded. ❯ sudo ~/bin/rkdeveloptool wl 0 some_img.img Write LBA from file (100%) For this, I cannected USB-C cable to the J11 USB connector in the middle, powered up via the USB-C connector in the corner and pressed the maskrom button on powerup. Note that it did not seem to be necessary to have the rkdeveloptool and the images to write in the same directory, as suggested by others here. Note that the the "some_img.img" is an image I lifted from an SD-card with Armbian 24.2.1 Jammy, so it is not the original clean image, but it does have the same stuff on it. Just the above commands recovered my board: It can boot from eMMC again and the /dev/mmcblk0 eMMC device is available again (both when booting from eMMC and when booting from SD). Analyzing why eMMC was broken before, I compared the serial output from the broken and fixed cases. The main difference is here seems to be the u-boot SPL version. AFAIU, this is what happens: Some ROM bootloader boots, which loads U-boot SPL from eMMC U-boot SPL checks SD-card and then eMMC to load the main U-boot Maybe there is another bootloader stage involved (between ROM and SPL, since there is some serial output before SPL shows up that is different between both cases). Here's a diff of the serial output between both cases (up to the moment where U-boot runs and no more interesting differences appear): --- old-opi5.txt 2025-07-02 21:20:08.631329154 +0200 +++ old-opi5-emmc-fixed.txt 2025-07-02 23:01:17.982196616 +0200 @@ -1,26 +1,24 @@ -üDDR d5483af87d cym 23/11/23-16:15:24,fwver: v1.15 +þDDR V1.11 f1474cf52f cym 23/05/09-11:02:36 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:28.9%, TX Vref:20.8%,21.8% +CH0 RX Vref:28.5%, TX Vref:23.8%,22.8% +CH1 RX Vref:29.3%, TX Vref:20.8%,20.8% CH2 RX Vref:29.3%, TX Vref:22.8%,21.8% -CH3 RX Vref:27.9%, TX Vref:20.8%,20.8% +CH3 RX Vref:26.7%, TX Vref:21.8%,21.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 -spl: partition error +U-Boot SPL 2017.09 (Feb 09 2024 - 18:56:36) +unknown raw ID 0 0 0 +unrecognized JEDEC id bytes: 00, 00, 00 +Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7efcd01a0f...) + OK @@ -29,7 +27,7 @@ ## Checking atf-2 0xff100000 ... sha256(1163474a5b...) + OK ## Checking atf-3 0x000f0000 ... sha256(da90adf3a4...) + OK Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) -Total: 304.579/460.237 ms +Total: 245.95 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-589-g3389cfdda:derrick.huang @@ -42,11 +40,10 @@ INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 -ERROR: dfs get fsp_params[0] error, 0xfead0004 != 0xfead0003 -ERROR: dfs get fsp_params[1] error, 0x1111 != 0xfead0003 -ERROR: dfs get fsp_params[2] error, 0x0 != 0xfead0003 -ERROR: dfs get fsp_params[3] error, 0x60241520 != 0xfead0003 -ERROR: loader&trust unmatch!!! Please update trust if need enable dmc +INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz +INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz +INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz +INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK @@ -67,18 +64,8 @@ CR: M/C/I Using default environment -no mmc device at slot 1 -Card did not respond to voltage select! -do_rkimg_test: dev_desc is NULL! mmc@fe2c0000: 0, mmc@fe2e0000: 1 -Card did not respond to voltage select! -PCIe-0 Link Fail - -Device 0: unknown device -Card did not respond to voltage select! -switch to partitions #0, OK -mmc0 is current device -Bootdev(scan): mmc 0 +Bootdev(atags): mmc 0 MMC0: Legacy, 52Mhz PartType: EFI DM: v2 Since in both cases, the main U-boot (Feb 09 2024) runs from the SD-card, I suspect that the U-boot SPL (or the preceding bootloader, if any) is somehow involved in setting up the eMMC properly, and the new one does not do the setup properly (or otherwise messes something up). Next things I could try are: Flash a recent Armbian image (different version/flavors) to eMMC using rkdeveloptool and see if any of those produce a working system/eMMC. Figure out how the boot process *really* works and what parts of the eMMC are loaded in what order and how Compare a working and broken armbian image (in the areas that contain bootloader-stuff) and swap out some of these parts to see what is the part that breaks it. However, my main issue is fixing reboots on the older armbian system we are using, so I might not get around to the above anytime soon (OTOH, it seems the newer U-boot SPL actually fixes the reboot issue, so that could motivate me to see if we can upgrade to the new u-boot version without losing eMMC).

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. 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?

For anyone else looking to patch their kernel through userpatches - it seems that (at least with the updated build system that uses the quite complex lib/tools/patching.py to apply patches) you can just drop a patch in `userpatches/kernel/archive/<platform>-<version>/` and it will be picked up (in my case, it was `userpatches/kernel/archive/sunxi-6.7`). No series file needed. I used a patch generated with `git format-patch`, but it seems that the script supports different formats, even mbox with multiple patches inside.