I want to flash the os of the nvidia jetson nano with VM firmware ubuntu 18.04. USB connection is fine. when I tried to do the flashing step, suddenly device seems to be undetected, still USB connection is fine established, I checked it with terminal lsusb.
I would be grateful if you help me. In the past I did the same and it worked, but now is not working.
The VM is at fault. During a flash USB will disconnect and reconnect. Your VM is only configured at the start, and is failing to pick up the reconnect. You’d have to ask the vendor of the VM how to hold the connection no matter how often there is a USB disconnect/reconnect. Also, if it is WSL2, then once that works, loopback will fail if any image creation is needed.
I’m having the same problem my drive is brand new. Do I need to format the drive first before putting it in the Orin nana 8gb developer kit? Thank you
Are you using a prebuilt image for the Orin Nano? If so, then applications like Balena Etcher and dd (on Linux) will apply those to the partition such that the filesystem itself is already present from the image. If you are building your own image, and then adding it to the SD card, then it needs to first be partitioned and formatted. I think some models of Orin only work with the newest R35.3.1 release (the list of releases is here). QSPI likely must be flashed at least once on any of the SD card models, which is separate from the SD card.
It works on the sd card but i want it running on the NVMe
I used Etcher to get on sad card
Sd card
Simply copying to the NVMe is not sufficient, but it is a start. I don’t have an NVMe to work with, but I’ll give some background which might be useful.
Any application which works with files and directories has to understand the underlying filesystem. That filesystem is from formatting a partition. This is not what you want.
A partition itself is just binary data. To copy binary data there is no need to understand a filesystem, and in fact, if that binary data has a filesystem in it, then copying the binary data also copies the filesystem with it.
I don’t really use Windows for any of this, but the Linux explanation still works (but with different tools). The dd tool can be told to read a partition, and copy it somewhere else. Unlike most tools, this copies binary data 100% bit-for-bit exact. One could copy a partition, create it as a file, and the file itself would not be useful. However, a tool like loopback could “cover” the file to make it appear as a partition, and then the loopback device would suddenly look just like the actual partition. Ignoring loopback, one could also use dd to place that file on a raw disk, and that partition would magically appear on that disk (there are a number of requirements though, e.g., not overwriting something important, and not having issues with the metadata). So that copy can be a file, but it isn’t a partition until it is installed as binary data on a raw disk, and not as a file within a partition.
You can use something like dd (I think Balena Etcher is a less powerful tool, but the same idea as dd) to directly copy the bit-for-bit exact binary image of a partition from the SD card to the NVMe (I don’t know if Windows allows that, but it is trivial on Linux). A proper way to do this might include first creating an unformatted partition on the NVMe which is an exact match to the size you will copy (the partition size would be placed within the extents of that partition).
The Jetson would still need to find a way to “point” at the new drive. I can’t help on that, but usually it involves an initrd flash (Jetsons don’t have a BIOS, so a flash is equivalent to installing (A) the BIOS equivalent, (B) the bootloader, and (C) the operating system; the initrd flash compensates for some of those missing BIOS functions).
If you can create a partition on the NVMe which is an exact byte size equivalent to what the partition size is on the SD card, then that is the start. I’m not sure how to do that on Windows, but on Linux it is easy to deal with exact byte sizes. Then either Balena Etcher or dd could in theory directly copy the binary image from the SD card into that partition.
Incidentally, the SD card’s content might still matter due to looking at the “/boot” content of the first device pointed to. That pointer might include the SD card’s extlinux.conf, but I’m not sure since I (A) don’t have a an Orin Nano, and (B) don’t have an NVMe.
Also, if you placed an image on the SD card, then Balena Etcher could place that same image on an NVMe. It’s just semantics to copy from the SD to the NVMe versus from some stock image to NVMe. One thing is for sure though: If your SD card is not modified, then it is safe to try whatever you want on the NVMe and see if it works. You could also clone the SD card for safety before starting (I have no advice for that on Windows).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.