CM4S: Enabling xhci from an overlay makes the system hang

[iluminat23]

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 the config.txt it works as expected. If we enable the xhci noce in our overlay the system hangs at boot.

/dts-v1/;
/plugin/;

/{
	compatible = "brcm,bcm2711";

	fragment@1 {
		target = <&xhci>;
		#address-cells = <1>;
		#size-cells = <1>;
		xhci_usb: __overlay__ {
			status = "okay";

		};
	};
};

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 the config.txt

Device (s)

Other

System

pi@raspberrypi:~ $ cat /etc/rpi-issue 
Raspberry Pi reference 2024-03-15
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f19ee211ddafcae300827f953d143de92a5c6624, stage2

pi@raspberrypi:~ $ vcgencmd version
Feb 29 2024 12:24:53 
Copyright (c) 2012 Broadcom
version f4e2138c2adc8f3a92a3a65939e458f11d7298ba (clean) (release) (start)

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

Logs

Additional context

No response

[pelwell]

we don't want to touch the config.txt

How are you applying the overlays - U-boot?

[iluminat23]

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

[pelwell]

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.

[iluminat23]

This would be great for us

[pelwell]

Here's a test firmware (the various start4 and fixup4 files) that should do what you want:
xhci_test_240325.zip
It's tested to the extent that it boots with and without the xhci node being enabled, and with it enabled an extra USB bus appeared.

[iluminat23]

Hi Phil, this works great.

[pelwell]

Cool. We're happy that it's a low-risk change, so it will appear in the next firmware release.

[iluminat23]

Will this also appear for bullseye?

[pelwell]

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.

[dirkdimehead]

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:
MESS:00:00:32.645213:0: Loaded 'Image.bin' to 0x200000 size 0x15dea00
MESS:00:00:32.651393:0: Device tree loaded to 0x2eff2c00 (size 0xd3a0)
MESS:00:00:32.660049:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:32.666693:0: uart: Baud rate change done...
MESS:00:00:32.668715:0:

[pelwell]

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.