Running u-boot 2021.04 on Raspberry Pi 4

Running u-boot 2021.04 on Raspberry Pi 4

[Roman Shaposhnik]

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,
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
greatly appreciated (in fact I actually added printf's to
write_smbios_table() to see if there's any micalculation going
on -- but no -- it seems that all method->write() methods
there work as expected and their cumulative output
adds up to  209 bytes -- but only 128 are present)

Thanks,
Roman.

# dmidecode
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
7 structures occupying 209 bytes.
Table at 0x3CB28020.
Wrong DMI structures length: bytes announced, only 128 bytes available.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: U-Boot
        Version: 2021.04
        Release Date: 04/08/2021
        ROM Size: 64 kB
        Characteristics:
                PCI is supported
                BIOS is upgradeable
                Selectable boot is supported
                I2O boot is supported
                Targeted content distribution is supported
        BIOS Revision: 21.4
Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: Not Specified
        Product Name: Not Specified
        Version: Not Specified
        Serial Number: 100000000ffddf0b
        UUID: 30303031-3030-3030-3066-666464663062
        Wake-up Type: Reserved
        SKU Number: Not Specified
        Family: Not Specified
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
        Manufacturer: Not Specified
        Product Name: Not Specified
        Version: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Features:
                Board is a hosting board
        Location In Chassis: Not Specified
        Chassis Handle: 0x0000
        Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.

Running u-boot 2021.04 on Raspberry Pi 4

[Sean Anderson]

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 at .../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>;
>                        };
>                };
>         };

> 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

You can always bisect it ;)

--Sean

> greatly appreciated (in fact I actually added printf's to
> write_smbios_table() to see if there's any micalculation going
> on -- but no -- it seems that all method->write() methods
> there work as expected and their cumulative output
> adds up to  209 bytes -- but only 128 are present)
> 
> Thanks,
> Roman.
> 
> # dmidecode
> Getting SMBIOS data from sysfs.
> SMBIOS 3.0 present.
> 7 structures occupying 209 bytes.
> Table at 0x3CB28020.
> Wrong DMI structures length: bytes announced, only 128 bytes available.
> Handle 0x0000, DMI type 0, 24 bytes
> BIOS Information
>          Vendor: U-Boot
>          Version: 2021.04
>          Release Date: 04/08/2021
>          ROM Size: 64 kB
>          Characteristics:
>                  PCI is supported
>                  BIOS is upgradeable
>                  Selectable boot is supported
>                  I2O boot is supported
>                  Targeted content distribution is supported
>          BIOS Revision: 21.4
> Handle 0x0001, DMI type 1, 27 bytes
> System Information
>          Manufacturer: Not Specified
>          Product Name: Not Specified
>          Version: Not Specified
>          Serial Number: 100000000ffddf0b
>          UUID: 30303031-3030-3030-3066-666464663062
>          Wake-up Type: Reserved
>          SKU Number: Not Specified
>          Family: Not Specified
> Handle 0x0002, DMI type 2, 14 bytes
> Base Board Information
>          Manufacturer: Not Specified
>          Product Name: Not Specified
>          Version: Not Specified
>          Serial Number: Not Specified
>          Asset Tag: Not Specified
>          Features:
>                  Board is a hosting board
>          Location In Chassis: Not Specified
>          Chassis Handle: 0x0000
>          Type: Motherboard
> Invalid entry length (0). DMI table is broken! Stop.
> 

Running u-boot 2021.04 on Raspberry Pi 4

[Roman Shaposhnik]

On Thu, Apr 8, 2021 at 8:59 PM Sean Anderson <seanga2@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 at .../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>;
> >                        };
> >                };
> >         };
>

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
>
> You can always bisect it ;)
>

LOL -- true! I was just hoping someone would recognize the issue perhaps.

Thanks,
Roman.

Running u-boot 2021.04 on Raspberry Pi 4

[Nicolas Saenz Julienne]

[ 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@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 at .../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
> > 
> > You can always bisect it ;)
> > 
> 
> 
> LOL -- true! I was just hoping someone would recognize the issue perhaps.
> 
> Thanks,
> Roman.?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210409/85ace59c/attachment.sig>

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@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 at .../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 at 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.?
> 
> 

Running u-boot 2021.04 on Raspberry Pi 4

[Roman Shaposhnik]

On Fri, Apr 9, 2021 at 3:15 AM Matthias Brugger <mbrugger@suse.com> wrote:

>
>
> 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@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 at .../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 at 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


Thanks! Works like a charm:

https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/overlays/raspberrypi-rpi.dts

But yes -- it would be nice to fix the default behaviour. Speaking of
tables being empty
(once your fix above makes it in) it may also make sense to document it
someplace,
but I honestly don't know what a good place for that would be ;-)


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

That sounds pretty useful too -- although my usecase is much more limited
-- I just
need to be able to provide quick DT overlays to reliably identify various
HATs on RPi
at the SMBIOS level.

Where it gets interesting, of course, are the HATs that provide their OWN
DTs via
EEPROM I2C.

Thanks,
Roman.

Running u-boot 2021.04 on Raspberry Pi 4

[Matthias Brugger]

On 09/04/2021 20:06, Roman Shaposhnik wrote:
> On Fri, Apr 9, 2021 at 3:15 AM Matthias Brugger <mbrugger@suse.com> wrote:
> 
>>
>>
>> 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@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 at .../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 at 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
> 
> 
> Thanks! Works like a charm:
> 
> https://github.com/lf-edge/eve/blob/master/pkg/u-boot/rpi/overlays/raspberrypi-rpi.dts
> 
> But yes -- it would be nice to fix the default behaviour. Speaking of
> tables being empty
> (once your fix above makes it in) it may also make sense to document it
> someplace,
> but I honestly don't know what a good place for that would be ;-)
> 

I send patches for the case where U-Boot relies on the embedded device tree, not
sure if that's your case:
https://patchwork.ozlabs.org/user/todo/uboot/?series=238321

Feel free to test and provide feedback :)

> 
>> 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.
>>
> 
> That sounds pretty useful too -- although my usecase is much more limited
> -- I just
> need to be able to provide quick DT overlays to reliably identify various
> HATs on RPi
> at the SMBIOS level.
> 
> Where it gets interesting, of course, are the HATs that provide their OWN
> DTs via
> EEPROM I2C.
> 

Well if we go with the smbios overlay it could add information to that in the
HATs overlay. But of course that only works if we have smbios node in the first
place.

Regards,
Matthias