Is there any way to disable USB3 OTG in the recovery bootloader other than setting the ODM data to disable all USB3?
It interferes with a USB3 hub on one of our carriers preventing it from flashing. USB OTG works fine in all the other bootloaders, it is just recovery nvtboot that has issues.
The micro-OTG port is not wired for USB3. There is no possibility of it ever being USB3.
The full-sized type-A port is capable of USB3.
I know it isn’t routed, however USB3 OTG is still enabled in the Recovery Bootloader and is interfering with an USB3 hub on our board preventing it from flashing. We are not using the Dev kit.
Is your bootloader modified? So far as I know all of the standard L4T releases using U-Boot lack the ability to become USB3 during the boot stage. The driver for USB3 has not been ported to U-Boot…so even if the port on a custom board is USB3-compatible there probably isn’t a possibility of any port attempting to be in USB3 mode without porting the driver. Seeing USB3 mode during boot stage is quite peculiar, it shouldn’t be possible.
Have you verified with a logic analyzer that the port itself has seen USB3 traffic at the PHY? Or is the problem something showing up only in log files somewhere? I can see the possibility that U-Boot was told to look for USB3 hardware (or in some way was told the port must be USB3 mode), but not that the driver actually exists in a way that the PHY would ever see it. Looking for USB3 drivers for hardware in U-Boot would be different to debug versus actually having USB3 and disabling it…not sure what is going on there.
FYI, something to illustrate is that when someone boots from a USB3 drive on a Jetson the full-sized port must be told to run only at USB2 speeds once Linux loads. In cases where the port changes from USB2 mode in U-Boot to USB3 mode under the Linux kernel the port will re-enumerate and the rootfs would be lost at a critical moment of boot. Many people have asked about getting a USB3 driver within U-Boot, but so far I don’t believe this exists.
Note: Recovery mode, when run through flash software, downloads a version of fastboot as a partial operating system. The same is true for fastboot, it has no USB3 driver.
It is 100% enabled in the recovery bootloader which is CBoot based but no source is available for the recovery bootloader, only the standard. Fastboot is not used anymore, it hasn’t been for years now.
I have confirmed it is the USB3 causing the issue. We are working around it by disabling USB3 during the flash and manually writing the partition to re-enable it after the main flash. Not ideal.
During flash fastboot.bin is temporarily downloaded…this is what supports a serial UART during flash. You’ll see fastboot downloaded during flash even now, but it doesn’t stick around after reboot.
The CBoot observation is interesting…it makes sense that something in firmware might make this possible even though U-Boot doesn’t have the driver. So is it correct you are seeing USB3 traffic of some sort during CBoot stage?
I actually have a USB1.1 HUB which I use on occasion to force a USB2 port back to 1.1 mode for use with a protocol analyzer, and I suppose there isn’t any reason a USB2 HUB couldn’t do the same with a USB3 port, but it brings up a topic that probably has use.
Can someone from NVIDIA confirm what USB3 traffic might exist during CBoot? I am reminded of issues people have flashing from a VM where the port is re-enumerating and the VM loses the port. Maybe this is related to switching between USB3 and USB2 as Cboot transitions to U-Boot.
Please check bootloader/partner/common/drivers/usbf/xusbf/ in cboot source
https://developer.nvidia.com/embedded/dlc/cboot-source-r2821
I looked at that but it is not CBoot that causes issues, only the recovery bootloader which We cannot build because the source for the recovery/flashing applications are not provided.
Hi pnewmanCTI,
We need to reproduce the issue first. Can it be reproduced on Dev kit?
Hi pnewmanCTI,
Have you clarified the cause and resolved the problem?
Or this is still an issue to support?
Please help to update the status to move it forward.
Thanks