What components do I need on a carrier board to make the Jetson AGX Orin programmable?

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

I am designing a custom carrier board to host an AGX Orin module. I am following the Jetson AGX Orin Series Design Guide, and I have the P3737 schematics for the JAO development carrier kit for reference. I don’t need everything from the Nvidia carrier kit on my custom board.

My question concerns programming the final product. What do I need to have on my board to make the Orin module programmable?

I thought I could do it via JTAG, but the design guide and data sheet list JTAG as optional (for debugging and boundary scan testing). I’ve noticed the USB recovery mode feature. Is that used for flashing/programming the device? I didn’t intend to have USB on my board, but if it’s necessary, then I have no choice.

I won’t necessarily be programming the Orin system myself, but it must be programmable, obviously.

Here are some more specific questions:

  1. What firmware comes pre-installed on the Orin module?
  2. Does it come pre-installed with an OS?
  3. How do I install an OS on it?
  4. Does it require an OS?
  5. How do I load programs on the module in general?
  6. Are there multiple options for loading programs?

Again, this is not about using Nvidia’s available Developer Kit. This is about using the Orin SoM after I design a custom carrier card for it. I want to know what I need on the card to communicate with the device.

2

Hi,

I notice you keep talking about this is not related to NVIDIA devkit. I totally understand that. There are already plenty of users making their own carrier board.

However, the questions you are asking here are very basic items that I would even suggest you could get a NV devkit to play with first.

Also, it is a good practice to have a NV devkit there when making your own carrier board. For example, if you hit any error on custom board, then you could try to see if NV devkit could reproduce that too. If it can, then you could reprot issue to us.

As for your question,

  1. What firmware comes pre-installed on the Orin module?
  2. Does it come pre-installed with an OS?

Don’t rely on any “pre-installed” thing from Orin module. We don’t guarantee that thing would work fine.

  1. How do I install an OS on it?
  2. Does it require an OS?

For NV devkit case, it would need to enter recovery mode so that x86 host PC can flash the board through sdkmanager tool or manual flash tools on the USB0 port.
Yes, it requires OS and we provide a BSP package for it called Linux_for_Tegra.

  1. How do I load programs on the module in general?
  2. Are there multiple options for loading programs?

I am not sure what “program” you are talking about. It seems a unclear term here.
For example, a basic hello world program is also a program. The whole BSP that uses to boot up the board may be also a “program” to you. You may need to clarify what you want to know here.

Question 2,3,4,5,6 seems could be nothing as you would be more clear about the situation if you ever run the devkit once.

3

Thanks for getting back to me so soon.

Yes, I have an NV devkit for testing purposes. However, I ultimately need to create my own carrier card to meet specific design constraints. I also don’t necessarily require everything on the devkit. I only want to take the parts I need and leave out the rest. I’m trying to determine what parts I need to get programs to run on the module.

What I meant is if the Orin comes installed with an OS.

I assume it comes with a bootloader, at least.

Okay, so I would have to load it myself via USB if I copied what the devkit does. So, I need USB on my custom carrier board. Are there other options?

Yes, any program. Even a “Hello World” program. That would absolutely include a BSP. Does the Orin module come with a BSP on it? How would I load a simple “Hello World” program?

Again, this is for an Orin SoM that will be on a custom carrier card. I know how to program the NV devkit. I want information on what I need on a custom card to program device without necessarily copying everything that the NV devkit does, only the essentials.

4

Actually a true project here requires you to tell more about your requirements but not just how you describe these things now.

For example, does your board need to remote update? If so, then a Ethernet is required

Will this board has chance to get reflashed? If so, then USB0 for recovery mode is needed. If not, then how did you expect it to get recovered if something goes dead?

You shouldn’t rely on anything that comes pre-installed from the module, even the bootloader software. Every module should be flashed by you to make sure the thing on it is really you want to use. (Yes, I strongly recommend you keep the usb port for recovery mode)
For example, if your module is manufactured 1 year ago, the pre-installed bootloader on it would definitely be older version ( or even something we don’t know), which may not have latest fix for some bugs.

As for running a program, I am not sure how to reply because the coverage of your question is too large. If you want to run a basic program, then it has nothing different from how you run a program on another Ubuntu machine.

However if you are talking about the BSP, then it relies using the flash tool we provided.
Bootloader/OS are essential and won’t be skipped.

5

Just some trivia, not in a particular order:

  • Jetsons are not set up for JTAG programming. When put in recovery mode a Jetson is a custom USB device understood by a custom USB driver.
  • JetPack/SDK Manager is just a GUI front end to the actual flash software. The actual flash software is known as the “driver package” because this is the previously mentioned custom USB driver that understands this custom USB device.
  • Recovery mode is mandatory for flash, but does nothing at all unless the flash software has changed something. If you don’t have recovery mode and the correct USB port available, then the Jetson cannot be flashed even with JTAG.
  • One can flash a Jetson on one carrier board using software intended for another, and then move the Jetson to the other carrier board. I suppose there might be a learning curve involved to do it that way, so it is probably a good idea to be able to use your custom carrier board with the USB port needed during flash, along with a way to go into recovery mode.
2 Likes
6

Actually a true project here requires you to tell more about your requirements but not just how you describe these things now.

For example, does your board need to remote update? If so, then a Ethernet is required

No, the board would be updated locally. I would physically get the board and perform the update.

Will this board has chance to get reflashed? If so, then USB0 for recovery mode is needed. If not, then how did you expect it to get recovered if something goes dead?

Yes, it can get reflashed. The more important question for me is how I would flash the board in the first place. For the first time.

You shouldn’t rely on anything that comes pre-installed from the module, even the bootloader software. Every module should be flashed by you to make sure the thing on it is really you want to use.
For example, if your module is manufactured 1 year ago, the pre-installed bootloader on it would definitely be older version ( or even something we don’t know), which may not have latest fix for some bugs.

If I can’t rely on anything being pre-installed, then I need to know how to install it myself. What options do I have? I think you’ve already implied this in your previous responses, but it seems that I do need to copy the USB recovery feature from the devkit.

As for running a program, I am not sure how to reply because the coverage of your question is too large. If you want to run a basic program, then it has nothing different from how you run a program on another Ubuntu machine.

This assumes that I will install an OS on the machine. Is this required, or can the processing system on the module run “bare metal”?

However if you are talking about the BSP, then it relies using the flash tool we provided.
Bootloader/OS are essential and won’t be skipped.

I am talking about the BSP, which is required to initialize programs when the system starts, and I am talking about any program (including the OS) that would be loaded into memory by the BSP. At this point, I am just trying to understand how the system works, so I can determine what I need on my board.

I could compare it to a typical embedded system with an MCU. If I had a generic MCU on the board, I could program/flash it with something like JTAG. I could connect the MCU to UART to read out simple serial data. This is basically what I’m trying to figure out for the Orin SoM. If I install an Orin module on a custom board, what does the board need to have on it for me to flash the thing?

7

This is some good general information.

My use-case would be something like this. The carrier board with the Orin would connect to a couple of cameras via Ethernet. The cameras would capture visual data that would be sent to the Orin GPU for processing. What this processing entails, what the code needs to do, is opaque to me. I don’t know. I might not be working on the software side myself. I just need to design a carrier card to make the Orin useable.

Unfortunately, I can’t use an existing carrier card in the final product due to design constraints. I can, however, use the NV devkit for testing purposes, but the devkit probably has complexity that I don’t necessarily require, and it runs Ubuntu with a bunch of peripherals, so you can basically use it as a desktop computer.

My card will not be used as a desktop computer. It’s going into a closed box. It’ll be programmed once, and hopefully, it won’t have to be reprogrammed. However, it must be reprogrammable just in case. It won’t ever be programmed/reprogrammed remotely.

If I had something like a Xilinx SoC, I could load a bootloader and program the programmable logic via USB or JTAG using Xilinx software. If I had a generic MCU, I could use JTAG and manufacturer drivers to store whatever program(s) I wanted on the device.

What would be the analogous process here with the Orin SoM on a custom board?

8

Let’s make this answer in short one.

You can only flash the board through usb recovery mode. No other method.

Bootloader is also part the of the software that got flashed to it too.

Why we are talking about Jetson devkit is your custom board is just smaller set of functions from NV devkit. What NV devkit cannot achieve, then your board cannot do it either.

For example, did you have other method to update the module on NV devkit other than USB recovery mode? I guess not. This is same to your own carrier board.

9

Okay, I think I’ve exhausted the information I can get on this. Thanks.

10

We can only support you with the structure/boot flow that based on what we offered on NV devkit.
If you need something more than that, then it may not exist.

For example, I feel you expect us to give you something that can run a program without OS or reflash. Unfortunately that thing does not happen.

As for the rest, disabling some I/O interface are of course acceptable.

11

No, I want to copy the NV devkit as much as possible, but only use what I need. At minimum, I wanted to know what components I need to be able to boot the system, flash it with new firmware, and load software like an OS. I think I’ve gathered enough here to determine that USB recovery mode will be necessary.

The datasheet refers to QSPI serial flash. There’s a 64MB NOR Boot Flash (QSPI) on the module. How does this get flashed? Is it through the USB recovery mode?

12

Yes, also through USB recovery mode. Bootloader will be flashed to this QSPI.

1 Like
13

Jetsons don’t have a traditional BIOS, but they do have the equivalent in software written to signed partitions of the eMMC for eMMC models. The boot chain, and this equivalent of a BIOS, are why Jetsons cannot “self flash”; this is also why you must use the recovery mode USB to flash. Without the correct USB exposure you won’t be able to flash an o/s on that carrier board. You might use a different carrier board to flash from.

Incidentally, one part you don’t want to skip if you are bringing this up, is the serial console port. You’re pretty much screwed without that if you need to debug boot.

Also, some CUDA-based software actually requires the X server to be running, so make sure you can operate your software headless if you are skipping the HDMI and/or DisplayPort. If you cannot, then a virtual X server could be used.

14

I can see your point about using another carrier board for flashing. This is the simplest solution. I’ll have to think over the usefulness of having flashing capabilities.

Software testing can be performed on the NV devkit, so it makes some sense to flash it all on a different board and simply transfer the module to the new one.

Yes, I plan to put serial ports on the board for UART-based debugging.

That’s a good consideration. I’ll keep that in mind.

15

One more point to consider: If you have an EEPROM or some other feature on the carrier board itself, then you probably want to be able to flash with the module on the carrier board. I’m suggesting to consider if anything on the carrier itself needs flashing that is part of the module flash.

16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.