Hello,
I have a Jetson Xavier NX with a 500GB NVMe SSD.
I’m trying to flash the NVMe with JetPack 4.6 (rev.3) using the SDK manager (over USB).
Host uses Ubuntu 18.04, SDK manager v1.7.3.
When the Ubuntu system configuration wizard should appear (to complete the installation), the Jetson gets stuck in the Nvidia logo screen.
I already tried flashing the eMMC instead, it worked fine and the NVMe was detected.
I also tried flashing from different hosts, got the same result.
Any ideas how to proceed?
Thanks
Hi,
Need to dump the uart log to tell why it got stuck.
If this is a developer kit and you don’t mind having it first boot from the SD card or about a second first you might be able to make things a lot easier by following the approach here:
The effect will pretty much be the same except this installs with one command and doesn’t require flashing first.
Kim Hendrikse
StalkedByTheState
Hello Kim,
we have the very similar issue. We have the dev kit, but we have only production modules left.
Can we do the same trick using eMMC memory? To load once through eMMC memory and then move back to NVM?
Thank you in advance!
I expect you could. The principle is simply a root pivot during the boot. The OS that you then boot from needs to be prepared on the nvme disk. My script does the preparation, i.e. the creation of the target partitions and the copying over of the installed OS etc.
However I have no experience with production modules, don’t have any and don’t know how they appear during the boot process so I’m only guessing. And I don’t know what my scripts would do.
If they production modules appear identically to the SD card in a dev kit then it might work just the same. However, the fact that it is a dev kit means that the dev kit’s SD card device must also appear. Perhaps the production device appears as /dev/mmcblk1p1 etc ? Or vice versa. If so, then it might be a minor tweak to make it work on a production module.
Personally, my gut feeling would be that all that you can do to avoid reflashing during development has the potential to reduce risk of something going wrong that takes a lot of time or precious resource (Dev kits and modules are a precious resources these days :-) ) loss.
It’s interesting though.
Cheers,
Kim
Thank you for the clarification!
Only to ensure, when you talk about partition on NVM, the partition size is as the size of the drive?
You don’t create the partition of the size of the origin image (let’s say 16gb)?
I just had a look at the code, it creates a partition the size of the disk. Actually, it’s created with constraints, the max size is constrained to 10TB which in practice means the whole disk currently.
Is that what you want ?
If not, you can change the value of VERY_BIG_SIZE in make_partitions.py.
Kim
The other project I have sbts-base sets the OS partition to 50GB and creates 2x other partitions. One to about 5GB intended for re-mountable configuration and the the other one the size of the disk intended for read-write. The value of 50GB is set with the variable OS_PARTITION_SIZE.
That’s the structure I setup for use with my yolo triggered security project StalkedByTheState. It’s designed for operational resilience against power cuts whereby the OS is running mounted read-only with a memory overlay file system.
Kim
Thank you very much!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.