@dwrobel could you build packages for EPEL9_4?
I forget to reply: thanks a lot!
As for RPi5: I gave that a go yesterday and needed to make one small adjustment. In config.txt on the boot partition I needed to comment out / remove [rp4] so that the following lines take effect (which are required to get a working display/gpu).
With that done it seems to work perfectly for me.
@treba Thank you for the feedback.
I needed to comment out / remove
[rp4]
Could you please confirm if the following would also works for you (I would prefer not to break rpi3):
--- config.txt.orig 2024-10-25 17:21:18.000000000 +0200
+++ config.txt 2024-11-18 11:35:03.554249245 +0100
@@ -29,6 +29,8 @@
# Gadget mode
# dtoverlay=dwc2
+# Model filters: https://www.raspberrypi.com/documentation/computers/config_txt.html#model-filters
+# Note: Pi 400 and Compute Module 4* also sees [pi4] contents
[pi4]
# Automatically load overlays for detected cameras
camera_auto_detect=1
@@ -45,3 +47,18 @@
disable_overscan=1
+[pi5]
+# Automatically load overlays for detected cameras
+camera_auto_detect=1
+
+# Automatically load overlays for detected DSI displays
+display_auto_detect=1
+
+# Enable DRM VC4 V3D driver
+dtoverlay=vc4-kms-v3d
+
+# Allows the default turbo-mode clock to be increased from 1.5GHz to 1.8GHz
+# Based on https://www.raspberrypi.com/documentation/computers/config_txt.html#arm_boost-raspberry-pi-4-only
+arm_boost=1
+
+disable_overscan=1
Yep, can confirm that it works as expected.
I can confirm that, with F41 and additional part [pi5] in config.txt file, it works just file with RPi5.
Thank you @dwrobel
1 Like
@dwrobel For Fedora 42, would you consider adding the [rpi5] section by default, so the images work OOTB (in case you havenāt done that already - in which case the related part could be removed from Howto/RaspberryPi - RPM Fusion)? For me that works perfectly fine and I use a single SD-card for both the 4 and 5 (I only use them for testing, so one at a time is enough).
would you consider adding the [rpi5] section
Yes, it will be part of the F42 image.
1 Like
I installed the F41version a while back. Now I would like to update to F42.
Can I just upgrade as on a normal x86 workstation with dnf? I still have an understanding problem with the boot process. It looks like that the arm image not uses grub2 and also EFI is not available? I would like to know if there is a boot option/menu which makes falling back to a working kernel available.
Does someone have a link to a page which illustrates/describes the differences or simply illustrates the arm way?
It is my first RPI and I am still in the process to getting used of it.
Can I just upgrade as on a normal x86 workstation with dnf?
Yes, you can.
I would like to know if there is a boot option/menu which makes falling back to a working kernel available.
No, there isnāt. Instead, attach the disk to the PC and copy one of the selected /your-mount-point/boot/vmlinux* file as /your-mount-point/boot/efi/kernel8.img.
1 Like
The update from 6.12.61-1.rpi5.fc43 to 6.12.67-2.rpi5.fc43 appears to have introduced a networking regression on my system. I am running Fedora 43 on a Raspberry Pi 5, using the onboard Ethernet interface, with an otherwise unchanged and previously stable configuration.
After a link flap, for example when I reboot my router, the gateway ARP entry becomes permanently stuck in the INCOMPLETE state. The Pi continues to send ARP requests, but it never receives replies. I verified with tcpdump that during the broken state no ARP replies are visible on the wire. Only a full reboot of the Pi restores connectivity, rebooting the router does not help.
Other devices connected to the same router do not experience this issue. The same Raspberry Pi 5 running Raspberry Pi OS on identical hardware and network, also using the onboard Ethernet, works correctly.
I first noticed this problem around two to three weeks ago and suspected it might be related to a recent kernel update. Since the previous build was no longer available in the Copr repository, I rebuilt 6.12.61-1.rpi5.fc43 from this fork of dwrobel/kernel, which is still two commits behind the current state:
https://github.com/MDev-Linux/fedora-rpms-kernel-rpi
With that build, I can confirm the issue does not occur, and 6.12.61-1.rpi5.fc43 works as expected.
1 Like
FYI, I donāt have any RPi5 to verify it.
That one looks quite similar to your symptoms: [Regression] commit f5c055c28415688bde0d8cc100803e8d4d3f3a04 in the rpi-6.12.y branch introduced a regression in the bmac driver Ā· Issue #7200 Ā· raspberrypi/linux Ā· GitHub.
Please consider testing: 6.12.73-1.rpi5 from the: coprs/dwrobel/kernel-rpi-testing.
Thanks for the pointer.
That matches my symptoms exactly, and 6.12.73 contains the fix that resolves the issue on my side.
I have not yet installed your RPM build, but coincidentally I have been working on my own Copr and GitHub setup based on your work and already tested 6.12.73 there.
I tried to understand how you structure the Copr builds for the split kernel-rpi4 and kernel-rpi5 packages when uploading SRPMs, but I could not get it to work the same way. In the end I implemented a different approach for my own builds.
For reference, these are the repositories:
https://copr.fedorainfracloud.org/coprs/mandolin/kernel-rpi
https://github.com/innovara/kernel-rpi
All credit goes to you and the previous contributors. I am simply building on that for my own use.
1 Like