Just want to clarify again..
I totally could not read your schematic. None of the things you shared so far is useful unless you give out a clear schematic with also SOM part + USB part.
One has to understand that in boot stages Linux is not running. Instead it is bootloader software, and that software is its own specialty dedicated operating system. Its only goal is to end its life by overwriting itself with Linux. The gist of that is that during bootloader stages drivers must be part of that bootloader software in order to run, and that regardless of how Linux works, this is independent of Linux.
Bootloaders are closely related in the sense that often they are more or less the same drivers as the ones in Linux, although they are always compiled for “bare metal”. There is a very very similar theme here: A driver needs to be able to find hardware (physical addresses) and associate drivers with that address. Something must also tell the driver to load. This is often by use of the device tree.
Typically a device tree would be loaded into the boot software, and then when Linux takes over the device tree is passed to the Linux kernel. Linux might or might not see a slightly edited version of the device tree which boot stages pass to the kernel. There isn’t usually much editing, mostly it is verbatim.
Consider that when Linux runs it is apparently seeing “hot plug” events, such as the plug in of a device to that port being visible and being passed on. It is highly likely that one of these cases are the problem:
- The device tree is not set up for this port in boot software.
- The device tree is set up for the boot software, but nothing is forwarding the plug in detect event.
- The device tree is set up for the boot software, and the plug in event occurs in boot, but no driver is loaded.
- The driver itself might be missing in the boot stages.
It seems likely that your device tree and/or boot stages need adapting for early boot. Linux is inheriting the state of the hardware the moment the kernel overwrites the bootloader, and so if the device can run in Linux, and the device can be detected upon hot plug, that the issue is the USB state prior to the kernel inheriting boot.
Are you certain that your device tree is visible to boot? Are you certain that there is software which triggers to monitor hot plug during the boot stages?
As I already asked, where is the full SOM side connection here?
I only saw you gave out typeC_ID_1V8 here but nothing else.
How does your vbus_det expect to work here?
connector {
compatible = "usb-b-connector", "gpio-usb-b-connector";
label = "micro-USB";
type = "micro";
id-gpio = <&tegra_main_gpio TEGRA234_MAIN_GPIO(Z, 1) GPIO_ACTIVE_HIGH>;
};
Why there is only ID pin here? This won’t make a working OTG function.
USB OTG could work with id pin missing but it would not work with missing vbus_det.
Yes, You are quite right!
I only modify pinmux in bootloader, and add usb otg mode in kernel device tree.
I modify FDT to /boot/dtb/ directory in /boot/extlinux/extlinux.conf file.
Any way, I wander why jp5.1.2 work well, but newer version not?
Our design not use fusb301 chip, use ptn5150 non-i2c mode instead, to fixed our problem, how can I do?
Thansk
It works ID only, VBUS=ID, use usb-conn-gpio.ko.
ID only will not make your OTG fully working between host/device and none.
This design which does not have working OTG is expected.
Thanks for your reply, in above schematic, JP5.1.2 is OK, and USB2.0 is OK (in JP5.1.6).
I want to know newer version begin JP5.1.2 should use ID and VBUS signal to TYPEC port to use otg mode, If so, we will modify our schematic to adapt the condition!
It is not about software change.
It is just your design is wrong since the beginning. JP5.1.2 driver might have some bug which makes your wrong design could still work. But I feel even that is not stable.
You should change the design to have one more GPIO there as VBUS_DET.
With Highest respect for your helping, thanks again!