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:
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@xxxxxxxx> 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 thatAll 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 -22Any 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/193Today 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
