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 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 _______________________________________________ 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
