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