Power up USB devices sooner during bootup, or delay access to them during boot



I am planning to use my Nano (original) as part of a robot that may be outside of my immediate control or in inaccessible locations.

Likewise, there is the possibility that the robot may need to boot/reboot while it’s inaccessible.

At present, the ability for the Jetson Nano to successfully boot/reboot from external media is not sufficiently reliable.  It succeeds only about 60-70% of the time, otherwise it fails over to the next boot choice, (BOOTP over the network), and proceeds to get stuck in BOOTP Hell, requesting data from a BOOTP server that doesn’t exist.

The Question:
Is it possible for the Nano’s boot process to either:

  1. Have Uboot allow more time for the USB device to come online before failing over to BOOTP?

  2. Power up the USB ports sooner, preferably at power on, so that an external device is ready to enumerate when Uboot asks it to?

Why this is a problem:

  1. During boot time, (and perhaps during run time too), the USB ports are not powered up until something makes a request to use them - and only then is that subsection enabled and only then is power presented to the USB ports.  For example, the USB ports are not supplied power until Uboot decides to access them.

  2. USB devices can take several seconds to power-up, internally configure themselves, and then start the enumeration handshake process.

  3. Uboot’s delay before failing-over to the next boot method is almost exactly the same as the power-up time for USB external media devices.

The result is a race condition.

  • Does the boot-loader win, not see the USB device, and then fail over to the next boot choice, (BOOTP)?

  • Or does the USB device power-up and enumerate fast enough for it to actively start booting the system?

Based on my experiments so far, the USB device wins the boot-race about 60 - 70% of the time, otherwise it gets stuck polling for a BOOTP server and gets stuck.

For a robot that is expected to function independently, (and may be forced to re-boot itself using a watchdog timer if the O/S hangs), a 60-or-so percent probability of success is not good enough.  It needs to be virtually guaranteed to always boot, barring especially extraordinary and unforeseen situations.

Hi jimrh,

Are you using the devkit or custom board for Jetson Nano?
What’s your Jetpack version in use?

Are you booting the board from network?

Have you tried to just boot the board from eMMC/SD?

May I know the block diagram of your connection on your robot?

Answers to your questions:

  1. I am using an original, (one camera port), dev-kit board.
    (Side note:  When the Nano first came out years ago, I grabbed it like a thief and loose money!  The later version wasn’t even a gleam in it’s daddy’s eyes yet.)

  2. I am NOT booting from the network.  The network is attached because I use it after the device boots.

  3. Booting from a local SD card always works because it receives power at power-up so it’s already “booted up” and is ready to enumerate immediately.

  4. I don’t have a “block diagram” available, however it is sufficient to note that the original target processor for this robot, (the GoPiGo-3), is a Raspberry Pi-3 or Pi-4.  (Development work is being done to port the software to the Pi-5.)

  5. My problem, (and hence this request), is to absolutely guarantee that the controller device will absolutely, always be guaranteed to boot without fail.  Because the USB port, (and the attached SSD device), get power so relatively late in the boot process, it is often not possible for the external SSD device to power up, become ready, and begin enumeration before the Nano gives up on it and falls back to BOOTP.  (And becomes stuck there. . .)

To solve this problem, I want to find out if it is possible for the USB/SSD device can receive power earlier in the boot process so that it has time to become ready to enumerate when the device asks for it.  I would be happy if we could do something as simple as giving the USB devices more “retries” to give it time to enumerate and become active.

My Project:
The goal of this project is to port the GoPiGo-3 Raspberry Pi robot libraries to the Jetson Nano, (and thence possibly to the Orion versions later on), because some of the more advanced Tensor Flow, SLAM, Object Recognition, and other fun AI-type stuff really doesn’t fly well on a Pi.  The theory I am proposing to test is to equip the GoPiGo-3 with a Jetson Nano and re-try the more advanced, processor intensive, AI stuff that currently requires an off-board PC to do the heavy lifting.

My current project is simply the first-stage of the porting process:  Getting the stuff to run on a Nano without crashing - and perhaps even some level of functionality - which doesn’t depend on a connection to the robot’s logic board.  In fact, I am deliberately AVOIDING connecting it to the robot because I don’t know what the GPIO pins are doing at this point and I don’t want to risk damaging the robot’s controller board by asking it to do stupid things like running the motors in both the forward and reverse directions at the same time. :wink:

I want to use an attached USB SSD because development/AI processing work is a high write-pressure environment - and SD cards are notoriously allergic to high write pressures1.  Even with A1 or A2 “application” rated SD cards, the R/W performance is considerably worse than an attached SSD device2 3 4.  Additionally, the largest share of SSD devices support TRIM, (discard), which greatly reduces the write pressure on the device by helping the device optimize dirty write/erase block scavenging.  On the other hand, SD cards generally do not support TRIM/discard, (though some pretend to), so there is no way to optimize garbage collection on these devices to reduce write pressure.

One additional point:
If you’ve done any studies on SD card capabilities and technology, you will realize that SD cards were specifically designed to be “read mostly” devices - suitable for cameras and such.  Even the “Application rated” SD cards don’t really achieve parity with SSD devices because, despite the improvements in R/W performance, they’re still really read-mostly devices at heart.  They’ve been adopted by micro-controller designers because of their small size, relatively large capacity, and low cost per unit.

In these kinds of stand-alone micro-controller applications, R/W performance is not a primary limiting factor, processor speed and capabilities usually overshadow the speed of the local SD card.  It’s only with the development of faster and more powerful systems, (like the Pi-4 and 5, the Jetson/Orion boards, etc.), that SD performance has become a significant factor - hence the desire to boot from faster external media like USB attached SSDs.


  1. SD longevity:

  2. Game application performance:

  3. Performance on a Raspberry Pi:

  4. It should be noted that some game platforms don’t see a significant performance impact, but it appears to be highly platform specific with the more advanced platforms showing more significant speed increases using a SSD.

I am sure there are other good benchmark sites out there too.

Sorry that I’m not clear about BOOTP.

You can check(and configure) the pinmux spreadsheet to know which the functionality of each pins.

Do you consider using Xavier NX or Orin NX/Nano devkit for NVMe SSD through PCIe?
It seems suitable for your use case to get reliable read/write performance and also boot from it.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.