SDK Manager on Arm-64

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:

  • Require increased power consumption.
  • Require increased physical size.
  • Increase cost.
  • Make it possible to be bricked, although a dual BIOS could help, but then it gets even bigger and more costly.

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 @HybridRobotics 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:

  • power up and power down like the EFM8 on the Devkits
  • enables remote power on/off, reset, turn on/off recovery mode thrugh UDP packets
  • acts as an Telnet Gateway for the serial console (Debug UART)

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

Hi,

The tegrarcm package is available for Ubuntu 22.04 now. Now, I need to find out how to use this package. It is supposed to be available from at least 18.04 onwards.

8-Dale

This package is only for the Legacy Tegra20, Tegra30, and Tegra114 platforms, not for the current ones.

OK. Is there any technical reason this package can not be expanded to include current and past NVIDIA platforms such as the Jetson TX2, AGX Xavier, Orin, etc?? What would it take to accomplish this?

8-Dale

Look at the source. There are blobs (hexdumps) specific for each device. Either reverse engineer this (much work) or have NVidia open-source it. The limitation to non-locked non-secure-boot devices would be ok for me.

tldr: No, there are no technical reasons. But you are stuck for the moment.

I would love to see NVIDIA make this Open Source! Yes, at the moment, I am very stuck and not able to use my AGX Xavier. This may be the same for the Jetson TX2 NX module I have, which I am waiting for carrier boards to arrive.

Will somebody from NVIDIA please comment on this??

8-Dale

I completely agree, but at the same time, I think NVIDIA has good reasons for not doing so. Unfortunately, there are possible security concerns (especially since some of this is shared across non-Jetson platforms on vehicles). I would tend to side with the open source, or at least open API interface for the Jetson case. In the case of information which applies only during recovery mode flash it seems reasonable to make the information available, but since I don’t have that information it is also difficult to say that this is harmless.

The sharing of code between the Jetson and vehicle platforms could be an issue, but I see no reason why this could not be worked around. Shared code is great, but this is one case where code should not be shared between platforms.

I certainly would not want to see anything introduced that would or could cause a security problem. In the case of the Jetson platform, we are talking about a direct cabled USB host to a USB device connection where there should not be any security concerns.

8-Dale

Security that is based on obscurity is no security. NVidia should know this.

Everybody should know this.