Orange Pi 5B Plus Boot

I took a look at these patches and found that they change only device tree sources and I got an idea. What if I just generate DTB using these patches and use it with Fedora kernel?

So, I’ve

  • checked out master branch of Linux kernel,
  • applied all these patches (they applied cleanly),
  • copied /boot/config-6.9.7-200.fc40.aarch64 into .config,
  • ran make menuconfig, make dtbs and then sudo make dtbs_install,
  • changed GRUB_DEFAULT_DTB variable in /etc/default/grub file and devicetree parameter in /boot/grub2/grubenv to the path of appropriate newly installed .dtb file relative to /boot directory,
  • rebooted —

and I’ve got thermal readings available through /sys/class/thermal/thermal_zone* using unpatched Fedora kernel. Great success!


For the life of me, I cannot get the eMMC working with the stock fedora kernel.
I get this message while booting:

[   14.315428] platform adc-keys-1: deferred probe pending: (reason unknown)
[   14.316051] platform feb20000.spi: deferred probe pending: (reason unknown)
[   14.316715] platform adc-keys-0: deferred probe pending: (reason unknown)
[   14.317316] platform fe2c0000.mmc: deferred probe pending: platform: wait for supplier /spi@feb20000/pmic@0/regulators/pldo-reg5

I’m not sure what’s going on… maybe it’s waiting for it to be powered on? I have a suspicion it’s related to edk2-rk3588 that I burned onto the SPI flash since the ubuntu install that I need to boot into get a working system seems to boot fine and bypasses the flash. But edk2-rk3588 is able to load and boot the fedora kernel and initramfs from eMMC just fine. You’re not using any device tree overlays, right?

On a related note, I do have fedora kernel packages based on the stock fedpkg kernel repo building for the rk3588 kernel rebased to v6.9.9, but they seem to have the same boot issue with the eMMC. Once I get the OPi5 Plus kernel building clean and booting, i’ll submit that kernel build to this COPR repo: rk3588 enablement

That’s strange. I use the edk2-rk3588 version 0.9.1 (download link in one of my previous messages). It boots Grub successfully, Grub boots kernel. Linux kernel was unable to detect eMMC, but I fixed it by specifying devicetree manually. Did you specify the correct devicetree?

my /etc/default/grub contains the line GRUB_DEFAULT_DTB=/dtb/rockchip/rk3588-orangepi-5-plus.dtb, confirmed it got written with grub2-editenv… I’m certain it’s working because I get output on the UART, whereas I wouldn’t before.

No, serial output doesn’t mean that you have correct DTB. It was working before I specified correct DTB, I even was getting an emergency shell on serial console.

I have no idea what went wrong with your setup.

I was also able to confirm the correct device tree loaded from within the dracut rescue shell by comparing the /sys/firmware/fdtvirtual file against what was in the /boot/dtb (which is symlinked to my v6.9.9 kernel) they were the same minus a few entries that grub automatically put in. I thought maybe that the device-tree was corrupted somehow, but that appears to not be the case.

Alright, at this point, I’m not sure if it’s a hardware, firmware, or software problem… tonight, I’m going to strip this thing down to the bare board with only emmc and then go from there.

it’s a stretch… but what are your edk2-rk3588 settings? also, your kernel cmdline?

Different question, are you using Fedora IOT or a different one?

I’m using standard Fedora Server for aarch64.

1 Like

Oh, I forgot one more thing. Not detecting eMMC can be caused by drivers missing in your initramfs image. This can happen if you were using a different kernel that had these drivers compiled in or under different names, so dracut was unable to do the right thing when building initramfs when you were using that kernel.

You can check whether this is the case this way:

  • install dracut-config-generic package,
  • regenerate initramfs using dracut -f,
  • reboot.

Ok! I’m booted. My initramfs had the rockchip drivers, but was missing the mmc-block driver. Manually added that to my dracut config and it booted. Thanks for suggesting that as a place to look, Oleg!

Right off the bat, cpufreq and mtdblock seem broken, it’s otherwise workable.

Glad that you succeeded.

Regarding mtdblock, I just did modprobe mtdblock, and /dev/mtdblock0 device file magically appeared. Then I copied contents of this device to a file, it appeared to be exactly 16MiB, containing GPT partition table (with protective MBR) with 512-byte sector and two partitions:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64            1023   480.0 KiB   8300  idbloader
   2            1024            7167   3.0 MiB     8300  uboot

How can I test cpufreq driver?

doh… yeah, I knew to try modprobing mtdblock, but I assumed it’d be loaded automatically like in ubuntu. That works.

For cpufreq, there is a kernel specific kernel-tools package that will give you the cpupower command.

To see the cpu frequency setting for each of the cpus (they’re coupled as groups on the rk3588, 2 for the high speed, 1 for the low power cpus) cpupower -c 0,1,2,3,4,5,6,7 frequency-info

I see a potential clue in the dmesg log.
[ 26.088834] platform cpufreq-dt: deferred probe pending: (reason unknown)
similar to the mmc messages I got earlier.

Yes, I have exactly the same message in kernel log.

Added server and removed iot