-
Notifications
You must be signed in to change notification settings - Fork 5k
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
CM4S: Enabling xhci from an overlay makes the system hang #6062
Comments
How are you applying the overlays - U-boot? |
No, with a hat-eeprom. This Test was done with the config.txt and an cm4 io-board. But it's the same on our custom hardware |
There is a surprising amount that needs to be done when enabling the XHCI controller on that port. I don't think it's reasonable to expect the kernel to do it. However, the firmware could fairly easily look at the state of the USB controllers in DT, determine that the XHCI controller is wanted, and set otg_mode=1 automatically. We'll give it some thought. |
This would be great for us |
Here's a test firmware (the various start4 and fixup4 files) that should do what you want: |
Hi Phil, this works great. |
Cool. We're happy that it's a low-risk change, so it will appear in the next firmware release. |
Will this also appear for bullseye? |
There's no reason it couldn't. If we were to make further bullseye releases, they would include this new firmware and presumably any 6.1 backports, but the frequency of such releases is TBD. |
sorry for bothering you here. I have a similar problem. If I activate BCM-USB-MSD in the BOOT_ORDER and have xhci (regardless of otg_mode=1 or overlay) active at the same time, the boot process hangs until I insert a USB stick: |
This is definitely not the right place - https://github.com/raspberrypi/rpi-eeprom would be better. You'll need to explain which boot mode you are expecting it to use, and where that boot mode is in the sequence. |
See: raspberrypi/linux#6062 firmware: arm_dt: Improve power HAT+ support firmware: arm_loader: Add user otp read and write functions See: raspberrypi/linux#6014 firmware: dtoverlay: Use %u when converting u32s to strings See: raspberrypi/linux#6039 firmware: video_decode: CONFIGCHANGED not wanted with lack of aspect ratio in new frame See: https://forum.libreelec.tv/thread/28391-cvideoplayeraudio-process-stream-stalled/?postID=190597#post190597
See: raspberrypi/linux#6062 firmware: arm_dt: Improve power HAT+ support firmware: arm_loader: Add user otp read and write functions See: raspberrypi/linux#6014 firmware: dtoverlay: Use %u when converting u32s to strings See: raspberrypi/linux#6039 firmware: video_decode: CONFIGCHANGED not wanted with lack of aspect ratio in new frame See: https://forum.libreelec.tv/thread/28391-cvideoplayeraudio-process-stream-stalled/?postID=190597#post190597
Describe the bug
We configure our devices solely over devicetree overlays, as we don't want to touch the
config.txt
. We are using one image for all devices and the loaded overlay takes care of the h/w configuration.For one device we use a CM4S and we want to use the xhci usb controller instead of the dwc2. If we enable the xhci by setting
otg_mode=1
in theconfig.txt
it works as expected. If we enable the xhci noce in our overlay the system hangs at boot.I guess the bootloader does some magic (enabling some clocks?) when
otg_mode=1
is set in the config. I think it should be possible to do this in the kernel as well and get proper support for this in the kernel.Steps to reproduce the behaviour
Enable the xhci noce in the devicetree and boot the system without
otg_mode=1
in theconfig.txt
Device (s)
Other
System
Logs
Additional context
No response
The text was updated successfully, but these errors were encountered: