No USB with Vanilla 5.16-rc2

[0n0w1c]

With an 8GB RPI4 and the current version of vanilla kernel with v1.32 and ACPI+Devicetree or Devicetree These errors appear prior to the uefi raspberry.

Failed to update USB compatible properties: Not Found
Failed to update PCIe address ranges: Not Found

USB keyboard works with UEFI, but once the kernel is loaded, no usb keyboard or mouse. Resulting in these kernel errors:

[    0.952249] usb 1-1: device descriptor read/64, error -71
[    1.232164] usb 1-1: device descriptor read/64, error -71
[    1.842156] usb 1-1: device descriptor read/64, error -71
[    2.212154] usb 1-1: device descriptor read/64, error -71
[    3.669786] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[    3.882305] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[    4.102006] usb 1-1: device not accepting address 4, error -22
[    4.262052] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[    4.482040] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[    4.701933] usb 1-1: device not accepting address 5, error -22
[    4.702113] usb usb1-port1: unable to enumerate USB device

With traditional rpi firmware booting, USB works fine.

If ACPI only is selected, no such errors are produced... but then no vc4.

[0n0w1c]

raspberrypi-bootloader-20211108-1 (start4.elf, fixup4.dat)

rpi-eeprom-update

BOOTLOADER: up to date
   CURRENT: Wed Oct 27 03:47:09 PM UTC 2021 (1635349629)
    LATEST: Wed Oct 27 03:47:09 PM UTC 2021 (1635349629)
   RELEASE: beta (/lib/firmware/raspberrypi/bootloader/beta)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

cat /boot/config.txt

arm_64bit=1
#enable_uart=1
#uart_2ndstage=1
enable_gic=1
armstub=RPI_EFI.fd
disable_commandline_tags=1
disable_overscan=1
device_tree_address=0x1f0000
device_tree_end=0x200000
#dtoverlay=miniuart-bt

Using the bcm2711-rpi-4-b.dtb supplied by kernel-5.16-rc2

grub2 2.06-2 is then loaded by uefi:

menuentry 'Vanilla ARM - RC' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-67f980ac-ed2d-4c24-9b33-d26967fad293' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod fat
        set root='hd0,gpt1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275/(null)/sas/disk@0,gpt1' --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  4EDD-A307
        else
          search --no-floppy --fs-uuid --set=root 4EDD-A307
        fi
        echo    'Loading Vanilla ARM - RC ...'
        linux   /Image root=UUID=d1684ccb-e8af-4276-8262-57c7ab0fa08e rw rootwait console=tty0 audit=0 video=HDMI-A-1:1920x1080M@60 dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x61f79d3c bcm2709.uart_clock=48000000 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:C1:37:15 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000
        echo    'Loading initial ramdisk ...'
        initrd  /initramfs-linux.img
}

I have also tried very basic kernel arguments, no difference:

root=PARTUUID=d905149e-02 rw rootwait console=tty0 audit=0

[0n0w1c]

It may be related to the changes in this part of bcm2711-rpi-4-b.dtb?

older

                        pci@1,0 {
                                #address-cells = <0x03>;
                                #size-cells = <0x02>;
                                ranges;
                                reg = <0x00 0x00 0x00 0x00 0x00>;

                                usb@1,0 {
                                        reg = <0x10000 0x00 0x00 0x00 0x00>;
                                        resets = <0x2d 0x00>;
                                };
                        };

newer

                        pci@0,0 {
                                device_type = "pci";
                                #address-cells = <0x03>;
                                #size-cells = <0x02>;
                                ranges;
                                reg = <0x00 0x00 0x00 0x00 0x00>;

                                usb@0,0 {
                                        reg = <0x00 0x00 0x00 0x00 0x00>;
                                        resets = <0x26 0x00>;
                                };
                        };

usb works and no errors with the older dtb.

[0n0w1c]

Using the current SUSE Tumbleweed bcm2711-rpi-4-b.dtb, no errors and everything seems to be working... it too has pci@1,0 usb@1,0. So this does indeed seem to be a devicetree issue.

[jlinton]

Yes, its device tree, and the rpi mailbox to reload the XHCI firmware. What appears to happen is that the PCIe fundamental reset doesn't actually reset the XHCI consistently so the rpi mailbox to reload the firmware may or may not need to be called. On some kernels it needs to be called on others it doesn't, I posted a patch to put that under user control, but really it needs to be handled better, and at this point the simplest change is probably to add a DT attribute to tell linux not to reprogram/reset the root port and treat it the same way the kernel treats it when running one of the ACPI patch sets.

[0n0w1c]

Now it would appear that with 5.17-rc1 that I can no longer get the upstream kernel to boot, even with using the older start4 and dtb. I am beginning to wonder, is this project still active? I have not seen much activity here and considering the issues with the linux kernels.

[jlinton]

It's not dead, there is a review/upstreaming log jam. If you want to review the code to fix this, take a look at:

https://edk2.groups.io/g/devel/message/85249?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3ACreated%2C%2CUtilize+SPI+flash+for+EFI%2C20%2C1%2C0%2C88087663

That patch set, includes a menu item to give a bit finer grained control over the PCIe/XHCI firmware loading, which is apparently quite flakey, but in my experience toggling the load on/off fixes the problem. The set to do that got merged into the SPI flash set because its needed to enable/disable GPIO export.

[jlinton]

Hey, want to try out a test build? I just pushed one with a bunch of other changes as well to https://github.com/jlinton/edk2-platforms/blob/cppc6-various-fixes-vc4aml-mailboxspinlock-xhcipci-clocktweaks-spiv4/RPI_EFI.fd

Grab it, replace the RPI_EFI.fd on your sd card and let me know how it works. If there are XHCI issues, go to the rpi->advanced menu and toggle the load firmware option.

[0n0w1c]

Excellent, I would be happy to. It will be a little later today before I have the chance.

Do you have a kernel preference? I have 3 different rpi kernels (5.10, 5.16 & 5.17) and 2 different upstream kernels (5.16 & 5.17) currently installed.

[jlinton]

I don't prefer one or the other, that's up to you. Mostly because I'm only personally interested n ACPI on this platform, and to a lesser extent assuring that the latest mainline/DT mostly works. That firmware patch to support runtime variables only works in ACPI+NO_GPIO mode because the firmware needs control of the pin mixing. The assumption is that we can control the GPIO via AML/etc if needed. So the feature is simply disabled in DT mode because we can't presume what the OS is going to do with the HW under it.

Although, to your previous comment about the DT working, I think you need to use the DT that we provide in this package (and comes from the rpi foundation) for this to work. At least part of the problem could be that our changes to update the PCIe bridge windows to match the way they have been programmed isn't working when the pcie bridge name/etc is changed.

[0n0w1c]

Good news, the test firmware booted all of the kernels, both rpi and upstream when switched to ACPI+Devicetree. I only tested once set to ACPI only, it did not boot. I can do more here if desired.

Bad news:

• rpi kernels have vc4 issues.
• upstream kernels have usb 2.0 issues. The keyboard is recognized within the uefi, but when the kernel boots, the cold plugging does not find the usb keyboard or mouse.

How would you like for me to test next?

I was typing this when I noticed your last post. Hmm... not the results I would expect given what you just explained.

[jlinton]

Yah, you need to pass acpi=force to mainline linux or using the ACPI only option to actually enable ACPI in linux's that aren't redhat/centos/etc based.

The ACPI/USB should be far more stable at this point than the DT configs because there are a bunch of different kernels/DT's in play and anyone of them can break things. AFAIK, we haven't been having issues with ACPI+USB since the rpi foundation dropped the start4.elf file that honors the bridge window programming.

[0n0w1c]

Ah ok, I will re-test ACPI, this time passing acpi=force.

[0n0w1c]

With passing acpi=force, both the 5.16 and 5.17 upstream kernels boot properly. vc4 is not working, but that was very recently fixed.

Edit: Further testing reveals that acpi=force is not required. Why I had usb issues previously, I can not explain. Maybe making changes to the firmware config had an effect.

[jlinton]

The vc4 should only be working in DT mode at the moment, and you need to include the upstream dt overlay in config.txt to get it working. I have an early hacked up set of DSDT changes to start enabling it in this test firmware, but none of the kernel patches are posted/etc. In ACPI mode, its stuck with just the UEFI framebuffer in linux (windows/etc works though) so you should see graphics, but be unable to change the res/use acceleration.

the acpi=force comment is odd, yes you shouldn't need it if you set the firmware to ACPI (rather than ACPI+DT/etc). Mainline by default chooses DT if it finds both ACPI and DT, but it's also possible to build the kernel without ACPI support, which I'm not sure if anyone is doing that.

[jlinton]

PS, if you are happy with it a "Tested-by:" on the SPI set would be appreciated.

Thanks,

[0n0w1c]

I have explored some, trying to determine how to include a "Tested-by:" but I am not sure how to do it. I came up with either a PR on github with my contact info or join the edk2.groups.io mailing list and reply to your patch.

Or some other way, which is probably the correct way... so I ask. :)

Edit: I looked through the kernel docs but unfortunately I was not able to determine the correct course of action.

[jlinton]

The easiest is probably just to create a groups.io account, subscribe to edk2-devel, then reply to the message from the web UI.

[0n0w1c]

The reply has been placed, now awaiting moderator approval.

[jlinton]

I don't think it appeared, were you subscribed to the group before trying to send it?

[0n0w1c]

Hmm, maybe what I submitted looked like spam? I just replied "Tested by:" and my email. Should I have replied otherwise?

[jlinton]

Yah, just a reply-all with the Tested-by bit following the patch subject (near the signoff-by) is the usual form. Against the cover letter rather than a particular patch tends to mean the whole set.

[0n0w1c]

Hmm, I must be looking in the wrong location, because my original reply is here.

[jwmullally]

The RPI_EFI.fd build from https://github.com/pftf/RPi4/issues/195#issuecomment-1025960823 doesn't seem to make a difference here. Let me know if you want more information.

(From scratch) Install: rpi-boot-eeprom-recovery-2022-04-26-vl805-000138a1-sd.zip Install: Raspberry Pi 4 UEFI Firmware Images v1.33 Change UEFI settings: "Limit RAM to 3GB: Disabled". Disable Secure Boot Install: Fedora Silverblue 36 (Kernel 5.17.5) from USB, reboot.

USB only works OK in ACPI mode:

Limit RAM to 3GB: Disabled
System Table Selection: ACPI

dmesg_acpi.txt

USB doesnt work in Devicetree mode:

Limit RAM to 3GB: Enabled
System Table Selection: Devicetree

Limit RAM to 3GB: Disabled
System Table Selection: Devicetree

With RPI_EFI.fd test build from Jan 31st copied over the original in the setup described above:

System Table Selection: Devicetree
DT Reload XHCI firmware: Disabled

dmesg_devicetree.txt

System Table Selection: Devicetree
DT Reload XHCI firmware: Reload

dmesg_devicetree_xhci_reload.txt

[CE1CECL]

I also had this issue for like a year now? I said it multiple times in the devEco discord, but no one understood. But I figured it out. Downloading and extracting https://github.com/raspberrypi/firmware/archive/refs/heads/master.zip boot folder to the USB and deleting the firmware folder, did it. ACPI+DevTree doesn't still work (nor does DevTree) but ACPI does. Turning off 3GB RAM limit is also what I did. I also did this to config.txt

arm_64bit=1 enable_uart=1 uart_2ndstage=1 enable_gic=1 armstub=RPI_EFI.fd disable_commandline_tags=1 disable_overscan=1 device_tree_address=0x1f0000 device_tree_end=0x200000 dtoverlay=miniuart-bt dtoverlay=upstream-pi4

and then I extracted http://cdimage.debian.org/cdimage/daily-builds/daily/current/arm64/iso-cd/debian-testing-arm64-netinst.iso which I am currently installing to the USB, and its working so far. Will edit if something changes. Replace the deleted FW with http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/testing/current/firmware.zip You also want to delete kerne.img where is the 4 (or more) files in https://github.com/raspberrypi/firmware/archive/refs/heads/master.zip

[valtzu]

I think I had the same issue and was finally able to resolve it.

usb works and no errors with the older dtb.

Earlier versions work because the code in fw which removes the pci node does not find the pci node as it was renamed/moved in the device tree – so then it's not removed and OS will find it.

With the more recent versions, everything works fine if I just remove the whole removing of pci node code block:

https://github.com/valtzu/rpi-efi-firmware/blob/main/0002-RPi4-fix-usb-on-recent-kernels.patch

I imagine that is not 100% backwards compatible though, but works fine with 6+ kernels booted from usb

[sanderhollaar]

I think I had the same issue and was finally able to resolve it. [..] I imagine that is not 100% backwards compatible though, but works fine with 6+ kernels booted from usb

Raspberry Pi4 8GB here.

I've spend weeks debugging why I do have USB with the NixOS-provided generic kernel linuxPackages_latest, and do not have USB with the NixOS-provided linuxKernel.kernels.linux_rpi4, nor with 6.1.58-v8 and 6.6.0-rc7-v8 from https://github.com/raspberrypi/linux compiled with bcm2711_defconfig. It just did not make sense at all. Untill I found this issue.

I've replaced /boot/RPI_EFI.fd with your https://github.com/valtzu/rpi-efi-firmware/releases/download/0.2.2/RPI_EFI.fd and now I have working USB with both 6.1.58-v8 and 6.6.0-rc7-v8 :partying_face:

Should this go upstream?