On Fri, Apr 9, 2021 at 3:15 AM Matthias Brugger <mbrug...@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 <sean...@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@1,0 { > >>>> #address-cells = <3>; > >>>> #size-cells = <2>; > >>>> ranges; > >>>> > >>>> reg = <0 0 0 0 0>; > >>>> > >>>> usb@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....@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.
