Hi, I love Balena and when I saw this post I immediately wanted to add my Jetson Nano Developer Kit to a fleet so I downloaded the developer version of NVIDIA Jetson Nano SD_CARD (NEW) and used Etcher to burn it.
Problem is, it boots to the vendor splash screen but doesn’t register in the fleet on my dashboard. Have done this many times with rPi3/4 with no issues.
Am using ethernet only plugged directly into my router.
The NVIDIA Ubuntu image I used prior booted fine with no issues.
Hi there thanks for contacting us! What version of the OS are you using? How long are you waiting for the device to appear in the dashboard before deciding that it hasn’t worked?
When booting, is it the Nvidea spalsh screen that you see or the balena one? Any boot logs displayed?
Another item to check, do you have the 2gb RAM Nano or the 4gb RAM Nano? There are different balenaOS images for each, so let’s make sure you have the right one downloaded, thanks!
Nvidia Jetson Nano 2GB Devkit SD
BalenaOS 2.82.11+rev2
aarch64
→ This should be the image for the Jeston Nano Dev Kit with 2 GB RAM
Nvidia Jetson Nano SD-CARD
BalenaOS 2.82.11+rev11
aarch64
→ This should be the image for the “old” / full speced Jeston Nano Dev Kit with 4 GB RAM
Nvidia Jetson Nano eMMC
BalenaOS 2.82.11+rev2
aarch64
→ This should be the image for Jeston Nano module, which can be bought without dev kit and is expected to be slotted into some other board manufactured by a third party for “real” use in the field, hence the eMMC (and it should also have 4 GB RAM, I guess)
Another item to check on this one, @philT , is to flash your Jetson Nano back to JetPack 32.4.4 using the Nvidia SDK Manager. You can follow these instructions: NVIDIA SDK Manager Documentation
Once you have it flashed back (the underlying issue is that JetPack 4.6 overwrites the QSPI flash on the Nano), then you can once again try booting up your balenaOS SD Card, and it should work. Hope that helps! (And, we’re actively investigating how to support JetPack 4.6, to avoid this workaround in the future.)
Thanks but unfortunately the SDK Mangler only runs on Intel and I have a Mac M1. This also rules out Docker and Virtual Box even if I used the ARM version of Ubuntu. I may be able to find another VM or possibly build the image from scratch but it seems like a lot of work just to run BalenaOS. I’m probably better off just running the native NVIDIA tooling.
Sorry to hear this @philT. The other method to downgrade is by using their tooling directly, which in your case might be more compatible with your local setup:
wget https://developer.nvidia.com/embedded/L4T/r32_Release_v5.0/T210/Tegra210_Linux_R32.5.0_aarch64.tbz2 && tar xf Tegra210_Linux_R32.5.0_aarch64.tbz2 && cd Linux_for_Tegra/ && sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
In any case, yes, the recent upgrade to JetPack 4.6 has left boards unable to immediately boot balenaOS…and we are discussing a path forward to get it resolved. Thanks!
Thanks @dtischler - I went through your explanation - sadly the paket with the tooling is not enough, the system just wants to flash the overall filesystem before it even dares to write some kB to the eeprom. In regards to the ARM leaflet I went ahead and did some small tutorial for with the 32.4.4 version, this is for the current Jetson Nano (4GB RAM, SD) and Jetson Nano (2GB RAM, SD) models, but I cannot test it on a ARM Mac, I would assume it needs at least some x86/x64 emulation, but never the less, all gals and guys with access to internet and an (even old) x86/x64 machine with current Ubuntu/Debian, this should help.
(This was tested on a headless Debian 10 machine and a 32 GB MicroSD Card was used - no warranty taken for any of this, it was just tested with a Jetson 4 GB and it is now working perfectly - but I cannot take any liability in any way )
0.) Power down your Jetson Nano
1.) Use a female/female jumper cable to cross the FC REC with one GND pin on the backside of the unit (close to the SD Card)
2.) Insert an empty, at least 16 GB big sd card
3.) On your recent (Ubuntu/Debian) Linux PC (could be that it needs to be x86/x64) prepare the overall system
sudo apt update
sudo apt install -y qemu-user-static
wget https://developer.nvidia.com/embedded/L4T/r32_Release_v4.4/r32_Release_v4.4-GMC3/T210/Tegra210_Linux_R32.4.4_aarch64.tbz2
wget https://developer.nvidia.com/embedded/L4T/r32_Release_v4.4/r32_Release_v4.4-GMC3/T210/Tegra_Linux_Sample-Root-Filesystem_R32.4.4_aarch64.tbz2
tar xf Tegra210_Linux_R32.4.4_aarch64.tbz2
cd Linux_for_Tegra/rootfs/
sudo tar xpf ../../Tegra_Linux_Sample-Root-Filesystem_R32.4.4_aarch64.tbz2
cd ..
sudo ./apply_binaries.sh
4.) Power on the unit
5.) Connect it via Micro USB cable to the PC
6.) Flash the overall package
sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
It took some time to get all data via USB 2.0 to the Jetson, but after the processed was finished in the flash tool, it rebooted the Jetson and started preparing Ubuntu. I let it run for some minutes before powering it down, removing the SD Card and the Jumper for the FC REC. I then put in a preconfigured balenaOS image sd card and saw it boot over the NVIDIA logo and successfully connect to balenaCloud.
Hope this helps future people until we get the issue resolved
Thanks @nmaas87 - great tutorial here! I noticed when flashing my Nano 4gb RAM unit back, that I had to use the barrel jack to power the Nano. It wouldn’t flash (just sat waiting indefinitely) while I had ONLY the micro-usb cable attached. Seems like it was unable to both power the board, and write data, over the cable. (I do know that some cheap micro-usb cables are power-only, and no data lines are even present…but this cable in particular does have them. In fact, once powered over barrel jack, the same cable did push the data and the flashing worked, so, bits were flowing ha.)
Good words, yes it needs to be powered by the barrel jack.
Sorry I always forget that, because I only run the 4 GB in “MAX performance” via barrel jack (I don’t like not using all the hardware I paid for ) - so this is an awesome remark
) - so this is an awesome remark