[PATCH v4 0/6] rpi5: initial support

[Stefan Wahren]

Hi,

Am 20.01.24 um 10:48 schrieb Jens Maus:
> Hi,
>
>> Am 20.01.2024 um 10:22 schrieb Stefan Wahren <wahrenst at gmx.net>:
>>
>> Am 19.01.24 um 22:26 schrieb Jens Maus:
>>> I actually do have some good and bad news:
>>>
>>> 1. Good news: I got u-boot finally showing up with my RaspberryPi5 8GB both on the HDMI and on the serial debug UART like you reported.
>>>
>>> 2. Bad news: I actually got it working by downgrading the rpi-eeprom to the same 2023/10/30 (VERSION:30de0ba5) version like you have.
>>>
>>> So the issue I saw/reported seems to be somehow related/limited to newer rpi-eeprom versions. Looking at my previous diff on the rpi bootloader log output differences, the potentially relevant piece might be the "M.2 PCIe HAT not detected.“ line that is only present in newer rpi-eeprom version outputs.
>>>
>>> So hopefully you can reproduce that issue yourself when upgrading your rpi-eeprom version to newer or also the latest version from 2024/01/15 available [1] and potentially find the actual piece that prevent your patchset from working on newer eeprom versions.
>> thanks for your work, but i think you are wasting your time. The
>> rpi-eeprom release 2024/01/15 seems to be broken [1]
>>
>> :-(
> Thanks for that info. However, I also tested older eeprom versions to identify when the issue that u-boot cannot boot a rpi5 started to appear. And I am afraid, it already starts with version 2023-11-20 right after the 2023-10-30 which currently seems to work fine with Ivan’s patches. Looking at the release notes of rpi-eeprom [1] one can see the following entries:
sorry, i got it wrong. I thought only 2024-01-15 is affected.
Unfortunately i'm not a U-Boot developer and i also don't have a RPi 5.
So i only can give some (hopefully) smart advices :-)

One idea would be to enable early debug in U-Boot (no idea how to
achieve this). I assume U-Boot crashes before it's able to print the
first line, but it's hard to believe it crashes at the very first
instruction of U-Boot. So with some luck we should be able to narrow
done the cause.

Another point would be to open an Github issue on rpi-eeprom and ask
them for advice, why 2023-11-20 stops to work in our case. Sure they
don't want to support U-Boot, but they are also interested in Linux
Mainline support.

Best regards
>
> — cut here —
> 2023-11-20: Auto-detect support for PCIe expansion HAT (default + latest)
>
>      • Add autodetect support for PCIe expansion HATs
>      • Add PCIE_PROBE=1 to the EEPROM config for custom PCIe exapansion designs that do not support the upcoming HAT spec. This gives similar behaviour to CM4 where PCIe x1 is enumerated to discover NVMe devices.
>      • Fix loading of multiple initramfs images that are not 32-bit aligned sizes raspberrypi/firmware#1843
>      • Kernel load performance improvement - remove a memcpy
> — cut here —
>
> So as I stated earlier, one probable catch for the u-boot patches here might be the mentioned PCIe changes with the rpi-eeprom 2023-11-20 version. Or it might be related to the „kernel load performance improvements“ mentioned?!?
>
> For now I am of course using the 2023-10-30 rpi-eeprom version and so far it works flawlessly with Ivan’s u-boot patches. Still I hope Ivan or someone else can have a closer look why with the 2023-11-20 version of rpi-eeprom u-boot immediately stops working at all.
>
> best regards,
> jens
>
> [1] https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware-2712/release-notes.md