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!
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 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?
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.
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.
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
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.
Using kernel as a base, I have SRPMs and RPMs building for kernel v6.10.0 that contain the collabora patchset. I’m going through the motions to setup a COPR repo to track these packages, but I’m honestly struggling a little bit on how to actually do that.
To push to a fork that I made, I apparently need to be in the fedora packagers group. So, I’ve applied for sponsorship. I can send out what I have on request until I creds to push.
This was denied, I think there was confusion that I wanted to create a competing kernel in the normal Fedora repo despite stating that this is for COPR only. So I’m not sure what to do at this point. If someone knows the proper way to setup a COPR build for this, I could use a hand. The existing documentation doesn’t seem very clear to me.
Hi. Has there been any progress on this since the last reply? I have an Orange Pi 5 Plus, and I’d be happy to help with testing and such to make Fedora a stable distro option for it.
As far as I’ve gathered from this thread:
I need to flash edk2-rk3588 to the SPI to enable GRUB, and GRUB can then boot Fedora kernels.
Then I need to DTB manually by putting GRUB_DEFAULT_DTB in /etc/default/grub so that eMMC is recognized by the kernel. devicetree=/dtb/rockchip/rk3588-orangepi-5-plus.dtb needs to be in /boot/grub2/grubenv.
I should add console=ttyS2,1500000n8 to the kernel arguments, because the Orange Pi 5 Plus uses ttyS2.
To get thermal readings available through /sys/class/thermal/thermal_zone*, I need to apply the patches from here to the latest kernel
Copy /boot/config-{kernel version}.fc40.aarch64 into .config
Run make menuconfig, make dtbs, and sudo make dtbs_install to compile those patches into the latest kernel.
Ensure GRUB_DEFAULT_DTB in /etc/default/grub and devicetree in /boot/grub2/grubenv has the path to the newly installed .dtb file relative to the /boot directory.
Reboot, and I should have thermal readings.
If eMMC is not detected, it could be because the drivers are missing from the initramfs image. So I would install dracut-config-generic and regenerate the initramfs, and then reboot.
Run modprobe mtdblock to ensure /dev/mtdblock0 device is detected.
I have a serial to USB so I can access the serial console, but the last user to reply on this thread mentioned they don’t have HDMI output. Do virtual consoles work? How do we go about implementing and testing this?