How are different carrier boards identified in order to load the right device tree?

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
#1

I have a Jetson Xavier NX SoC that I want to use with a new carrier board developed in house. I am a bit confused about how the carrier board is identified by the bootloader and consequently loads the correct device tree.

Any assistance in the following would be greatly appreciated!

  • In a device tree structure, the “compatibility” node is used to match up hardware with drivers/modules. However, the device tree root node “compatibility” is for the entire carrier board. What is this being matched with?
  • I read in an embedded linux book that “machines” are defined by DT_MACHINE_START and DT_MACHINE_END macros in the kernel source, and this is what is compared against with the root node compatibility string. But using the devkit device tree as an example I cannot find a macro for the SoC + devkit (eg “nvidia,p3449-0000+p3668-0000”)
  • Is the carrier board eeprom involved in something? I can see in the cboot source that the only eeprom it seems to care about is one labeled “cvm” ie the eeprom on the SoC
  • I am not using extlinux.conf to load my device tree, so the only device tree I want to be using is flashed to the kernel-dtb partition. In this case, does it even matter what the root node “compatibility” field is, since there is only one to load?

Thanks!

#2

Follow up: In investigating OTA updates for the bootloader, I noticed that in /etc/nv_boot_control.conf I have the following two entries:

Device TN Spec: 3668-200-0001-G.0-1-2-jetson-xavier-nx-p0-mmcblk0p1
Device Compatible Spec: 3668----1–jetson-xavier-nx-p0-mmcblk0p1

Where have these come from? I had previously been using “jetson-xavier-nx-p0” as the name of my flashing conf, although I have since changed to -p1, so I am now really confused!

#4

Hi,

I think you overestimate the bootloader… it does not know which device tree should be loaded.
The device tree is decided by user side during flash.

1 Like
#5

Device TN Spec: 3668-200-0001-G.0-1-2-jetson-xavier-nx-p0-mmcblk0p1
Device Compatible Spec: 3668----1–jetson-xavier-nx-p0-mmcblk0p1

And this has nothing to do with the device tree. We have a table in OTA tool and it will also use the info read from board eeprom.

1 Like
#7

Ah great thanks very much!

So when is the device tree root node “compatibility” string important? And when you say “OTA tool” do you mean the update engine, and does “board eeprom” mean carrier board eeprom?

Thanks for the quick reply!

#8

I am sorry to make you confused.

  1. So when is the device tree root node “compatibility” string important?

Actually, I never touched this property so not sure what impact might happen. You can try to modify it and see if anything is not funcitoning.

  1. And when you say “OTA tool” do you mean the update engine,

Yes, the update engine.

  1. and does “board eeprom” mean carrier board eeprom?

It should be module eeprom. We don’t read carrier board eeprom.

#9

Great! I will try changing that root node string and see if anything changes.

Also, I will assume that the carrier board eeprom is only for whatever purpose I wish to use it for, and isn’t important for anything nvidia related.

I just have one more question (sorry, maybe I should make a new thread): how is the update engine getting those spec and compatibility strings? I guess I need them to match if I want to update the bootloader using OTA

#10

Please refer to