USB does not work

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

Hi
In our custom board, when we put TX2 in recovery mode, the USB port work properly and we can flash the TX2. But when Linux boots, USB does not work. I check +5Volt on USB connector and there is no voltage +5.
But … when I connect TX1 to our custom board, every thing is OK. Why?!

aa
aa786×472 111 KB

Boot logs for TX2 is attached.

2

I couldn’t give you specifics, but the odds are quite high that if the physical wiring is correct, then this is entirely a case of needing edits to the device tree. Take a closer look at the PINMUX spreadsheet, and the device tree as it relates to any changes in USB wiring and/or power rails. Also make sure your ID pin detect is set up correctly (if in device mode then it cannot be in host mode).

3

Many factors can cause a USB connectivity issue such as;

1. BIOS

  • USB isn’t set as first hard drive on BIOS.
  • There might be a problem with BIOS or UEFI boot partitions or files.
  • If you didn’t turn off secure Boot.
  • Might be your USB drive isn’t compatible with computers BIOS or UEFI boot mode
  • You are using an incorrect partition table
  • You are using Out of dated BIOS/UEFI firmware.
  • Your system has Junk in volatile memory
  1. GRUB

*You are using root partition in grub.

  • You might be using an incorrect path to ISO in grub.
  • You may have incorrect persistent-path, (if used), in grub
  • Grub menuentry structure of your system is not suiting OS
  • You are providing the path to incorrect file type for vmlinuz and initrd (.efi and .lz)
4

Embedded systems do not have a BIOS, but the same functionality exists from several binary partitions. The concept is the same and still valid as what you mention, but the software providing this differs (or in the case of device tree, the firmware is part of the function which a BIOS would have performed). Think of PINMUX spreadsheet and its output, including parts of the device tree, to be what used to be “BIOS”.

Similar for GRUB, this is only on desktop PCs. Most Jetsons have U-Boot, plus some earlier boot stages…and these have the same function which you mention, but for arm32/arm64. The Xavier and Xavier NX don’t even use U-Boot, but those “earlier” boot stages have that functionality.

You’ll find that the older arm32 systems could use the zImage compressed image format, whereas the desktop PC uses the vmlinuz variant for compression. Same idea. However, when ARM-based systems transitioned from 32-bit to 64-bit the bootloader itself remained 32-bit, and zImage was skipped (presumably there was some address space limitations), and arm64 transitioned to an uncompressed Image format. Everyone who builds zImage or vmlinuz also builds Image, and then this is compressed to the zImage or vmlinuz format. Everything you mention about this is still correct, but the file names and programs executing this differ once you get to arm64.

Just for trivia, the operating system itself is still on a main partition. Sometimes people want to back up all partitions, but this is similar to someone on a PC backing up the bootloader and the CMOS BIOS/UEFI itself. Whenever flashing the non-rootfs content is what you would value. The only time you’d care about the other “standardized” content (which is easily flashed correctly without effort) is if you have custom hardware with a custom device tree or other hardware which is essentially part of boot prior to the Linux kernel loading.

EDIT: It is rather fascinating when you begin to see how the earlier boot stages fit together and how they are the same or different compared to the PC. One of the biggest challenges for embedded is that there is no standardized boot environment or services the way a PC motherboard has. It is like working on a custom BIOS by the end user on every different board model.

5

Hi linuxdev,
Thanks.

1_There is no info about USB0_OTG_ID in TX2 PINMUX spreadsheet. In EVM schematic, USB0_OTG_ID is connected to A36. How can I find A36 GPIO number?!
I can’t find defining an using of USB0_OTG_ID in dts, so I can’t do any changes

2_What is relation between GPIO number and TEGRA_AON_GPIO(X, Y) or TEGRA_MAIN_GPIO in dts?

Please guide me

6

I do not actually know a direct answer to that. It is possible that the USB0_OTG_ID is fixed and not actually a configurable GPIO. On the carrier board schematic for the reference board everything which is GPIO, and bound to some particular function for that default use, has “GPIO” in its name. USB0_OTG_ID has no such leading “GPIO” in its name, so I suspect that there is no configuration possible, and that it is this pin and only this function.

This does not mean that there are not other configuration requirements for USB, e.g., which controller may have some choices, and there will be various possibilities within a controller.

Someone who has worked on a custom carrier board USB would have to answer.

8

Hi,
For developing custom USB lane mapping, please check product design guide and adaptation guide:
https://developer.nvidia.com/embedded/dlc/jetson-tx2-series-oem-product-design-guide
https://developer.nvidia.com/embedded/dlc/Tegra_Linux_Driver_Package_TX2_Adaptation_Guide