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.wah...@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-le...@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
