On 11/27/23 11:22, Stefan Wahren wrote:
Hi, Am 27.11.23 um 19:41 schrieb Florian Fainelli:On 11/27/23 09:44, Justin Chen wrote:On 11/27/23 8:28 AM, Phil Elwell wrote:On Mon, 27 Nov 2023 at 12:39, Stefan Wahren <wahrenst@xxxxxxx> wrote:Hi Phil,Hi Justin, [add Phil] Am 27.11.23 um 07:02 schrieb Justin Chen:On 11/25/23 6:56 PM, Stefan Wahren wrote:In contrast to the Raspberry Pi 4, the Compute Module 4 or the IO board does not have a VL805 USB 3.0 host controller, which is connected via PCIe. Instead, the BCM2711 on the Compute Module provides the built-in xHCI.Does this work? I maintain this built-in xHCI controller internally. I wasn't aware the Compute Module uses this block.i successful tested this with a CM4 (arm 32 bit, multi_v7_lpae_defconfig) with eMMC. Before this series the USB devices (mouse, keyboard) connected to the host interface didn't work. After comparing vendor DTS with mainline i noticed the missing xHCI block [1]. Unfortunately i wasn't able to get further information from the public datasheets. I don't know if the VideoCore does some magic tricks on the xHCI or i missed some downstream xHCI changes.This block is held in reset and needs a bit toggled to get things going. Florian, just to confirm, this is our "brcm,xhci-brcm-v2" block correct? Justin[1] - https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/bcm2711-rpi-ds.dtsi#L119What's the question here? Does the XHCI block present in the raspberrypi/linux dtsi file really exist? Yes it does.since i don't have any documentation about the xHCI block, i assumed the compatible generic-xhci is correct. But Justin seems to suggest that the xHCI block needs some special treatment and we need a specific compatible. Did i missed some xHCI driver changes? Does the VC firmware something to the xHCI especially on CM4?The firmware switches the on-board USB pins from DWC-OTG to XHCI if otg_mode=1 is set in config.txt, or if booting over USB MSD.is this pinctrl/pinmux available from ARM via 0x7e200000 or a different IO address?It's in a different, undocumented block. PhilWell if it works, then maybe I am misunderstanding something here. Maybe its time for me to pick up a CM4 board.There is one on my desk that you are welcome to use, or remote into if you prefer. To answer your earlier question, yes this is the same block as the one present in 72112 for which we use the "brcm,xhci-brcm-v2" compatible string, it would be preferable to have it backed by that compatible string in case we happen to support suspend/resume on the Pi 4B one day, if nothing else. I did confirm that after applying Stefan's patches plus changing my config.txt to have otg_mode=1, USB continues to be fully functional. This is the case with using both "generic-xhci" or "brcm,xhci-brcm-v2" so with the minor request to update the compatible to "brcm,xhci-brcm-v2", this is: Tested-by: Florian Fainelli <florian.fainelli@xxxxxxxxxxxx> Stefan, I am getting a deadlock on boot if I leave your changes in and uncomment dwc_otg=1 in config.txt, is there an alias or something that the boot loader should be patching?sorry but i'm unable reproduce those deadlocks, neither in arm or arm64, with eMMC or without eMMC, xhci builtin or module. If i uncomment this in config.txt, USB host is just disabled.
Here is my config.txt FWIW: # A bit too verbose uart_2ndstage=1 enable_uart=1 arm_64bit=1 # Custom kernel images kernel=kernel8-upstream.img #kernel=kernel7l.img #device_tree=bcm2711-rpi-4-b-UPSTREAM.dtb device_tree=bcm2711-rpi-cm4-io-UPSTREAM.dtb force_turbo=1 # DWC-OTG <=> XHCI #otg_mode=1
I'm using the following firmware: raspberrypi-firmware soc:firmware: Attached to firmware from 2023-03-17T10:50:39
OK, my CM4 is at 2022-07-25T15:10:17, updating to 2023-10-17T15:39:16 does not really show any difference.
Is this DTS difference a problem?
It does not appear so, changing the node unit-name does not affect the results.
upstream -> xhci: usb@7e9c0000 downstream -> xhci: xhci@7e9c0000
Side question: does the VPU boot ROM or firmware take care of configuring the USB PHY somehow? Should not we also have a Device Tree node for it eventually?
-- Florian
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature