We are looking to add to our current fleet of devices a set of Nvidia Jetson Nano boards. Our issue resides that a lot of commercially (not dev kit) boards are made to be used without an SD Card.
I’m looking to start testing these devices, but the only image available is to be used with an SD Card… Is there any alternatives? I see that some other images, like for TX2 seem to not be made to use with an SD Card, so any chance that balenaOS image will work on the Jetson Nano?
The Jeston Nano is a balena-supported device, and balena images can be burned to SD cards or internal MMC. For example, the balenaFin has onboard storage and flashing it merely requires the device to be tethered via USB to the flashing workstation (instead of inserting a removable SD card and flashing to that). By contrast, the balena NUC image does two-stage flashing. That is, you flash the balenaOS image to a USB, boot the device, and it then flashes the image to internal storage.
I hope this helps. Let us know if we can be of any assistance.
Thanks for the response… right now we are accustomed to flash NUC devices, so we are not familiar with the flashing process via tethering… Is there any way you could help us on that by showing us the steps that could be required or by redirecting us to a knowledge base or video that shows how to do it?
We’ve created a quick tool to flash Jetson-based products. Just keep in mind that you’d need to make sure that not every carrier board is supported by balenaOS. If you let us know what type of boards you’re looking at, it might help us give a more accurate answer.
We are planning to use an Nvidia Jetson Nano with eMMC storage, which is a supported board and should work for us… At least I assume it will. Thanks for showing the tool, looks great! If I have any issues I will let you know for sure!
I got the instructions how to set my Jetson Nano device into Force Recovery Mode and I started the flashing process using the quick tool that you proposed… And I encountered an issue related to the MBR signature
Hi @eeb – thanks for reporting this to us. I’ll ping our devices team to take a look at this, but in the meantime can I ask you to please file an issue in that repo with the details you’ve given above?
Hi @saintaardvark - I’ll do it, I’m trying to do a bit more of research so I can pin-point better what’s happening and a possible solution or a path to a solution.
Hi there – I’ve checked with our devices team about this, and they’ve let me know a couple things:
First off, the jetson-flash repo is meant to be used on Ubuntu, as it uses the NVidia host tools. (I’m not sure that’s clear from the repo instructions, so we’ll be improving that part of the documentation.)
We’re in the process of releasing a jetson-nano image for the emmc variant, so we do not recommend flashing the Jetson Nano SD-card image from the dashboard to an eMMC SOM for production purposes. We hope to release that image soon.
I hope that helps, but please let us know if you have any additional questions.
Hi @saintaardvark I’ve been also trying from a machine running Ubuntu 18.04.4 LTS now, and I’m getting the same error message about the MBR boot signature. If possible could you please tell me in which boards you guys test? This would be important for me so I can verify the flashing process on my own and check if is something that can be improved on your side or maybe an issue or something specific to the manufacturer that interfaced the Jetson Nano with the board.
Also maybe is worth to mention that my Jetson Nano board is not bare-metal, it run now has the Nvidia-provided Ubuntu OS if I do not power it in Force-Recovery mode, I make emphasis on the Force-Recovery part because maybe it’s a different mode than Recovery.
My Jetson Nano board model is P3448 180-13448-DAAA-B01 so that’s maybe useful as well because there different versions of it, like A02 I think.
Hi @eeb – thanks for the additional details. Can I ask you to include them in an issue in that repo? In the meantime, I’ll check with our team about which board we used for testing.
Yes I’ll get to it right now… Just a last check for me, is there something else except the actual project requirements installed with npm install that are required in order to make the script work properly? And if there is, could you provide instructions on how to install them, or at least the documentation? I wanna make sure that is not something in my board or my development Ubuntu computer before actually filling an issue that could be on my side.
P3448 180-13448-DAAA-B01 is the SOM code. Is the carrier board that you are using with this SOM the B01 devkit - 180-13449-DAAF-B01’? Or are you using some other carrier board, produced by another vendor? For carrier boards that are not produced by Nvidia, another dtb might be necessary.
Otherwise if you are using the Nvidia carrier board, it should be fine. But please don’t use the SD-CARD image on an eMMC SOM for production purposes, as we’ll try to release the eMMC image for the Nano very soon, hopefully next week or the other.
Also, since you are trying to flash v2.51.1+rev1 which is based on L4T 32.4.2, please use this PR . It will get merged as soon as the eMMC image becomes available.
Finally, please unzip the image downloaded from the dashboard, the MBR error appears because a zip file is provided to the tool, while it expects to find a disk image.
We are not using the dev board… in this case we are using another carrier board, one made by Advantech, to be more precise, the product is MIC-710IVA. About the SD-CARD image, thanks for the advice, we are in development stage right now and we got the point where are code is potentially ready and we are dealing with the HW part, so still a few weeks until we plan on releasing something to production, this is more now a POC phase were I can execute the install process and then I can try to simplify for our operations team.
I’ll follow your suggestions and get back with the results, thanks for the detailed explanation! I really appreciate it. Also I’ve been going over your code for flashing, and got to the point where I start to ask myself stuff like this
Thanks for clarifying, since you are using a different carrier board, a custom device type will very likely be necessary in production. At least because the device tree provided by Advantech should be used.
The answer to your question regarding mmcblk0p12 is that BalenaOS partitions are placed after the NVidia mandatory partitions, after the ones that contain signed bootloaders and firmwares. With the flash.sh script, there is only one APP partition for the rootfs and it is the first one on the emmc, hence the mmcblk0p1 argument to flash.sh.
Until now we haven’t seen no Jetson board ever getting bricked, the flashing mechanisms used by NVidia are pretty robust, they never failed. I’m pretty confident you can experiment freely, as long as you put the board in recovery mode you should be able to always re-flash it.
Thanks for the details! Is there anyway that I can provide you and your team with the necessary information to make this customization in case is necessary? I’m not an expert in embedded Linux, but I could provide device tree information from the board by using
dtc -I fs /sys/firmware/devicetree/base
And other stuff that you may need.
Really appreciate your explanation, I’ll let you know the results of the stuff I try.
I managed to flash it, it worked as soon as I used the .img file instead of the .img.zip file downloaded from the dashboard. I’ll create an issue to update the documentation and include the step of unzipping the images downloaded from the dashboard.
The dashboard instructions for the SD-CARD image already specify extracting the image before writing it to an SD-CARD, and the upcoming Jetson Nano eMMC image is also prepared with this dashboard information.
Thanks! I wasn’t aware of it. Do you have a timeline to include this into Etcher? I’m just asking to know if we need internally to do a desktop app for this…
