wireless-tools
by David Legg
Just installed Fedora 38 (minimal) on an RPI 4 and found that the
wireless-tools package is not available. Anybody know where to get
iwconfig etc from, please?
:D
2 hours, 8 minutes
PCIe slot on Raspberry Pi CM4
by James Clark
I am trying to connect an i210-T1 to the PCIe slot on a Raspberry Pi CM4
with the official IO board. The problem is it won't boot. I tried this in
Fedora 38 initially. Now I've installed a recent nightly
(Fedora-Server-39-20230828.n.0.aarch64.raw.xz) and I've connected a USB TTL
adapter. It appears to be a U-Boot problem. I get the following over and
over again
U-Boot 2023.10-rc3 (Aug 21 2023 - 00:00:00 +0000)
DRAM: 992 MiB (effective 7.9 GiB)
RPI Compute Module 4 (0xd03141)
Core: 212 devices, 16 uclasses, devicetree: board
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In: serial,usbkbd
Out: serial,vidconsole
Err: serial,vidconsole
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 2.5 Gbps x1 (SSC)
"Error" handler, esr 0xbf000002
elr: 00000000000b52b0 lr : 00000000000b526c (reloc)
elr: 000000003df812b0 lr : 000000003df8126c
x0 : 000000000000dead x1 : 0000000000100000
x2 : 0000000000008000 x3 : 00000000fd508000
x4 : 000000003db399f0 x5 : 0000000000000001
x6 : 000000003df82bb8 x7 : 000000003db39fc0
x8 : 000000003df82c90 x9 : 000000003db3992c
x10: 0000000000000002 x11: 0000000000000140
x12: 000000003db39918 x13: 000000003db39fc0
x14: 00000000ffffffff x15: 000000003db39b78
x16: 000000003df82c90 x17: 0000000000c0c0c0
x18: 000000003db47d60 x19: 000000003db399f0
x20: 0000000000000001 x21: 000000003db53f00
x22: 0000000000000000 x23: 0000000000010000
x24: 000000003dfc58fc x25: 000000000001ff00
x26: 000000000000ffff x27: 0000000000000000
x28: 000000003db53b10 x29: 000000003db39950
Code: 350001f4 f94017e0 39400000 92401c00 (d5033fbf)
Resetting CPU ...
resetting ...
James
2 weeks, 3 days
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
2 weeks, 4 days
