[fedora-arm] Raspberry Pi CM4 experience report

I have spent some time trying to get Fedora 38 working nicely on the Raspberry Pi CM4 and I have written a guide based on my experience.

https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/fedora.md
https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/chrony.md

The background here is that the CM4 is unique amongst SBCs in having hardware PTP support that includes PPS input. I wrote a guide to how to take advantage of this based on Raspberry Pi OS and LinuxPTP. It is also possible to take advantage of this hardware PTP support for NTP by using chrony's support for PPS input via the PTP hardware clock and for NTP-over-PTP hardware timestamping; this allows NTP to approach PTP levels of accuracy. So my initial goal was to get this working, so that the CM4 can be used as a state-of-the-art NTP server with Fedora. It now seems to be working, although there's plenty of scope for tuning.

I ran into a few problems.

The biggest problem is that HDMI output doesn't work properly. It works OK in Fedora 38 in the original image, but it doesn't work after updating, and it doesn't work in a recent Fedora 39 nightly. The HDMI output works at the U-boot and Grub stage. It then says "Booting Fedora Linux (version info here)" and after a while the screen goes blank. In Fedora 38 jupdated, it stays blank. In Fedora 39 nightly, it shows some systemd lines, starting with plymouth-start.service and ending with systemd-vconsole-setup.service.

The next biggest problem is this:

  https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi/HATs#Deactivate_Serial_Console_entirely

The implication of this is that if you connect a GPS to the normal TXD/RXD pins on the CM4 IO board, it doesn't boot (because U-boot treats the NMEA GPS output as input).

I tried to workaround this as suggested by connecting a keyboard so I could configure U-boot to disable the serial console, but I found that USB keyboard input in U-boot didn't work.

I ended up enabling an additional UART. The docs say e.g. "UART3 GPIOs 4 - 7".  I assumed this  meant TX was on GPIO4 and RX was on GPIO7. Eventually I figured out that it actually meant that TX,RX,CTX,RTS were on GPIOs 4,5,6,7. I suppose in retrospect it's obvious, but it would be helpful if the wiki was a little more explicit. However, this isn't a completely satisfactory workaround, because some GPS hardware explicitly designed for the Raspberry Pi doesn't allow changing what TX/RX pins are used (notably this one https://store.timebeat.app/products/gnss-raspberry-pi-cm4-module?variant=42280855699627).

This in the wiki is incorrect

The new devices will appear as /dev/ttyAMA0-4. Note that the numbering is simply counting through the activated devices. The numbers are not linked to any UART specifically. Only activating UART0 and UART5 will make UART5 be available as /dev/ttyAMA1.

If I enable just uart3, I get /dev/ttyAMA3.

I found the Serial devices section of the wiki confusing, particularly the description of UART 0/1

Raspberry Pis up to but not including the 4-series have only one UART which is UART0/1 (depending on which chip you use).

The Raspberry Pi docs (https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts) say there are two UARTs (a mini UART and a PL011), and I see two serial devices at the Linux level.

It mentions

dtoverlay=pi3-disable-bt

But I think the right one to use currently is simply

dtoverlay=disable-bt

This makes /dev/ttyAMA0 (a PL011) be connected to the TX/RX pins. Without this it's /dev/ttyS0 that's connected to the TX/RX pins (and there's a /dev/ttyAMA1).

James