Note that Figure 6. above is how a 'Colibri iMX8QXP 2GB WB IT v1.0 ’ is assembled. Figure 7 does give the wiring for a (not yet available) module without a on module Wi-Fi chip.
I think you misinterpret the bypass function of the USB3803.
The “USB3803” USB Hub allows to connect the upstream port with the USB_H port through the bypass HW signal without providing any Hub functionality. The Linux kernel with our device tree does take the Hub out of Reset and out of that bypass mode so that it works as a USB Hub providing its USB services to the USB_H port AND the Wi-Fi module.
The question is what is it exactly that you want to achieve, respectively what does not work for you in the current configuration?
If you do not care about the USB connection to the Wi-Fi module and you do want to not go through an additional USB Hub you could disable the USB3803 driver in the device tree and take the USB3803 out of reset but keep it in bypass mode by configuring the FXL6408 drivers initial state accordingly.
Thanks for the clarification. I was indeed referring to Figure 6. I was misinterpreting the bypass function of the USB3803.
So by default the Toradex kernel and device tree will enable use of the USB3803 as a Hub and USB_H will work externally.
I have configured USB OTG2 as a USB Device and after the configuration script I see no activity on either Windows or Ubuntu USB Host PC. This same script works on iMX8 MEK NXP hardware to configure the port as USB Device. I have attached the script for reference.
Any suggestion for changes to Toradex Linux kernel configuration and/or device tree configuration are welcome.
USB Hub here means: The i.MX8X plays the USB Host role, on USB_H is a host port and you connect a USB device there.
Whether or not the USB3803 allows to reverse the USB roles if in bypass mode I do not know. The datasheet clearly still marks the port as upstream on the i.MX8X side and downstream on the USB_H connector side. However, as the datasheet also talks about an analog switch it may be that your configuration works if setting the USB3803 into bypass mode.
While we did not yet bring-up the USB client functionality and the automatic role switching on USB_C that would be the port meant to be used for that. Do you have any particular reason for trying this on USB_H?
I am using this port as a USB Device because that is what our hardware team has laid it out for. The OTG1 port should act as a USB Host, but that is also not working. The OTG1 hardware is fine because when I use an NXP MEK based u-boot (with subtle modifications for this hardware) I can see a connected USB stick as a mass storage device from u-boot prompt. When booting Toradex kernel and connecting the same USB stick to this port I see no activity in the kernel dmesg. This was going to be my next conversation with you so I am jumping ahead of myself.
Back to the OTG2 issue. I disabled the “usb3803@08” by adding a label:
I also set the “inital_output” to 0x15 for the gpio expander to keep the bypass gpio active (expander GPIO 5 LOW) and the reset gpio inactive (expander GPIO 4 HIGH) to keep the part out of reset and in bypass mode with the following:
I am using this port as a USB Device because that is what our hardware team has laid it out for.
I really doubt this will work. And even if it would it is still a very very bad idea as the USBH port on any other module is always just a host port only.
The OTG1 port should act as a USB Host,
That port is a switchable device/host port on any of our Colibri modules since the dawn of time. So both configurations should be possible.
but that is also not working. The OTG1 hardware is fine because when I use an NXP MEK based u-boot (with subtle modifications for this hardware) I can see a connected USB stick as a mass storage device from u-boot prompt.
Given the existence of a regular USB host port USBH such configuration really does not make much sense for us especially in the boot loader where USBC is just that a client port to be used e.g. as USB mass storage (UMS).
When booting Toradex kernel and connecting the same USB stick to this port I see no activity in the kernel dmesg. This was going to be my next conversation with you so I am jumping ahead of myself.
I guess that was just never really implemented/supported.
Please note that the Colibri iMX8QXP 2GB WB IT V1.0A was an early access sample and as such is no longer supported.