Running u-boot 2021.04 on Raspberry Pi 4

[Matthias Brugger]

On 09/04/2021 10:14, Nicolas Saenz Julienne wrote:
> [ Adding Matthias for the SMBIOS part ]
> 
> On Fri, 2021-04-09 at 00:00 -0700, Roman Shaposhnik wrote:
>> On Thu, Apr 8, 2021 at 8:59 PM Sean Anderson <seanga2 at gmail.com> wrote:
>>> On 4/8/21 8:18 PM, Roman Shaposhnik wrote:
>>>> Hi!
>>>>
>>>> first time poster, long time lurker here. Over at Project EVE
>>>> https://github.com/lf-edge/eve I've been trying to migrate
>>>> from our current u-boot v2020.07 + patches:
>>>>
>>>> https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020.07
>>>> to the latest u-boot 2021.04.
>>>>
>>>> Great news is that most of the patches we dependent
>>>> on seem to have been pulled upstream. However, this
>>>> single *chunk* of one patchset wasn't:
>>>>
>>>> https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020.07/0001-usb-xhci-Load-Raspberry-Pi-4-VL805-s-firmware.patch#L293
>>>>
>>>> I'm wondering what was the reason for leaving it behind,
>>>
>>> +CC Nicolas
>>>
>>>>   - Get rid of PCI core patch as not needed with correct DT PCI topology 
>>>
>>> also from the cover letter
>>>
>>>> This also depends on a DT/bindings patch available on the linux-mailing lists:
>>>> https://www.mail-archive.com/linux-kernel@.../msg2205783.html
>>>
>>> The merged version of this series is
>>>
>>> https://patchwork.kernel.org/project/linux-usb/list/?series=310015&state=%2A&archive=both
>>>
>>>> Here is the relevant bit for reference/discussion:
>>>>
>>>>          &pcie0 {
>>>>                 pci at 1,0 {
>>>>                         #address-cells = <3>;
>>>>                         #size-cells = <2>;
>>>>                         ranges;
>>>>
>>>>                         reg = <0 0 0 0 0>;
>>>>
>>>>                         usb at 1,0 {
>>>>                                 reg = <0x10000 0 0 0 0>;
>>>>                                 resets = <&reset RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
>>>>                         };
>>>>                 };
>>>>          };
>>>
> 
> Yes, instead of using a PCI quirk we settled on a reset controller. All in all
> it is less hacky. But needs changes in DT.
> 
>> Aha! Thank you so much -- this is super helpful!
>>  
>>>> since without it I don't seem to have functioning USB
>>>> devices on my  Raspberry Pi 4. In fact, adding it back:
>>>>
>>>> https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04
>>>> (just that one chunk -- 'cuz the reset got upstreamed)
>>>> seems to solve the issue for me.
>>>>
>>>> Another question I have is that the new u-boot seems to have
>>>> some kind of a regression that I can't quite debug. The SMBIOS
>>>> tables that it constructs during EFI boot sequence seem to be
>>>> broken (see the dmidecode output below). Again, this seems
>>>> to be a regression compared to  v2020.07. Any ideas on what
>>>> could be wrong or how can I start debugging it would be
>>>

Yes, that's not working right now. I'm working on a fix for the tables:
https://patchwork.ozlabs.org/project/uboot/patch/20210406090435.19357-1-matthias.bgg@kernel.org/

This will fix the error en dmidecode but the tables will be basically empty.
Before that there was some information that helped you to identify that you are
running on a RaspberryPi.

A quick fix would be to add that information to the DTS. Like for example done here:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3328-rock64-u-boot.dtsi#L13

On the long run we want to add a sysinfo driver to read the information for the
mailbox driver and use that. But my understanding is that for that we would need
to create a SPL for the mailbox driver to provide that info in a shared data
structure. It's still on my list for investigation.

Regards,
Matthias

>>> You can always bisect it ;)
>>>
>>
>>
>> LOL -- true! I was just hoping someone would recognize the issue perhaps.
>>
>> Thanks,
>> Roman. 
> 
>