-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No USB with Vanilla 5.16-rc2 #195
Comments
raspberrypi-bootloader-20211108-1 rpi-eeprom-update
cat /boot/config.txt
Using the bcm2711-rpi-4-b.dtb supplied by kernel-5.16-rc2 grub2 2.06-2 is then loaded by uefi:
I have also tried very basic kernel arguments, no difference:
|
It may be related to the changes in this part of bcm2711-rpi-4-b.dtb? older
newer
usb works and no errors with the older dtb. |
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. |
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. |
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. |
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: 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. |
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. |
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. |
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. |
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:
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. |
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. |
Ah ok, I will re-test ACPI, this time passing acpi=force. |
With passing acpi=force, both the 5.16 and 5.17 upstream kernels boot properly. 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. |
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. |
PS, if you are happy with it a "Tested-by:" on the SPI set would be appreciated. Thanks, |
I have explored some, trying to determine how to include a "Tested-by:" but I am not sure how to do it. 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. |
The easiest is probably just to create a groups.io account, subscribe to edk2-devel, then reply to the message from the web UI. |
The reply has been placed, now awaiting moderator approval. |
I don't think it appeared, were you subscribed to the group before trying to send it? |
Hmm, maybe what I submitted looked like spam? I just replied "Tested by:" and my email. |
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. |
Hmm, I must be looking in the wrong location, because my original reply is here. |
The RPI_EFI.fd build from #195 (comment) doesn't seem to make a difference here. Let me know if you want more information. (From scratch) USB only works OK in ACPI mode:
USB doesnt work in Devicetree mode:
With RPI_EFI.fd test build from Jan 31st copied over the original in the setup described above:
|
I also had this issue for like a year now? I said it multiple times in the devEco discord, but no one understood. arm_64bit=1 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. |
I think I had the same issue and was finally able to resolve it.
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 |
Raspberry Pi4 8GB here. I've spend weeks debugging why I do have USB with the NixOS-provided generic kernel I've replaced Should this go upstream? |
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.
USB keyboard works with UEFI, but once the kernel is loaded, no usb keyboard or mouse.
Resulting in these kernel errors:
With traditional rpi firmware booting, USB works fine.
If ACPI only is selected, no such errors are produced... but then no vc4.
The text was updated successfully, but these errors were encountered: