Flashing Jetson TX2 via USB


Looking at a custom carrier board for the Jetson TX2 and won’t have a SDCard slot, what is the recommended way to flash the resin image via USB please?


@telphan did you ever flashed the Jetson with a resin.io image via usb in recovery mode?

@brice I am sorry, but we cannot flash over recovery mode as we would need to provide users with tools that Nvidia has under copyright.

Thanks @telphan, I understand you can’t provide the tools, was just wondering if there was a way for me to do it using the flash.sh script provided with Jetpack? Alternatively, is there a way to boot from a USB drive instead and flash this way?

The way we recommend commissioning the TX2 is to create an Installer SD card, that you then boot the TX2 from. https://docs.resin.io/jetson-tx2/nodejs/getting-started/#provision-your-device

Let us know if that doesn’t suit your use case, and we’ll see if we can dig further.

Oh, drat, just noticed the bit in your original post where you mentioned the lack of an SD slot! Give me a moment to dig further.

@sqweelygig any update on this one please?

hey @brice , you could potentially you could use flash.sh script to flash resinOS, but we do not have a process in place for that. Essentially you need to modify the flash.xml to include our partitions and then use the normal JetPack process to flash.

Thanks, will give it a try.

Did Shaun’s advice above fix the issue, I’m going to assume yes, but it would still be nice to know.

@sqweelygig I haven’t had a chance to resume testing this method, will keep you updated.

@brice If you are still interested, I wrote a little tool to flash resinOS image on the TX2 via the USB.

You can check the tool out here:

Let me know if you have any feedback on this.

1 Like

Awesome, thanks @telphan

@telphan I would like to flash my new Jetson Nano Production module with this tool, as it has no SD card integrated. I assume it needs some adaption, f. ex. I changed the download link in cmd.js in order to match the Nano production drivers.

But the first error message I get seems to be more related to a recent change in the balenaOS image filesystem:

Retrieve resin-image from balena.img
(node:9093) UnhandledPromiseRejectionWarning: Error: Unsupported filesystem.
    at /home/osboxes/Desktop/jetson-flash-master/node_modules/resin-image-fs/build/driver.js:95:13
    at tryCatcher (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/promise.js:517:31)
    at Promise._settlePromise (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/promise.js:574:18)
    at Promise._settlePromise0 (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/promise.js:619:10)
    at Promise._settlePromises (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/promise.js:695:18)
    at _drainQueueStep (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/async.js:138:12)
    at _drainQueue (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/async.js:131:9)
    at Async._drainQueues (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/async.js:147:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/home/osboxes/Desktop/jetson-flash-master/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:705:18)
    at tryOnImmediate (timers.js:676:5)
    at processImmediate (timers.js:658:5)
(node:9093) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:9093) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I used a Jetson Nano Production image with version 2.43.0rev1. Could you help me out on this?


The error you are seeing (as unfriendly as it is) is expected.
To explain it I need to make you aware of some context, our OS team creates two types that I will call flasher and non-flasher(the actual balenaOS). The two images are to be used very differently, the former is for devices that have internal mmc so we to flash balenaOS to the internal mmc, it is essentially a wrapper around the real balenOS image. While the latter is for device that have external mmc such is the for nano (e.g. SD card), in this case we flash the balenaOS onto the external mmc without a need for the flasher wrapping.
Coming back to the my tool now, when using a flasher type I have to unwrap the internal balenaOS, action that is no required for the Nano as the image is already “unwrapped”.
Back to the problem; the full explanation is a fairly big and I don’t what to bore with all the details, but essentially the tool now is confused and tries to wrap balenaOS from a balenaOS image (inception) and looks at a partition number that has no filesystem (it is a binary partition) and there is your error.
Kind regards,

@telphan Thanks for the clarification! Where can I get the right kind of image from then? Do I need to build a custom image?

Assumed I have the right kind of image - do you think it is sufficient to change the link to the Jetson firmware and the device type in ResinJetsonFlash, or are there other obstacles I could face when flashing to the Nano?

To give a bit more context, at the moment all our device types have a single image type:

  • either a flasher, if there’s internal storage (devices is booted from external media by default, and that system flashes the final image)
  • or a non-flasher: if there’s no internal storage, to flash on the SD card for example to run from.

In this case, we added support for the Jetson Nano when it was the first release, with an SD card slot and no internal storage, so ended up with a non-flasher image. In this case, there are two ways forward:

  • I’ll check with our device support team, how we would go about creating a flasher image (that would be appropriate for such an internal storage device like this production Nano
  • as I’ve checked, it seems feasable to modify the the USB flasher script mentioned earlier, to work with a non-flasher image (in essence it will need to do less than it does now, and hence the issue.

Either way the ball is in our court: there’s no image that you could use with this script yet; and the script also needs modifications. Will discuss with the team and will get back to you.

@imrehg Thanks for the additional information, this was very helpful for us.

We want to deploy a large number of Jetson Production Devices anytime soon (in the range of days rather than weeks) and therefore need a quick solution for this. I appreciate your efforts to discuss this with the team, please let me know when you have an update on this topic.

1 Like

Will do! IMHO the script update now and more robust solution later would be the best way forward given the timeline you mentioned but will confirm.

Thank you very much! Yes I think so too, that would be the best way to go.