Raspberry Pi CM4 experience report
by James Clark
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#Deacti...
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=...
).
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#co...)
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
8 months, 1 week
- 1
- 0