Wednesday, March 16, 2022

[fedora-arm] Re: Change in kernel PPS GPIO handling?

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  

No comments:

Post a Comment