De-mystifying platform adaptation process and terms for Jetson Xavier NX

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hello,

while working with Xavier NX, some questions have remained mystery to me for a long time, and would like to get them answered.

Assume you are developing a custom carrier board with minor changes to the evaluation kit board, want to change the functions and configurations of a few pins and devices, and therefore need to modify the gpio, pinmux and device tree:

  1. What are the names “quill”, “galen”, “jakku” etc.?
    I assume these are the working titles for reference design boards and, by digging deeper, it’s obvious that “jakku” relates for the Xavier NX evaluation kit, but it’s actually not said anywhere. Are the names related to carrier-boards, modules or some other reference designs?

  2. What is the correct way to enable/disable devices and change pin functions on Xavier NX?
    It’s not clear, what files are intended to be modified in order to configure certain devices. For example, I can find configuration related to pcie@141a0000 in several files across the device-tree source directory:
    tegra194-p3668-common.dtsi
    tegra194-p3668-pcie-plugin-manager.dtsi.
    tegra194-plugin-manager-p3668.dtsi
    tegra194-soc-pcie.dtsi

Some forum posts mention certain bits of ODMDATA value affecting on the operating modes of the PCIe-controllers. The file tegra194-p3668-pcie-plugin-manager.dtsi seems to have modular, conditional fragment-pcie-c5-rp and fragment-pcie-c5-ep, but what mechanism causes the selection?

  1. What is the role of the pinmux- and gpio-dtif files on Xavier NX platform?
    It is well documented that the pinmuxes are to be converted to cfg files for the bootloader, and how to do it. The purpose for that is a bit unclear. Yes, the pinmux and pad-voltage -files contain the hardware initialization data, but is the data needed to be included the dtsi files on the kernel device-tree also? Or does the boot-process initialize the harware and configure the device-tree according to the cfg files (I here refer to the fragments found in tegra194-p3668-pcie-plugin-manager.dtsi)? The other platforms device-tree sources have several “pinmux” named files, but t19x has none.

  2. What is ODMDATA value?
    The flash.sh includes a ODMDATA parameter. Currently it is defined as 0xB8190000 for Xavier NX, but I cannot find documentation about how to modify it and what it actually does. Some forum threads do mention that certain bits affect on the PCIe controller modes.

  3. What difference the eeprom id makes?
    The file p3668.conf.common has a comment “undef for non eeprom boards” for process_board_version(). What change does it make? (The same question applies to DEFAULT_FAB -parameter, I guess)

Hope you can de-mystify these issues. Thanks.

3

hello juho.roine,

as you can see from the L4T sources, those were names of each Xavier DevKits.
for example,
$L4T_Sources/r32.4.3/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19x

$ tree -L 2
.
├── common
│   ├── bct
│   └── kernel-dts
├── galen
│   └── kernel-dts
└── jakku
    └── kernel-dts

please note that, device tree properties can be overwritten by later include *.dtsi files.
you may review the orders of those device tree sources, usually, it’s plugin-manager to include at last.


you may check board configuration file for the value of ODMDATA.
for example,
Jetson-Xavier were using board configuration file, p2972-0000.conf.common.

ODMDATA=0x9190000;

instead,
Jetson-Xavier-NX using board configuration file, p3668.conf.common.

ODMDATA=0xB8190000;

please access pinmux spreadsheets via download center. if you done pinmux customization and click the Generate DT File button on the top-right. you’ll also found there’re several *.dtsi files for your usage.
please refer to developer guide,
you should check Jetson Xavier NX and Jetson AGX Xavier Series MB1 Platform Configuration chapter for more details of board customization.


it’s used for feature configuration.
for example,
you may refer to developer guide, Flashing the PCIe Endpoint on a Jetson AGX Xavier Series System.
there’s a specific way to enable PCIe endpoint mode by updating ODMDATA.
FYI,
you may also examine ODMDATA on your target, i.e. /sys/firmware/devicetree/base/chosen/plugin-manager/odm-data


please refer to Jetson Module EEPROM Layout for more details.
thanks

4

Thanks for the reply.

I have read these documents, but still, the meaning of each bits of ODMDATA is unexplained.
The device tree directory /sys/firmware/devicetree/base/chosen/plugin-manager/odm-data shows nodes from device-tree expectedly as a result of ODMDATA value, but the question remains: how to know which bits of the ODMDATA parameter (such as 0xB8190000) to change to get certain changes in the mentioned device-tree directory? I.e. what are the functions of each of these 32 bits:
1011 1000 0001 1001 0000 0000 0000 0000 (0xB8190000 as binary number)

File Tegra_Linux_Driver_Package_AGX_Xavier_Adaptation_Guide.pdf explains some of the bits for AGX Xavier, but no such table is found for the Xavier NX.

The following thread indicates that the bit 13 (mask 0x1000) stands for endpoint mode for C5 controller.
So, now only 31 bits to figure out :) Can you supply this data or point, where it can be found?

This explains the already well-documented dtsi file creation process, but the unanswered question is, in which cases the device tree sources are needed to be changed and recompiled?

Here’s an example:
If I change the bit 13 of ODMDATA from 0 to 1 (ODMDATA=0xB8191000), after complete reflashing the device and running oem-config, the data in /sys/firmware/devicetree/base/chosen/plugin-manager/odm-data can be seen changed representing the new ODMDATA value, for example:

  • node disable-pcie-c5-endpoint = <0x1> is removed
  • node enable-pcie-c5-endpoint = <0x1> is added.
  • and some other related changes in the device tree can be seen.

The only change made to the flashing process was changing one bit in the ODMDATA value. No manual changing of device tree sources was needed.

Now, what mechanism did the change? I can figure out at least these options:

  1. bootloader manipulated the device tree that it then passed to the kernel?
  2. flash.sh manipulated the device tree that it then flashed to kernel to use?
  3. oem-config manipulated the device tree during the first boot?

To affect, this change seem to happen with complete reflashing of the device (cannot say, which partitions exactly needed to be flashed, but MB1_BCT or kernel-dtb partitions did not affect, and running oem-config was not needed). Could you explain, what really happens here?

If I now change the pinmux and pad-voltage configurations (tegra19x-mb1-pinmux-p3668-a01.cfg and tegra19x-mb1-padvoltage-p3668-a01.cfg files), do I need to apply and compile the pinmux and pad-voltage dtsi-files to the kernel device tree or will the changes be applied there by the bootloader/oem-config/flash.sh or whatever did the previous change?

5

hello juho.roine,

may I also know what’s your actual use-case, for example, what’s the goal of platform configuration with ODMDATA,
thanks

6

How can I know even what can be configured through ODMDATA value, if it is not documented at all?

7

hello juho.roine,

ODMDATA is one 32-bit number passed during the flashing. such as HSIO, PCIE, and UPHY configurations. It is used by bootloader and kernel for some configuration.
for example,
you may access Jetson AGX Xavier Platform Adaptation and Bring-Up Guide, please refer to [Table 3. ODMDATA bits for UPHY lane assignment] for reference.
thanks

8

The link is related to AGX Xavier. Is it valid data for Xavier NX too?

9

hello juho.roine,

Yes, both Xavier and NX were based-on same Tegra chip, i.e. T194 series.