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.

Right, then the suggestion about this error earlier in the thread was incorrect. I had seen it was wifi-related, but had assumed the same radio is used for wifi and bluetooth, so thought the error might have been related (though I suspected it was just a warning and a second firmware load would succeed, but mentions of it online were a bit confusing). Anyway, thanks for confirming!

I just tested a clean image, installed just `pi-bluetooth` and everything worked right way (hciconfig shows a bluetooth adapter and I can pair devices using gnome-settings right away). In particular, I do not need armbian-firmware-full, nor the firmware symlinks I discussed above. On closer inspection, I suspect that the firmware error message that we were seeing was just a first attempt at loading a raspberrypi4-specific firmware, but it already falls back to a generic firmware. In particular, looking at the OP's dmesg output (which matches my own), I see the following lines (unrelated lines were snipped): [ 9.387030] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2 [ 9.658798] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 9.658998] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 9.679093] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60 I think this means it first tries brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin, that fails, then it tries brcm/brcmfmac43455-sdio which succeeds. Also, I did not need to install bluetooth packages using armbian-config (those probably add support for other bluetooth stuff, basic keyboard and mouse already worked). Concluding: Installing `pi-bluetooth` is enough to make bluetooth work in a pi4, so that should probably be installed by default in this image (it is also a tiny image).

I suspect I do not have this package - it does seem like that package would indeed work, since it calls hciattach using this service and this script. I had seen mention of this package before, but I suspected it was something specific to Raspbian, or maybe Ubuntu itself, hadn't realized it would be available on armbian as well. I'll test to see if installing it helps and if so, we should probably install it by default (in the image, or in the armbian-config bluetooth set of packages maybe). I checked the kernel config, and the rpi image (bcm2711) already has those modules builtin, so that apparently does not work here (maybe that's a mainline feature to automatically do the hciattach, as you mention it does work automatically on mainline apparently).

Turns out running hciattach works: $ sudo hciattach /dev/ttyAMA0 bcm43xx [sudo] password for matthijs: bcm43xx_init Flash firmware /lib/firmware/brcm/BCM4345C0_003.001.025.0162.0000_Generic_UART_37_4MHz_wlbga_ref_iLNA_iTR_eLG.hcd Set Controller UART speed to 3000000 bit/s Device setup complete $ sudo hciconfig hci0: Type: Primary Bus: UART BD Address: E4:5F:01:3D:8E:21 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:928 acl:0 sco:0 events:69 errors:0 TX bytes:5491 acl:0 sco:0 commands:69 errors:0 After that, I can connect to my bluetooth keyboard using gnome settings as normal. What I did: - Install bluetooth with armbian-config - Install armbian-firmware-full - Create firmware symlinks - Run the hciattach command I'm not sure if all of these are really needed, I'll try with a clean image to be sure. If I can find the time, I'll also see if we can make this work out of the box somehow, by running the hciconfig command at startup (this pullrequest for sunxi adds a systemd service for this, I was thinking of a udev rule maybe). I also found this pullrequest for sunxi which makes some kernel modules builtin and then claims hciattach is not needed at all. Maybe also see how Raspbian does this...

I'm running into the same issue on my rpi4b (jammy gnome version), same messages in dmesg as DownUnder has, and no hci shown by `hciconfig` (so I assume the problem is indeed kernel-level). - Installing `armbian-firmware-full` does not help. It contains files named like the requested firmware, but .txt instead of .bin (which I guess might *also* be needed). These txt files are symlinks (which again link to other files): $ ls -l /lib/firmware/brcm/*raspberrypi,4-model-b* lrwxrwxrwx 1 root root 22 Jul 28 2022 /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt -> brcmfmac43455-sdio.txt -rw-rw-r-- 1 root root 1883 Feb 17 23:23 /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt.distrib lrwxrwxrwx 1 root root 22 Jul 28 2022 /lib/firmware/brcm/brcmfmac43456-sdio.raspberrypi,4-model-b.txt -> brcmfmac43456-sdio.txt - I found this thread where someone (for the rpi3) suggests adding rpi symlinks to the generic files, which I adapted for rpi4: sudo ln -s ../cypress/cyfmac43455-sdio.clm_blob brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob sudo ln -s ../cypress/cyfmac43455-sdio.bin brcmfmac43455-sdio.raspberrypi,4-model-b.bin This fixes the error in dmesg, but hciconfig still shows nothing. $ sudo dmesg|grep brcm [ 1.427393] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges: [ 1.427443] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff] [ 1.427529] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x063fffffff -> 0x00c0000000 [ 1.427621] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x007fffffff -> 0x0400000000 [ 1.492518] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC) [ 1.492963] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00 [ 8.509484] brcmfmac: F1 signature read @0x18000000=0x15264345 [ 8.530822] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 8.538523] usbcore: registered new interface driver brcmfmac [ 8.815847] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 8.823298] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60 - I found this post that suggests you need to run hciattach to set things up (I suspect the bluetooth adapter might be attached to serial and this creates a hci device talking to that serial?). I haven't tried this yet, though. To be continued, but I gotta run now, so this post is a bit rough, sorry for that.