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