Using a SD card to boot from a USB device?

Greetings!

I have been researching the USB boot process so that I can boot my A02 Jetson Nano from a USB device (an external SSD), and it has been an adventure!

In essence it doesn’t automatically USB boot from cold-and-dark without some strange manipulations, usually unplugging the SSD and plugging it back in again.  And that doesn’t always work.

Further research disclosed that the most likely reason for this is that the Nano doesn’t power-up the USB ports until relatively late in the initial boot sequence, preventing the USB device from presenting itself for enumeration.  The suggested fix is a powered USB hub so that the drive is powered up immediately.  (All my hubs are ancient USB-2 hubs)

Another solution was to modify Uboot to extend the boot delay.  Unfortunately, that requires a Linux host system, downloading the SDK, recompiling Uboot’s binary and re-flashing it.&nbsp: (I don’t have a full-time Linux box, instead I use portable USB flash drives with an ISO image for the infrequent times I need Linux.)

One relatively simple solution that I think will work is to allow the Nano to begin the boot process using a SD card and then transfer boot authority to the USB device after it’s had a moment or two to wake up and have its first cup of coffee.

I have not been able to find any articles detailing this process as they’ve all been superseded by the one device method.

I would appreciate any guidance with this you can provide.

See if this works:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3274/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E0HO0HA

As I mentioned here:

I decided to conduct an experiment to see if I could force an update to the QSPI.

  1. I decided to download, install, and spend time updating the Jetson SDK.
  2. I attempted to flash the OS to the Nano, with a deliberately undersized SD card so it wouldn’t take so long.

Result:

  1. I was able to witness a glorious failure while flashing. :wink:
  2. I don’t know how to how to verify the revision level of the QSPI so I can’t be absolutely sure that the QSPI was updated, but after the flash attempt it appears the Nano’s ability to boot from the external SSD has improved as it seems to boot more reliably.

Maybe someone should update the instructions to indicate that, somehow or other, an update to the QSPI would help?

Thanks!

I don’t really know what’s your point in both posts.
For updating QSPI, you can simply do:

sudo ./flash.sh jetson-nano-qspi internal

Easy friend!  Easy!

That’s nice to know, I did not know that.

[rant]
One of the things that I find the most difficult about the Jetson Nano is the documentation and the way it is organized.

This isn’t to say I am unfamiliar with documentation per se, having worked in software development, as well as high-reliability/mil-spec aerospace for decades before I retired.

But!

(IMHO) the Jetson documentation is some of the most labyrinthine documentation I have ever found where even a well considered web search, (or three!), returns either nothing, or results that are so confusing that it beggars the imagination.

So far, in the last several weeks of research I have discovered that to do anything with the Uboot boot-time parameters I have to, apparently, completely recompile the entire Uboot binary from scratch, and - based on my research - the only way to re-flash the QSPI was to formally re-flash the entire system using the SDK.
[/rant]

You say that to flash the QSPI, all I need to do is sudo ./flash.sh jetson-nano-qspi internal, right?  Thank you, this is a much easier method than installing the entire SDK and spending a day updating it.

However,

  • What “current working directory” (./) are you in?  Nothing specifies where to even start looking for this stuff.
  • How do I know if the QSPI I am going to flash is the most current one for the Jetson Nano I have?

Forgive my frustration, but I have been battling this particular dragon for the last few weeks and I’m beginning to run out of migraine headache medicine. :wink:

Under Linux_for_Tegra where those xxx.conf file is located.

We don’t really have a way of checking it.
Maybe there’s something like the build time of U-Boot in the booting log.

1 Like

Ref:
https://forums.developer.nvidia.com/t/how-to-make-the-boot-screen-display-boot-messages-instead-of-the-nvidia-splash-screen/285841

https://forums.developer.nvidia.com/t/where-can-i-change-default-cmdline-cbootargs-and-other-questions-regarding-jetson-nano-boot-process/82087/6

@DaveYYY
I am beginning to suspect that some of the angst is a result of the Nano, (et. al.), being designed as sophisticated embedded systems rather than simply kit-bashed Linux systems like the Raspberry Pi that act like miniature Linux desktops.  As a result there is, and must be, a lot of internal visibility into the very dirtiest and grittiest parts of the system.

It’s gnarly because that’s the way it is, right?

My apologies for my frustration, it just seems that information that should be obvious, isn’t, and I hate incessantly bothering you folks with silly noob questions that I should be able to answer for myself.

You bump into a issue/problem, you ask it here, and we answer/solve it.
That’s all.

There are a lot more users asking questions much more noob than you do here.
Please don’t feel guilty.

1 Like

Is it correct to assume that, in the case where a current working directory is assumed, but not specified, (i.e. /home/user/[something]/. . . .), that the “default” directory is the L4T directory, (i.e. /home/[user]/nvidia/nvidia_sdk/JetPack_4.6.2_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra) in my particular case?

I also think that part of the confusion (at least for me) is that half of the stuff is on the Jetson board itself and the other half is on the host. (:man_facepalming:)

You always do everything under Linux_for_Tegra.

Ultimately I decided to side-step the issue by transferring my development environment back to a SD card for the time being.

: shrugging_shoulders:

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