Has anyone had luck running Fedora 39 on the Orange PI 5B Plus? I’m able to get it to the EFI STUB while booting and then it hangs.
I understand that this is still a non-supported system but I’m willing to assist with a porting effort. Kernel 3.7 should have anything needed for bring up. I’m just missing a few things with how the whole EFI/stub works. Does anyone have pointers to get the kernel booting?
I suspect the Orange Pi 5 has the same issue as the Raspberry Pi 5. Fedora still does not support it since there are kernel issues that are being worked on.
Could you please provide more details about RK35xx support in Fedora 40?
I’ve upgraded Fedora on Rock-5B to release 40, but I still have to use a custom kernel: Fedora one doesn’t find EMMC, so system boots to emergency shell as a result.
This allows to boot GRUB that in turn is able to boot Fedora kernels and custom kernels I’ve installed.
Fedora kernels don’t detect EMMC, so booting process ends with rescue shell, no mmcblk* files in /dev directory.
Custom built kernel from GitHub - nyanmisaka/linux-rockchip branch rk-6.1-dev2 detects EMMC successfully, boot process results in fully functional Fedora.
I also have Orange Pi 5 Plus. The situation with it is essentially the same with some differences.
I use UEFI firmware downloaded from the same web page, but it boots from microSD card, not SPI flash. I’m not sure whether Orange Pi 5 Plus even has SPI flash, At least, flashing UEFI image using maskrom mode writes to EMMC, overwriting partition table and creating one special partition.
Fedora kernels detect no EMMC, no microSD as well, the custom kernel mentioned above detects EMMC and microSD, but detects no ethernet interfaces.
OK, so I’ve succeeded booting Fedora with Fedora kernel on Orange Pi 5 Plus and Rock 5B. The secret of success was to specify DTB manually, either with devicetree directive in BLS config entry file, or with GRUB_DEFAULT_DTB variable in /etc/default/grub.
The last variant has advantage that it results in adding devicetree parameter in /boot/grub2/grubenv automatically, so it’s not necessary to edit BLS config entry files manually after installing new kernel versions. Disadvantage of this approach is that you can’t specify per-kernel DTB for each kernel, you can only use DTB from the latest kernel (through /boot/dtb symlink), and I’m not sure whether it’s safe to use DTB from different kernel version if you decide to boot a kernel that is not latest installed.
Also, it’s important to add console=ttyS2,1500000n8 to kernel arguments: upstream Fedora kernel has no ttyFIQ0, the console on Orange Pi 5 Plus and Rock 5B is ttyS2.
I use Orange Pi 5 Plus and Rock 5B as servers, without graphics console, so I use serial console only and have no idea whether graphics works with upstream Fedora kernel.
But upstream Fedora kernel comes with some limitations. I found that I have no /sys/class/thermal/thermal_zone* directories with upstream Fedora kernels, so I can’t see how hot my boards become during compilation. Also, speed of a fan connected to Rock 5B is not controlled automatically dependent on temperature, it just spins at the maximum speed. I still can reduce this speed manually by writing values less than 256 to /sys/class/hwmon/hwmon0/pwm1 file. I have no fan connected to Orange Pi 5 Plus, so I don’t know whether it also lacks automatic PWM fan speed control.
@pbrobinson: what drivers are responsible for exposing temperatures through /sys/class/thermal/thermal_zone* files and controlling PWM fan speed automatically?
According to rk3588 mainline status the thermal ADC drivers have not been merged into mainline yet. A patch to enable that functionality is linked on that page.
That entry was critical for me to boot into the latest fedora kernel (6.9.7) from eMMC using edk2-rk3588 (v0.10) on SPI flash. Thanks for that. edk2 is supposed to send a custom device-tree to the kernel from what I understand, but that doesn’t appear to be working.
Now that that the kernel is loaded, it doesn’t see the eMMC to load the rest of the system from. My intent is to save the nvme for data storage and run the system from eMMC. Any thoughts on getting eMMC working with the fedora kernel. Supposedly, all the pieces are there.