Just in case anyone thought the GPIO-related F35 problems were limited to newer Pi 4s and Pi 400s, I can confirm that even my old Pi 3B is similarly afflicted.

1. Install Fedora 35 aarch64 onto micro SD card:

arm-image-installer --image=Fedora-Minimal-35-1.2.aarch64.raw2.xz --target=rpi3 --media=/dev/sdf

2. And boot.

3. GPIO commands now work, except that the sense seems to be reversed compared with my pi 4; i.e. this command raises the GPIO to 3.3V,

gpioset `gpiofind GPIO27`=0

when I would have expected 0 to mean 0V as it does on my pi 4 running the 5.14.10-300.fc35.aarch64 kernel.

4. Updating to the latest 5.16 kernel using dnf causes GPIO not to work at all. This is the case whether I delete the /boot/dtb soft link or not. I get the same with rawhide (F37), and haven't managed to find an F36 image yet.

Just sayin' all this in case it provides some clarity or helps in any way whatsoever ...

:D

PS. All commands done as root.


On 11/03/2022 16:37, Stefan Wahren wrote:
Subject:
[fedora-arm] Re: Change in kernel PPS GPIO handling?
From:
Stefan Wahren <stefan.wahren@i2se.com>
Date:
11/03/2022, 16:37
To:
arm@lists.fedoraproject.org

Am 05.03.22 um 12:34 schrieb Stefan Wahren:
Am 04.03.22 um 21:50 schrieb Stefan Wahren:
Am 03.03.22 um 02:29 schrieb Chris Adams:
Once upon a time, Stefan Wahren <stefan.wahren@i2se.com> said:
Hi Chris,

Am 02.03.22 um 10:51 schrieb Peter Robinson:
I have an RPi4 running Fedora 35.  It hadn't been updated in a while, so
I applied updates today.  When I boot to the kernel 5.16.11-200, I lose
the PPS device from my GPS hat.  Boot back to 5.14.16-301.fc35 and it
works.

I'm booting with EFI firmware, and with a device tree config.txt that
All our firmware are EFI, that's the only way we support booting, is
it the default U-Boot based one or are you using the edk2 one?

has "dtoverlay=pps-gpio,gpiopin=4" in it.  I removed the /boot/dtb
symlink and set /etc/u-boot.conf to not re-add it.

When I boot 5.16, I see /proc/device-tree, and it has
/proc/device-tree/pps@4 in it (and the contents look correct), but
loading the pps-gpio kernel module just gives:

pps-gpio: probe of pps@4 failed with error -22
Any chance you can tell us which kernel it started with, 5.14.x to
5.16.x is a big window to debug and looking at kernel logs for
drivers/pps there's been no changes in that space in the 5.15+ kernels
at all.

I wonder if it's a change/regression in the firmware overlay <->
kernel interface.
do you use the DTB file from 5.14.x or 5.16x?

I guess this is related to this commit:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=266423e60ea1b953fcc0cd97f3dad85857e434d1

Unfortunately this is a change which requires this DTS fix:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=c8013355ead68dce152cf426686f8a5f80d88b40

So DTB and kernel must "match".
Okay, so what's the best way to do that?

I have EFI firmware from https://github.com/pftf/RPi4 in /boot/efi, and
the /boot/dtb symlink removed.  The bcm2711-rpi-4-b.dtb file in
/boot/efi is from the RPi4_UEFI_Firmware_v1.32.zip file.  I have a
config.txt in /boot/efi that references overlays in /boot/efi/overlays
from RPM bcm283x-overlays (like pps-gpio)..

I'm not quite sure how I need to fit all this together.
Let me recap the situation. mainline and rpi vendor tree are independent
in development. Synchronization (incl. device tree) happens in both
directions.

U-Boot bootloader decided to keep an own copy of the mainline DT files
(which is currently based on an older 5.15 version which lacks the
gpio-ranges property). According to this statement [1] the EDK2 UEFI
decided to use the rpi vendor tree and don't care about the mainline DT
files.

I'm sorry but as a spare-time kernel developer, i don't have to time to
fight against all this mess.

I hope i will have some time for debugging in the near future ...

[1] - https://github.com/pftf/RPi4/issues/193

Today i tried Fedora 35 Minimal for my first time, here are my test results:

Raspberry Pi 400 32 bit => bus width issue
Raspberry Pi 400 64 bit => hangs while show graphics
Raspberry Pi 4 B 4 GB 32 bit => kernel crash
Raspberry Pi 4 B 4 GB 64 bit => boot into setup
Raspberry Pi 4 B 8 GB 32 bit => black screen, fails to start kernel?
Raspberry Pi 4 B 8 GB 64 bit => boot into setup

At least the 32 bit issues on Raspberry Pi 4 are expected since the
kernel config doesn't have ARM_LPAE enabled.

Okay, here is the explanation for the different behavior on Raspberry Pi
400 and Raspberry Pi 4 B. The Raspberry Pi 400 has a newer BCM2711 SoC
(Stepping C0), which have less DMA restrictions for the emmc2 interface
(responsible for SD card access). For the Raspberry Pi 4 B there are
older boards which have Stepping B0 and all the new boards should have
Stepping C0 [1].

Unfortunately there is no 100% reliable way to detect the stepping from
the kernel side. So currently the Raspberry Pi firmware patches the
dma-ranges in the firmware DT [2]. So in case U-Boot [3] or another
bootloader ignores this firmware DT and read a fresh DTB the right
dma-ranges get lost. Finally this results in unexpected behavior as soon
the emmc2 switches to DMA mode [4].

Best regards

[1] -
https://www.jeffgeerling.com/blog/2021/raspberry-pi-4-model-bs-arriving-newer-c0-stepping

[2] -
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/bcm2711.dtsi?h=next-20220310&id=3d2cbb64483691c8f8cf88e17d7d581d9402ac4b

[3] - https://forums.raspberrypi.com/viewtopic.php?t=319125

[4] - https://bugzilla.redhat.com/show_bug.cgi?id=2011423


_______________________________________________
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure