I accidentally formatted /dev/mtdblock0 when trying to format an external USB drive. I thought perhaps that was a view onto the SD Card and that I had ruined it, so I flashed a new one with the latest Nano image. But it still doesn’t boot. I’m going to try connecting a serial console to see if anything is output, but nothing shows up on HDMI.
Is this recoverable?
Yes, it is recoverable but you need to find another x86 host, install sdkmanager and use sdkmanager to flash your jetson with usb connection. That is the true method to recover any jetson device.
Sdcard image is just for experiencing the jetson.
I have Windows for ARM in Parallels on my M1 Mac. Do you know if that runs in windows for ARM? Usually apps run, but proprietary USB drivers often don’t.
Sdkm can run on docker too. But I personally prefer using native x86 ubuntu.
Oh I misread. It doesn’t need windows, it needs Ubuntu. But it has to be x86? Can’t be ARM?
Yes, some binaries are built for x86. So cannot run on ARM.
Bah. That’s going to be difficult. Thanks.
If you are going to develop for a Nano, then I’ll suggest a dual boot with Ubuntu 18.04. Just make sure you have plenty of disk space (at least 50GB after install and update).
Update: I found the command line instructions.
Is there any way to fix this from the command line? I built a PC to run Ubuntu 22.04, but because all PCs and linux suck ass, I can’t get graphics to work at anything but 800x600, and the sdkmanager UI is so poorly designed it can’t work at that low resolution. I’m unable to grow or shrink the window enough to let me get at all the UI elements to do anything.
Update: I realize I have to put it into recovery mode. Please standby while I try that.
Update2: Yeah, I can’t seem to get it into recovery mode. Assuming the pins go from top down like in the diagram (which I question because there’s a white triangle at the bottom that usually indicates pin 1)
And following the steps here, or in the manual, I can’t get it to show up under lsusb. However, my Mac is able to see it when I plug it into that. I’ve tried different USB cables and different ports on the Linux PC.
Okay I was able to log into SDK Manager and operate it via X Windows on my other machine. But now it can’t detect the attached Jetson Nano board that I’m trying to fix. It’s connected via USB and powered up, but because I borked it somehow, all I get is a green LED on it, no Ethernet, etc.
How do I use SDK Manager to fix it? The docs I found say virtually nothing about how to use it.
Okay, more progress. Turns out TWO USB cables I had were bad.
Now SDK Manager recognizes a board is attached, but provides me with three options:
I can’t quite tell what I have for the Nano:
And the carrier (P3450) isn’t one of the options:
In any case, I tried selecting the first option, but SDK Manager still won’t let me proceed to the next step:
The host machine is 22.04, but I’m not trying to install anything on the host. I just want to repair the Nano.
Since my host running 22.04 seems to be part of the problem, I decided to install the Docker image available for 22.04. But it’s not clear to me if that’s working properly:
$ docker run -it --rm sdkmanager --cli install --logintype devzone --product Jetson --version 4.6.3 --targetos Linux --host --target JETSON_AGX_XAVIER_TARGETS --flash all --additionalsdk 'DeepStream 6.0.1'
No update is available.
To initiate login process open https://static-login.nvidia.com/service/default/pin?user_code=38705174 in a browser or scan the QR code on your handheld device then login with your NVIDIA Developer account. SDK Manager will start once done.
Login user code: 38705174. (valid for: 10 minutes).
? SDK Manager is waiting for you to complete login.
1) Generate a new login user code
2) Display the QR Code
3) Cancel login
Answer:
Waiting for user information from NVIDIA authentication server...
Retrieving user information...
Loading and processing available products...
Login succeeded.
Loading user information...
User information loaded successfully.
Loading server data...
Server data loaded successfully.
* Available on ubuntu16.04, ubuntu18.04. For available versions run sdkmanager --query.
I’m running out of ideas.
Hi rmann,
Please download Docker image for Ubuntu-22.04 from: SDK Manager | NVIDIA Developer
Try below command:
$ docker run -it --privileged -v /dev/bus/usb:/dev/bus/usb/ -v /dev:/dev -v /media/$USER:/media/nvidia:slave --name jetson-nano --network host sdkmanager --cli install --logintype devzone --product Jetson --target JETSON_NANO_TARGETS --targetos Linux --version 4.6.3 --flash all --license accept --staylogin true --datacollection enable
Please make sure your target device is JETSON_NANO_TARGETS or JETSON_AGX_XAVIER_TARGETS.
Thanks, @carolyuu.I don’t think that did anything…
$ docker run -it --privileged -v /dev/bus/usb:/dev/bus/usb/ -v /dev:/dev -v /media/$USER:/media/nvidia:slave --name jetson-nano --network host sdkmanager --cli install --logintype devzone --product Jetson --target JETSON_NANO_TARGETS --targetos Linux --version 4.6.3 --flash all --license accept --staylogin true --datacollection enable
No update is available.
To initiate login process open https://static-login.nvidia.com/service/default/pin?user_code=85072024 in a browser or scan the QR code on your handheld device then login with your NVIDIA Developer account. SDK Manager will start once done.
Login user code: 85072024. (valid for: 10 minutes).
? SDK Manager is waiting for you to complete login.
1) Generate a new login user code
2) Display the QR Code
3) Cancel login
Answer:
Waiting for user information from NVIDIA authentication server...
Retrieving user information...
Loading and processing available products...
Login succeeded.
Loading user information...
User information loaded successfully.
Loading server data...
Server data loaded successfully.
* Available on ubuntu16.04, ubuntu18.04. For available versions run sdkmanager --query.
Also, that command doesn’t have --rm, so the container stays loaded, and attempting to run it again fails with “The container name “/jetson-nano” is already in use…”. Is that intentional? It doesn’t seem to remember my login if I remove the container, either. Does it not store that in the /media/$USER volume?
Hi,
I think there are some misunderstanding. As the jetson nano could be only flashed by ubuntu 16.04 or 18.04 host, you need to use the “docker image for ubutnu 18.04” on your host.
That is why this got printed:
- Available on ubuntu16.04, ubuntu18.04. For available versions run sdkmanager --query.
Some random facts you might find useful:
Linux_for_Tegra/rootfs/” directory, and unpack the “sample rootfs” with sudo (you must do this as root).cd back to “Linux_for_Tegra/”, and run the command “sudo ./apply_binaries.sh”. You only need to do this once.sudo ./flash.sh jetson-nano-devkit mmcblk1p1
mmcblk1p1 (on an SD card), whereas an eMMC model refers to this as mmcblk0p1 (on eMMC memory). Dev kits have QSPI memory on the module for boot content (there is no BIOS, so this is the equivalent), and rootfs is on the SD card, so you have to flash the Jetson to get correct QSPI content; the rootfs has its own instructions which you can look at from the L4T URL listed above.sudo ./tools/l4t_create_default_user.sh” script to add that account before flashing (this updates the “rootfs/” content).apt-get in older packages, but optional packages can be added with apt-get commands in some releases. I don’t know if your release has that available or not, but you could search something like this once you’ve booted up (from the Nano):apt search jetpack
The “ Supported Host Operating System” chart on this page has some very vague wording, “ While SDK Manager supports all the below host operating systems, you need to verify the SDK package supports the host OS.” It then lists which SDKs support which OSes.
Why on Earth does the host matter for the SDK in the first place?
In any case, it wasn’t at all clear what was meant by the docker versioning, but I guess that makes sense. I’ll try the 18.04 one.
FYI, the target being flashed is the reason for part of the dependencies. The rootfs filesystem for Ubuntu 18.04 is being generated by the host PC. So long as the host PC has all of the requirements, e.g., ext4 having the correct defaults, then in theory command line flash does not have many requirements. An Ubuntu 18.04 host PC is guaranteed to have the correct versions for creating an Ubuntu 18.04 rootfs. The GUI on top of this has other requirements. The GUI might be able to handle Ubuntu 22.04, but it is the intersection of the requirements for the product with the requirements for the GUI which creates the limitation (the GUI can work with Ubuntu 22.04, but the Nano cannot).
I had 18.04 on the SD card until I screwed up the Nano by accidentally overwriting /dev/mtdblock0. I don’t know what device that is on my Nano. I don’t even know if my module has eMMC or QSPI. But re-imaging the SD card was not enough to make the Nano boot again.
I will try the 18.04 Docker image, and if that fails, I guess I can try the commands you mention, but I don’t think those will work because my host is 22.04. It boggles my mind that the host has to also be stuck on a stupid old OS.
Nano can’t use an Ubuntu 22.04 host. It might work with command line, but definitely not with the GUI. Your Nano must be a dev kit because your picture shows an SD card slot on the module itself. eMMC models don’t do this.