Hello,
I need to flash my Jetson TX2 NX and AGX Xavier but there is no build of SDK Manager for Arm-64. Will there ever be a build of SDK Manager for Arm-64? I do not have access to an x86 Linux PC and prefer doing all my development on Arm-64 systems.
8-Dale
SDKM is a flash front end tool (it is the network utility on top of JetPack). These run only on an x86 host PC, they don’t run on the Jetson itself.
Jetsons don’t have a BIOS, and much of the work a BIOS would perform is in partitions (either in eMMC or QSPI memory). Thus, they cannot self-flash. The host PC running the flash software understands a Jetson in recovery mode. You’d install JetPack/SDKM on the host PC, connect it to a recovery mode Jetson via the proper USB cable, and run flash from the host PC.
A host PC running Ubuntu 20.04 or 18.04 will work with older JetPack 4.x or JetPack 5.x. This also happens to match an exact release of L4T (and L4T is Ubuntu plus NVIDIA drivers; this is what gets flashed to the Jetson). See:
Hi,
Are you saying that SDK Manager can not possibly ever run on an Arm-64 system?
I do not have access to an x86 PC at all.
I am not talking about running it on a Jetson.
I am talking about running it on a different Arm-64 system.
8-Dale
For clarity, @hybotics.wy1 wants to use an Arm-based desktop machine (such as a RaspberryPi running Ubuntu) to flash his Jetson.
This requires running the the SDKM on the Arm-based desktop, but only x86 packages appear to be available.
Is there an aarch64 build of the SDKM or an alternative method of flashing the Jetson does doesn’t require the SDKM (and will work from an Arm-based host)?
Great thought!
If there is a procedure I can use from an Arm-64 system and still be able to flash my AGX Xavier and soon my Jetson TX2 NX, that would be awesome!
8-Dale
What @Linuxdev said… Use a linux PC for flashing.
I don’t say it would be impossible, I don’t want to cast a cloud, but I think that you’ll have an Ubuntu PC doing that before succeeding from an RPi.
Also note that you would need several tens of GBs for creating the image to be flashed.
And many USB issues from emulation…
Though, I’d be happy if you show that I’m wrong and share for everyone.
Hello,
I do not have an x86 PC.
I have an Arm-64 system with 8 cores and 16GB RAM that runs from a 1TB hard drive.
8-Dale
Hi again.
I also have a Raspberry Pi 400 that runs from a 512GB flash drive.
8-Dale
Part of the flash software is x86 binary Linux. It cannot run on arm64. That part is the “driver package”. During flash the Jetson must be in recovery mode, which turns it into a custom USB device (it is not a generic mass storage device). This device is only understood by the driver package. Thus, there is no possibility of using official flash software. You could play games with dd for parts of this if you knew a lot about it, but still likely fail on some important parts of flash (for example, some of the flashed content is more or less “black box”, and so it is unlikely you’d ever have enough information for complete flash from arm64).
I’m a (relatively new) developer evangelist for Arm, I’d really like to get a better understanding of what parts of the SDK manager can’t be run on aarch64 right now, and what we can do to change that.
Are there any of the SDK Manager developers in this forum?
On the host PC:
Linux_for_Tegra/bootloader$ file tegrarcm_v2
tegrarcm_v2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.8, BuildID[sha1]=34af5ec73d62e56d5303eb59a2aeb768bf8e4845, with debug_info, not stripped
That file (the guts of recovery mode Jetson access) is closed source.
I understand that now.
Hi again,
Is NVIDIA planning to create its own flasher software for its hardware?
It seems like this is the logical thing to do. If it were me, I would not want to depend on somebody else’s binary blob of code for something as important as this. It would allow NVIDIA to support more host platforms such as aarch64, Mac, and others.
8-Dale
I’m not sure what the question is. tegrarcm is NVIDIA’s. All of the flash software is already provided by NVIDIA for its hardware. When a third party creates a carrier board and provides software, it is just a patched version of the NVIDIA software (mainly device tree edits).
Flashing a system without a BIOS implies it cannot self-flash. Adding a BIOS would:
The flash software itself is doing far more than flashing. It is in fact creating an entire operating system rather than just using a pre-canned image. One of the reasons for using an Ubuntu host for flashing the Ubuntu Jetson is that it already has the ability to do things like manipulate loopback filesystems (ext4) and partitioning tools (versus building those from scratch and reinventing the wheel).
I don’t know if it is true, but I’ve heard there was talk about building an arm64 version of the flash software (which is not what JetPack/SDKM is…that’s only a front end to flash). I’ve never heard if that would actually “be a thing” or if it was just something considered.
It looks like there is already an arm64 build of tegrarcm in the Ubuntu archives: Ubuntu – Package Search Results -- tegrarcm
Would it be possible for @hybotics.wy1 to use that directly, skipping the SDKM frontend, to flash is Jetson device?
There is no desire to add a BIOS to Jetson devices, and as far as I understand there is no need to have a BIOS on the host device, the host only needs to be able to communicate with the Jetson. As more host PCs become Arm64 based, whether they be Mac, Windows or Ubuntu, having a way for those hosts to run the SDKM software is desirable.
Definitely! I am not asking for a BIOS to be added to NVIDIA’s Jetson boards. That would be a silly request. ;)
All I am looking for is a way to flash my TX2 NX and AGX Xavier without needing an x86 PC to do it.
I am very happy doing all my development on Arm-64 systems and would love to be able to do all of my
development on Arm-64 systems.
8-Dale
I agree it would be useful, but I have not yet heard of an arm64 build for flashing tools which works with a Jetson. Maybe NVIDIA will comment on plans for an arm64 flash tool, and whether the URL in post 15 is ready.
Incidentally, I’m not suggesting adding a BIOS to a Jetson. I am suggesting that because a BIOS is not present on a Jetson that the flash software is more complicated and involved than what people are used to with a PC. For quite some time we have been able to skip the GUI front end and use the “flash.sh” utility on command line (which is in turn a front end to the tegrarcm).
I’d like to have the Tegra RCM protocol open-sourced and documented. This would solve problems like this where flashing needs an amd64 PC for no technical reason.
There are other use cases as well. My own carrier boards have an extra microcontroller that has it’s own Ethernet and IP address and does:
My carrier boards are part of larger machines and not easily accessible, and these machines are scattered all over Europe… It would have been nice to reroute the Jetson’s USB0 to the microcontroller in order to perform remote flashing over ethernet. When using an LTE gateway this could make service much easier, and it would have been possible from an hardware standpoint. But without documentation and software this has been a non-starter.
Hi,
I would also like to see that done! It would solve a lot of problems, like what you and I are experiencing. As you said, there is no technical reason this has to be done the way it is being done. In fact, I have been able to get 98% of the way to where my devices are flashed but there is that very last step that I can not do because of that x86 software blob.
I would like to hear from NVIDIA as to why this can not be changed so an x86 PC is not needed.
8-Dale