Building Armbian Distribution with Kernel 6.10 for Orange Pi 5 Pro

[Sergey Dulimov]

Hi everyone!

I recently bought an Orange Pi 5 Pro and decided to install kernel 6.10 on it, as I wanted to take advantage of the new drivers available in this kernel. I found that the [Orange Pi 5 Pro page on the Armbian website](https://www.armbian.com/orange-pi-5-pro/) offers distributions with kernel 6.1, but not 6.10.

After trying to install kernel 6.10 via `armbian-config` on an already installed system, I encountered an issue: the system stopped booting.

### Questions and Requests for Help

1. **Support for Kernel 6.10 on Orange Pi 5 Pro**:
   - Am I correct in understanding that kernel 6.10 is currently not supported for my board?
   - Does anyone have information on whether support for kernel 6.10 for Orange Pi 5 Pro is planned in the future?

2. **Possibility of Installing Kernel 6.10**:
   - Is there any way to install kernel 6.10 on the Orange Pi 5 Pro? Has anyone already faced this challenge and can share their experience?

3. **Building Armbian Distribution with Kernel 6.10**:
   - I want to try building the Armbian distribution with kernel 6.10 from source. Can anyone share the configuration and instructions for compiling kernel 6.10 suitable for the Orange Pi 5 Pro?
   - What steps need to be taken to successfully build and install the kernel on this board?

If anyone has successfully built kernel 6.10 for the Orange Pi 5 Pro or has additional tips, please share! Any help would be greatly appreciated.

Thanks in advance for any assistance and advice! I hope my experience will be useful to other Orange Pi 5 Pro owners.

### Additional Information

Just in case, here is the link to the [Armbian page for Orange Pi 5 Pro](https://www.armbian.com/orange-pi-5-pro/).

Thank you!

[Efe Çetin]

OPi 5 Pro is not yet supported for 6.10 kernel and if you want it supported someone has the board needs to add its DT tohttps://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip-rk3588-6.10/dt. If you're interested in making the board work in mainline you can take https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip-rk3588-6.10/dt/rk3588s-orangepi-5.dts devicetree as reference. You need to adjust regulators, some devicetree nodes, properties etc.

[SteeMan]

Moved post to Community Maintained/Staging as this board is a Work In Process and not yet supported.

 

Note:  The typical way a new board gets introduced to Armbian, is the first step is to bring it in with the 'vendor' kernel.  Which is getting what the board manufacturer released building under Armbian.  Normally the board manufacturers don't support the OS for their boards so whatever gets released is likely never to be updated to anything newer.  And often the linux kernels they use are heavily patched and not close to mainline linux.  Then once that step is completed, the community (both Armbian and many others) work to incorporate all the custom code into mainline linux where hopefully it will be maintained going forward.  That can sometime take years and sometimes it never really happens as the board manufacturers rarely contribute to this (they move on to the next board and don't want to incur any costs to maintain older boards).  It also is rare that everything that worked under the vendor kernel will work under mainline (at least not for a long time).  And for all of this to occur there needs to be people willing to give of their time to volunteer to do all this as no one financially supports the ongoing maintenance of most SBC boards.

[allatutti]

Quote

You need to adjust regulators, some devicetree nodes, properties etc.

Is there any info what exactly is needed for armbian? When I take a look at decompiled dtb it had about 2500 lines of code, in metioned dts are only about 700 lines. Thank you

[salas]

@Sergey Dulimov Have you been able to make any progress ?

[salas]

@Efe ÇetinWhy DTB compiled for kernel 6.1 wont work in 6.10 kernel ? Should't that info about regulators, dt nodes , properties be the same?

Second question: If I take DTS source for 6.1 and compile using dt compiler of 6.10, should it work ?

[SteeMan]

3 hours ago, salas said:

@Efe ÇetinWhy DTB compiled for kernel 6.1 wont work in 6.10 kernel ? Should't that info about regulators, dt nodes , properties be the same?

Second question: If I take DTS source for 6.1 and compile using dt compiler of 6.10, should it work ?

Technically a DTS is specific to a kernel version.  As changes happen to the kernel apis, those need to be reflected in the DTS's.  So they DTB and kernel image are always built and shipped together.

 

Now in practice changes that impact the DTS aren't common, so you can usually use DTS's accross kernel versions.

 

However in this case, I'm assuming that when you refer to 6.1 that is a vendor kernel, and 6.10 or greater would be mainline kernel.  Now these are two very different code bases.  A vendor kernel is whatever the board/cpu vendor hacked together to get a kernel running on their hardware.  Often these are more android kernel based.  When features finally get rolled into mainline, their implementation is often completely different.  Thus one can't share a DTS between a vendor kernel and a mainline kernel.  But often you can use the vendor DTS to gather information about what needs to be implemented in the mainline DTS.

[C127]

Hello Armbian community,
 

I'm new to the forums and I'm currently working on adding support for the Orange Pi 5 Pro. I have developed a DTS file that enables support for this board on the EDGE kernel (currently v6.16).

Here is the current status of device support with my changes:
 

Working Features:

• Wireless & Bluetooth
• USB 2.0 (x3 ports)
• HDMI 2.1
• Gigabit Ethernet (via PCIe to RJ45 adapter - requires manual driver installation as it's not in the kernel)
• NVMe x2 (One slot tested with an NVMe drive, works perfectly. The other is used by the Ethernet adapter)
• GPIO PWM LEDs
• Audio CODEC (ES8388)
• GPU (with the latest Mesa drivers)
   

Not Yet Working (Work in Progress):

• USB 3.1
• HDMI output via USB-C DisplayPort Alt Mode
• NPU
   

Untested (Hardware unavailable to me):
These are expected to work but remain unconfirmed.

• Cameras
• Regulated FAN
• TouchScreen
• eMMC Flash
   

Not Sure:

• VPU (Unable to test due to lack of VAAPI support)

Additional Information:
I have successfully booted the board using u-boot version 2024.04, and it will likely work with newer versions as well.
 

Questions and Call for Collaboration:

I've based my work on the Armbian build system, patching the kernel, u-boot, and modifying the board configuration file. Now that the initial work is done, I have a few questions:

1.  Contribution Process: When my DTS and related changes are more mature, what is the proper procedure to submit them as a contribution to the official Armbian project?
2.  Testing: My build is based on the nightly branch. I am looking for volunteers to help test the image. Is there a specific forum section or process for sharing test images and gathering community feedback?
3.  Collaboration: I would greatly appreciate any help or collaboration, especially with getting USB 3.0 and DisplayPort (via USB-C) connectivity fully functional. If you're interested in helping, please let me know.

Thank you for your time and any guidance you can provide.

Repository:

U-boot Patch: https://github.com/c127dev/u-boot/tree/orangepi5pro-dev-2404
Kernel Patch: https://github.com/c127dev/linux/tree/orange-pi-5-pro-dev
Armbian build: https://github.com/c127dev/build/tree/orange-pi-5-pro-dev

[salas]

Hi @C127 Thanks for working on this board!

I have a few questions though.

Quote

Gigabit Ethernet (via PCIe to RJ45 adapter - requires manual driver installation as it's not in the kernel)

Where can I get that driver from ?

 

Quote

NVMe x2 (One slot tested with an NVMe drive, works perfectly. The other is used by the Ethernet adapter)

I did not really get this. My board has one single NVME slot for M.2 M cards.

 

Quote

HDMI output via USB-C DisplayPort Alt Mode

Isn't USB-C in this board only for power supply ?

 

 

Quote

eMMC Flash

I use eMMC cards. I am gonna check if I can boot using your kernel and uboot.

 

 

I just want to confirm you really mean orangepi 5 PRO variant.

 

I wonder If i could use your kernel patch directly against the mainline 6.15 or 6.16  kernel. When your job gets more mature it would be nice to try to port upstream.

 

 

[C127]

Hello @salas!

Thanks for the questions and your interest in testing! Let me clarify those points for you, as my initial explanation could have been clearer.
 

Quote

Where can I get that driver from?

The driver for the Ethernet adapter needs to be compiled from source. You can find the repository here:
https://github.com/dante1613/Motorcomm-YT6801/
 

Quote

NVMe x2 ... I did not really get this. My board has one single NVME slot for M.2 M cards.

You're right, my board also has only one user-accessible M.2 NVMe slot. My "NVMe x2" note was a bit confusing. According to the board schematics, the RK3588S SoC provides two NVMe interfaces. On this board, one is routed to the M.2 slot, and the other is internally wired to the chip that drives the RJ45 Ethernet port. So, only one is available for storage.
 

Quote

Isn't USB-C in this board only for power supply?

You are correct that the USB-C port is used for power delivery. However, based on the schematics, the USB-C controller's pins are also multiplexed. Some are routed for DisplayPort Alt Mode (which then goes to the HDMI port), while the remaining data lines are intended for USB 3.0. I am still investigating this part, so I'm not 100% certain yet, but that's what the hardware layout suggests.
 

Quote

I use eMMC cards. I am gonna check if I can boot using your kernel and uboot.

 

Thank you so much for offering to test with an eMMC card! That would be extremely helpful to confirm that it's working correctly.
To make it easier for you, I've just uploaded a pre-compiled image to the "Releases" section of my Armbian build repository. You can also build it yourself from the source, of course.
 

Quote

I just want to confirm you really mean orangepi 5 PRO variant.

 

And yes, to confirm, all my work is for the Orange Pi 5 Pro variant.
 

Quote

I wonder If i could use your kernel patch directly against the mainline 6.15 or 6.16 kernel.

 

Regarding your question about the kernel patch: it's currently based on the Armbian edge kernel tree (v6.16), which includes its own set of patches. It might not apply cleanly to a vanilla mainline kernel (like one from kernel.org) without some adjustments. However, the core DTS changes should be a great starting point for upstreaming the work once it's more mature. That's definitely the end goal!
 

Thanks again for your feedback!

[salas]

I will only be able to test it after july 10th when i return back home but I will get back here  as soon as I test it.

[Werner]

9 hours ago, C127 said:

1.  Contribution Process: When my DTS and related changes are more mature, what is the proper procedure to submit them as a contribution to the official Armbian project?

There are unfortunately no detailed instructions how to add new boards or board families to the build framework yet. This is a very extensive topic. However there are a few existing pull requests that should give clues like https://github.com/armbian/build/pull/7902/files

 

9 hours ago, C127 said:

2.  Testing: My build is based on the nightly branch. I am looking for volunteers to help test the image. Is there a specific forum section or process for sharing test images and gathering community feedback?

No, since it is community supported use Stating section for Rockchip devices in forums.

 

 

I did a quick check on your work.

- dts files which aren't upstreamed (yet) shall be added in full into the dt folder of the equivalent kernel patch directory (patch/kernel/archive/rockchip64-6.16/dt to say). You can use kernel-dtb build command to extract such a full tree.

- this also avoids my 2nd concern which is modifying the existing orangepi-5.dtsi and disabling nodes which where later re-added with another patch.

- if possible try to bump to latest mainline u-boot, so either v2025.04 or wait a bit longer for v2025.07 which is currently RC.

[C127]

Thank you for the response. I've reviewed the PR you linked, and based on that, I have created my own: https://github.com/armbian/build/pull/8348
 

I appreciate the review. I have fixed the issue with the unnecessary wrapper in my `orangepi5pro.csc` file and have also addressed the other recommendations.
 

Regarding the use of the latest U-Boot version, I did test it. However, it seems that with versions newer than 2024.04, U-Boot takes a very long time (~60 seconds) just to start the kernel. This is likely due to an issue from the refactoring that occurred after the 2024.04 release.
 

Thanks again for your guidance.

[salas]

@C127 

Quote

To make it easier for you, I've just uploaded a pre-compiled image to the "Releases" section of my Armbian build repository. You can also build it yourself from the source, of course.

any chance to make a release that already has the ethernet driver compiled and working ?

[whywontitwork]

@C127

 

Thank you for taking the time to try and make this work!

 

I tried running the image from your github on two of my Orange Pi 5 Pros, and unfortunately all I get is a solid white LED without any progress even after ~2-3 min. Joshua's 6.1 Ubuntu works fine. Any idea on what I need to do to make the Orange Pi 5 Pro boot with your image / build? Happy to help debug or enable you to make progress. Vulkan on an RK3588 board would be amazing!

[Werner]

9 hours ago, salas said:

any chance to make a release that already has the ethernet driver compiled and working ?

I added a suggestion at the PR how to implement the driver while building to allow network oob.

[C127]

Hello everyone.
 

@salas
I have just implemented the out-of-box (OOB) network driver functionality in a new commit to the repository. This should serve as a temporary patch for now (or potentially a permanent one, depending on if/when the driver gets mainlined into the Linux kernel).
 

@whywontitwork
 

Quote

I tried running the image from your github on two of my Orange Pi 5 Pros, and unfortunately all I get is a solid white LED without any progress even after ~2-3 min.

Thank you very much for the feedback and for testing the image. I need a bit more information to help track down the issue. My suspicion is that the system is successfully loading u-boot but failing to load the kernel. However, without debug logs, it's difficult to know the real cause.

To help diagnose this, could you please tell me how you flashed the image? I flash my builds to a microSD card using the Balena Etcher software. Are you using the same method or a different one?
 

I appreciate your support in getting the Orange Pi 5 Pro maintained! One of my main motivations for starting this project was to get Panthor support for the Mali GPU too. I can confirm that on my end, with the image I've built, the latest version of the drivers works correctly. Getting Vulkan and OpenGL running on an RK3588 board!

[salas]

@C127I tried to boot your image on orangepi5pro emmc card. It wont boot.

DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
ch0 ttot7
LPDDR5, 2400MHz
channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch1 ttot7
channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch2 ttot7
channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch3 ttot7
channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
Manufacturer ID:0xff
DQS rds:l0,l0 
CH0 RX Vref:26.7%, TX Vref:21.0%,21.0%
DQ rds:h3 h3 h2 h1 h4 h2 h2 h1, h1 h2 h3 h4 h1 h2 h2 h2 

DQS rds:l0,h1 
CH1 RX Vref:27.9%, TX Vref:20.0%,20.0%
DQ rds:l0 h2 h2 h3 h5 h3 h3 h6, h4 h2 h2 h2 h2 h1 h4 l0 

DQS rds:l0,l0 
CH2 RX Vref:26.7%, TX Vref:20.0%,20.0%
DQ rds:h3 l0 l0 l0 h4 h1 h7 h3, h1 l0 h1 l0 h2 h4 h1 h2 

DQS rds:l0,h1 
CH3 RX Vref:27.9%, TX Vref:22.0%,21.0%
DQ rds:h4 h4 h7 h4 h2 h2 h4 h3, h3 h3 h6 h2 h3 h1 h3 h1 

stride=0x2, ddr_config=0x6
hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x2000
change to F1: 534MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F2: 1320MHz
ch0 ttot8
ch1 ttot8
ch2 ttot8
ch3 ttot8
change to F3: 1968MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F0: 2400MHz
ch0 ttot7
ch1 ttot7
ch2 ttot7
ch3 ttot7
out

U-Boot SPL 2024.04-armbian-2024.04-S2504-P83ae-H29de-Vbf83-Bb703-R448a (Jul 03 2025 - 17:49:57 +0000)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

 

[salas]

@C127Boot from the  sdcard boots, although with some minor things:

1) First boot spent 1 minute in "Starting kernel message"

2) ssh does not generate the host ssh keys on first boot. So no way to login using ssh until someone manually run ssh-keygen -A.  I think this is more a armbian bug maybe.

3) I am gonna test a few extra things.

 

The image looks great, although missing the emmc card boot

 

[Werner]

32 minutes ago, salas said:

1) First boot spent 1 minute in "Starting kernel message"

Probably due to automatic file system expansion across the sdcard.

32 minutes ago, salas said:

2) ssh does not generate the host ssh keys on first boot. So no way to login using ssh until someone manually run ssh-keygen -A.  I think this is more a armbian bug maybe.

That's a known issue that pops up every now and then for a few years now. I guess this wasn't mitigated enough yet or the cause not determined yet.

[C127]

Hello @salas

Thanks a lot for testing and for the eMMC boot log! That's super helpful.
I'm ready to tackle the eMMC boot issue. As you saw, it's failing very early in the U-Boot SPL, so it's definitely a hardware initialization problem.
I'm creating a new fork to add a patch for this (Patch >=v0.4). Since I can't test it myself (I don't own an eMMC module), I would need your help to flash and test the new images. With a bit of luck and your feedback, we should be able to get it working.
 

[salas]

I will gladly help you to test it.

Just to let you know,  on 0.3 apparently If i boot from the sdcard, after booting the emmc is available. So the kernel knows about it. just uboot does not ?

Edited 7 hours ago by salas

[salas]

I will flash the new image now and let you know what happens,

[salas]

@C127 0.4 output. Still no boot

DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
ch0 ttot7
LPDDR5, 2400MHz
channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch1 ttot7
channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch2 ttot7
channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch3 ttot7
channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
Manufacturer ID:0xff
DQS rds:h1,l0 
CH0 RX Vref:24.6%, TX Vref:21.0%,21.0%
DQ rds:h4 h2 h1 h2 h1 h5 l0 h7, h1 h1 h3 h3 h1 h1 h7 l0 

DQS rds:l0,h2 
CH1 RX Vref:27.9%, TX Vref:21.0%,21.0%
DQ rds:h4 l0 h2 h3 h7 l0 h7 l0, h6 h5 h4 h5 l1 h1 h6 h6 

DQS rds:l0,h2 
CH2 RX Vref:25.0%, TX Vref:21.0%,21.0%
DQ rds:h1 l0 h2 l3 h1 h2 h5 h1, l1 h7 l1 h4 l2 h1 h1 h3 

DQS rds:l0,h1 
CH3 RX Vref:27.5%, TX Vref:21.0%,21.0%
DQ rds:h3 h1 h2 h1 h4 h1 h1 h1, h5 h6 h2 h2 h4 h4 l0 h5 

stride=0x2, ddr_config=0x6
hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x2000
change to F1: 534MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F2: 1320MHz
ch0 ttot8
ch1 ttot8
ch2 ttot8
ch3 ttot8
change to F3: 1968MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F0: 2400MHz
ch0 ttot7
ch1 ttot7
ch2 ttot7
ch3 ttot7
out

U-Boot SPL 2024.04-armbian-2024.04-S2504-P83ae-H29de-Vbf83-Bb703-R448a (Jul 03 2025 - 17:49:57 +0000)
Trying to boot from MMC1
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

 

Edited 7 hours ago by salas

[salas]

Post not related to 0.4!

 

Since yesterday I've been doing a few tests on your kernel patch against mainline kernel 6.16-rc5. here what I found out.

I am testing against Johsua's ubuntu because this is my goal ( newer kernel on that image )

1) Kernel compile and works , but I get a few warnings on the dtbs compilation

  DTC     arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dtb
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts:235.3-13: Warning (reg_format): /mmc@fe2d0000/wifi@1:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts:233.17-241.4: Warning (avoid_default_addr_size): /mmc@fe2d0000/wifi@1: Relying on default #address-cells value
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts:233.17-241.4: Warning (avoid_default_addr_size): /mmc@fe2d0000/wifi@1: Relying on default #size-cells value

 

2) Your patch works and makes the system bootable from the SDCARD. U-boot reads the /boot from the sdcard, since it can not find the EMMC, but after booting I can have to / on the EMMC and that works.

3) Curiously after the uboot handoff to the linux kernel, emmc is available but the sdcard fails to initialize

Quote

[   10.201606] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[   11.640919] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000)
[   11.678383] mmc0: error -110 whilst initialising SD card
[   12.933858] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000)
[   12.948524] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
[   14.235738] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000)
[   14.250377] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
[   15.419285] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000)

 

emmc initialize just fine with the /

[   10.225763] mmc2: new HS400 Enhanced strobe MMC card at address 0001
[   10.228424] mmcblk2: mmc2:0001 A3A564 233 GiB
[   10.233239]  mmcblk2: p1 p2
[   10.234373] mmcblk2boot0: mmc2:0001 A3A564 4.00 MiB
[   10.237884] mmcblk2boot1: mmc2:0001 A3A564 4.00 MiB

 

 

 

So I basically have a working system but it requires the sdcard to boot and I can not mount the sdcard after boot

 

root@pi5pro1:~# uname -r
6.16.0-rc5
root@pi5pro1:~# cat /etc/os-release 
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

 

Edited 6 hours ago by salas

[C127]

Hello @salas,

Thank you for the incredibly detailed testing and analysis!
You are absolutely right, the problem is entirely aligned with U-Boot. Your observation that the kernel can see the eMMC after booting from the SD card is the key. It proves the hardware is fine and the kernel's eMMC driver is working correctly. The issue is that the U-Boot SPL (Secondary Program Loader) is not initializing the eMMC interface properly at boot time.
Based on this, I've created a new patch (v0.5) that specifically targets this U-Boot initialization problem. I have adjusted the U-Boot device tree in an attempt to correctly enable the eMMC interface during the SPL phase.
I have just updated the pre-compiled image in the "Releases" section of my build repository to v0.5.

Thanks again for your amazing help!

[salas]

@C127 Tested, same problem

 

DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
ch0 ttot7
LPDDR5, 2400MHz
channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch1 ttot7
channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch2 ttot7
channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
ch3 ttot7
channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=4096MB
Manufacturer ID:0xff
DQS rds:h1,l0
CH0 RX Vref:24.6%, TX Vref:23.0%,22.0%
DQ rds:h5 h2 h1 h2 h1 h5 l0 h7, h1 h1 h3 h3 h1 h1 h7 l0

DQS rds:l0,h2
CH1 RX Vref:27.9%, TX Vref:21.0%,21.0%
DQ rds:h5 l0 h2 h2 h6 l0 h7 l0, h7 h5 h4 h4 l1 h1 h6 h7

DQS rds:l0,h2
CH2 RX Vref:25.4%, TX Vref:22.0%,21.0%
DQ rds:h1 l0 h2 l2 h1 h1 h5 h1, l1 h7 l2 h4 l2 h1 h1 h3

DQS rds:l0,h1
CH3 RX Vref:27.9%, TX Vref:21.0%,21.0%
DQ rds:h3 h1 h1 h1 h4 h1 h1 h1, h5 h6 h2 h2 h3 h5 l0 h5

stride=0x2, ddr_config=0x6
hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x2000
change to F1: 534MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F2: 1320MHz
ch0 ttot8
ch1 ttot8
ch2 ttot8
ch3 ttot8
change to F3: 1968MHz
ch0 ttot6
ch1 ttot6
ch2 ttot6
ch3 ttot6
change to F0: 2400MHz
ch0 ttot7
ch1 ttot7
ch2 ttot7
ch3 ttot7
out

U-Boot SPL 2024.04-armbian-2024.04-S2504-Pdd14-H29de-Vbf83-Bb703-R448a (Jul 11 2025 - 23:38:46 +0000)
Trying to boot from MMC2
Card did not respond to voltage select! : -110
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

 

[salas]

Actually  the 0.4 was trying to boot from MMC1 and the 0.5 from MMC2. is this expected ?

[C127]

You are right, I was too focused on the eMMC. The fact that sdio is used for WiFi/BT on this board suggests a more complex problem with the main SDHCI controller in U-Boot.
This means my U-Boot patch is still in a very early stage, and I need to do a deeper analysis of how all these interfaces are powered and configured.

I will continue working on it and will let you know when I have a new patch to test.

[salas]

Sure. I am here to test it when you send.

Next week I will be off for about 7 days, but we can test until that after that.