Thursday, March 31, 2022

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

Am 11.03.22 um 17:37 schrieb Stefan Wahren:
> 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 <> 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:
>>>>> Unfortunately this is a change which requires this DTS fix:
>>>>> So DTB and kernel must "match".
>>>> Okay, so what's the best way to do that?
>>>> I have EFI firmware from in /boot/efi, and
>>>> the /boot/dtb symlink removed. The bcm2711-rpi-4-b.dtb file in
>>>> /boot/efi is from the 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] -
>> 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].
Okay, at least i found a fix [1] for the 64 bit boot issues (Original
Fedora 35, Linux 5.14) with RPi 400/RPi 4 Stepping C0. This requires the
DTB files to be updated and U-Boot to choose between the B0 and the C0
variant of the Rpi 4 DTB file.

Unfortunately this doesn't fix the SD card issues on 32 bit.

Best regards

[1] -
arm mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam on the list, report it:

No comments:

Post a Comment