Once upon a time, Stefan Wahren <stefan.wahren(a)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/?...
>
> Unfortunately this is a change which requires this DTS fix:
>
>
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?...
>
> 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] -