| Message ID | 20231126025612.12522-1-wahrenst@gmx.net |
|---|---|
| Headers | show |
| Series | ARM: dts: bcm2711-rpi-cm4-io: Enable xHCI host | expand |
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. 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 > Stefan Wahren (3): > dt-bindings: usb: xhci: Add optional power-domains > ARM: dts: bcm2711: Add generic xHCI > ARM: dts: bcm2711-rpi-cm4-io: Enable xHCI host > > Documentation/devicetree/bindings/usb/generic-xhci.yaml | 3 +++ > arch/arm/boot/dts/broadcom/bcm2711-rpi-cm4-io.dts | 9 ++++++++- > arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi | 5 +++++ > arch/arm/boot/dts/broadcom/bcm2711.dtsi | 9 +++++++++ > 4 files changed, 25 insertions(+), 1 deletion(-) > > -- > 2.34.1 >
On Mon, 27 Nov 2023 at 11:08, Stefan Wahren <wahrenst@gmx.net> wrote: > > 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#L119 What's the question here? Does the XHCI block present in the raspberrypi/linux dtsi file really exist? Yes it does. Phil
Hi Stefan, Stefan Wahren <wahrenst@gmx.net> (2023-11-27): > thanks for testing. Are you absolutely sure that you are using > bcm2711-rpi-cm4-io.dtb from the mainline tree? I'm pretty sure, yes. Starting from the unpatched kernel: root@rpi4-20231108:~# md5sum /boot/firmware/bcm2711-rpi-cm4-io.dtb /usr/lib/linux-image-6.6.0+/broadcom/bcm2711-rpi-cm4-io.dtb 5cbe07e9f85ddfefd21ffe98bf92f5ea /boot/firmware/bcm2711-rpi-cm4-io.dtb 5cbe07e9f85ddfefd21ffe98bf92f5ea /usr/lib/linux-image-6.6.0+/broadcom/bcm2711-rpi-cm4-io.dtb The second file is shipped by the linux-image package built via `make bindeb-pkg`, and sync'd into /boot/firmware as the first one. After deploying the patched kernel, I'm seeing both files getting updated: root@rpi4-20231108:~# md5sum /boot/firmware/bcm2711-rpi-cm4-io.dtb /usr/lib/linux-image-6.6.0+/broadcom/bcm2711-rpi-cm4-io.dtb c6ea63f43dcdf8ecd66dda6c494f52e2 /boot/firmware/bcm2711-rpi-cm4-io.dtb c6ea63f43dcdf8ecd66dda6c494f52e2 /usr/lib/linux-image-6.6.0+/broadcom/bcm2711-rpi-cm4-io.dtb Comparing a copy of the first set of files against the refreshed DTB, I'm seeing the attached (dt)diff. > I would expect the following hardware name: Raspberry Pi Compute > Module 4 IO Board I suppose this is an arm(32) vs. arm64 difference? - setup_arch() in arch/arm/kernel/setup.c does this: machine_desc = mdesc; machine_name = mdesc->name; dump_stack_set_arch_desc("%s", mdesc->name); - setup_machine_fdt() in arch/arm64/kernel/setup.c does that: name = of_flat_dt_get_machine_name(); if (!name) return; pr_info("Machine model: %s\n", name); dump_stack_set_arch_desc("%s (DT)", name); So I'd guess you're testing on arm(32) and seeing the name embedded in the DTB while I'm testing on arm64 and seeing the name as filled by the bootloader? > Be aware the arm files has been moved into a broadcom subdirectory. Thanks for mentioning that, but I've been working on arm64 exclusively, and those files have always been shipped in that broadcom subdirectory anyway. With 64-bit capable hardware, I didn't think of mentioning I was testing 64-bit kernel and user space (Debian 12, arm64), sorry about that. Cheers,
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#L119 >>> What'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? Thanks > This also > triggers the enabling of the node with the label or alias "xhci". > > CM4 is not handled any differently to the other 2711-based devices in > this regard. > > Phil
Stefan Wahren <wahrenst@gmx.net> (2023-11-27): > Could you please provide the following information: > > - settings of config.txt Here you go: arm_64bit=1 enable_uart=1 upstream_kernel=1 kernel=vmlinuz-6.6.0+ initramfs initrd.img-6.6.0+ enable_jtag_gpio=1 force_turbo=1 > - VC firmware version This is pieeprom-2023-01-11.bin I know there's pieeprom-2023-05-11.bin as well, but I've been keeping the former as a constant throughout the PCIe patch series testing once I realized how critical it was (old beta EEPROM versions found in some CM4s made everything much harder initially). In case the config matters: [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 BOOT_ORDER=0xf25641 ENABLE_SELF_UPDATE=1 > - did you use arm64/defconfig or something special? I'm using a “distribution config”, starting from the latest arm64 config found in Debian unstable (6.5.10-1), and applying `make oldconfig`. You'll find it attached. Cheers,
Stefan Wahren <wahrenst@gmx.net> (2023-11-27): > Sorry, i was a little bit unspecific. This the first level bootloader > stored in the EEPROM. I meant the VC firmware version from the SD card > which is logged in dmesg: > > raspberrypi-firmware soc:firmware: Attached to firmware from ... [ 2.677987] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-08-26T14:03:16 Cheers,
Hi Cyril, Am 27.11.23 um 14:02 schrieb Cyril Brulebois: > Stefan Wahren <wahrenst@gmx.net> (2023-11-27): >> Could you please provide the following information: >> >> - settings of config.txt > Here you go: > > arm_64bit=1 > enable_uart=1 > upstream_kernel=1 > > kernel=vmlinuz-6.6.0+ > initramfs initrd.img-6.6.0+ > > enable_jtag_gpio=1 > force_turbo=1 can you please check what happens if you add the following to config.txt: [cm4] otg_mode=1 > >> - VC firmware version > This is pieeprom-2023-01-11.bin > > I know there's pieeprom-2023-05-11.bin as well, but I've been keeping > the former as a constant throughout the PCIe patch series testing once > I realized how critical it was (old beta EEPROM versions found in some > CM4s made everything much harder initially). > > In case the config matters: > > [all] > BOOT_UART=0 > WAKE_ON_GPIO=1 > POWER_OFF_ON_HALT=0 > BOOT_ORDER=0xf25641 > ENABLE_SELF_UPDATE=1 > >> - did you use arm64/defconfig or something special? > I'm using a “distribution config”, starting from the latest arm64 config > found in Debian unstable (6.5.10-1), and applying `make oldconfig`. > > You'll find it attached. > > > Cheers,
Hi Stefan, Stefan Wahren <wahrenst@gmx.net> (2023-11-27): > can you please check what happens if you add the following to > config.txt: > > [cm4] > otg_mode=1 I've only rebooted a few times but the system seems to be booting fine once this setting is added to config.txt. Writing stuff to a USB stick with or without the patches seems to give similar performances: ~ 18 MB/s after 3 minutes of copying /dev/null to /dev/sda with a 32M block size; similar CPU usage for dd, usb-storage, and the relevant kworker thread. Cheers,
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@gmx.net> 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#L119 >>>>>>>> >>>>>>> What'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. >>> >>> Phil >> >> Well 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@broadcom.com> > > 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. I'm using the following firmware: raspberrypi-firmware soc:firmware: Attached to firmware from 2023-03-17T10:50:39 Is this DTS difference a problem? upstream -> xhci: usb@7e9c0000 downstream -> xhci: xhci@7e9c0000
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@gmx.net> 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#L119 >>>>>>>>> >>>>>>>> What'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. >>>> >>>> Phil >>> >>> Well 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@broadcom.com> >> >> 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?