Is it possible to Dynamically Select Pinmux and DTB for Multi-Baseboard Compatibility in Unified OTA and MFI Packages

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

Hi,

we are designing our own carrier board and ourcarrier board design is continuously evolving, which leads to changes in the pinmux/pinmux and device tree. We can distinguish different baseboards in the hardware settings based on the board ID(from a MCU).

Is it possible to use this board ID to select different pinmux/gpio configurations or DTBs to achieve compatibility, so that a single software package can run on different baseboards and different baseboards can share the same OTA and MFI packages?

For DTB, I think I can modify the UEFI code or extlinux.conf to select different device trees.
But for pinmux/gpio, can I achieve this goal?

Thanks

2

*** Please note that this reply is generated by LLM automatically ***

I understand your question. You’re designing a custom carrier board for the Jetson AGX Orin module, and your design is evolving, leading to changes in the pinmux and device tree. You want to know if it’s possible to use a board ID from a Microcontroller Unit (MCU) to select different pinmux and GPIO configurations or Device Tree Binary (DTB) files, so that a single software package can run on different baseboards and share the same Over-The-Air (OTA) and Machine Firmware Image (MFI) packages.

Short answer: Yes, it is possible to achieve this goal.

Long answer:

For the Device Tree Binary (DTB) selection, you can modify the UEFI code or extlinux.conf to select different device trees based on the board ID. This is a common approach to support multiple hardware configurations with a single software package.

For the pinmux and GPIO configurations, you can use the compatible property in the device tree overlay to specify the supported Jetson platforms and their corresponding pinmux configurations. The compatible property is used to identify the combination of Jetson module and carrier board that the overlay supports.

To dynamically select different pinmux and GPIO configurations based on the board ID, you can use the following approaches:

  1. Update the MB1 pinmux BCT: You can update the MB1 pinmux BCT to configure the pinmux settings for each board ID. This requires modifying the T23x BCT Deployment Guide and generating the correct .dtsi files from the Jetson AGX Orin pinmux spreadsheet.
  2. Dynamically make pinmux changes: You can use the GPIO tools to dynamically change the pin settings if the pin meets certain conditions (e.g., part of the 40-pin header, not configured as an SFIO pin by the MB1 BCT, and configured to be bidirectional by the MB1 BCT).

To achieve compatibility and share the same OTA and MFI packages across different baseboards, you can:

  1. Use a single software package: Create a single software package that includes all the necessary device tree overlays and pinmux configurations for each supported board ID.
  2. Use a board ID-based selection mechanism: Implement a mechanism to select the correct device tree overlay and pinmux configuration based on the board ID read from the MCU.

By using these approaches, you can create a flexible and scalable solution that supports multiple hardware configurations with a single software package, while also sharing the same OTA and MFI packages across different baseboards.

Comparison with other approaches:

While modifying the UEFI code or extlinux.conf can be used to select different device trees, it may not be the most efficient approach for selecting pinmux and GPIO configurations. Using the compatible property in the device tree overlay and dynamically selecting pinmux configurations based on the board ID provides a more flexible and scalable solution.

In summary, using a combination of device tree overlays, pinmux configurations, and a board ID-based selection mechanism, you can achieve compatibility and share the same OTA and MFI packages across different baseboards, while also supporting multiple hardware configurations with a single software package.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

5

Hi hanyang369,

What’s the Jetpack version in use?

For the different board, we would suggest using the different board config no matter you want to flash or generate OTA payload.
You can find that there’re many board config under <Linux_for_Tegra>/.
Since different board may be applied with different configurations like the BCT, BPMP, PINMUX, DTB..etc rather than just kernel device tree, you should create the different board configuration files for different boards.

6

Hi Kevin,

Jetpack version is 6.0.
I have read Setting Optional Environmental Variables, But I still don’t understand how to add the conf file. Suppose I have two hardware boards now. How do I create agx_version_a.conf and agx_version_b.conf under <Linux_for_Tegra>? Do I need to copy the contents of the jetson-agx-orin-devkit.conf file and then add environment variables at the end to point to the corresponding device tree and pinmux files? How should the flashing command, the command to generate the OTA file, and the command to generate the mfi file be modified to use the new conf files?
The current flashing command is:

sudo ROOTFS_AB=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1 -S 30GiB -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_ab.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg" --network usb0 jetson-agx-orin-devkit external

The commands to generate the OTA and MFI packages are:

sudo -E ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh --external-device nvme0n1 jetson-agx-orin-devkit R36-3
sudo BOARDID=3701 FAB=500 BOARDSKU=0005 ROOTFS_AB=1 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --massflash 5 --external-device nvme0n1 -S 30GiB -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_ab.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg" --network usb0 jetson-agx-orin-devkit external
7

Yes, it would be a good start to copy from original jetson-agx-orin-devkit.conf and rename them to agx_version_a.conf and agx_version_b.conf respectively.

Please check the contents inside the board config to match your board design.

You can simply replace jetson-agx-orin-devkit with either agx_version_a or agx_version_b no matter for OTA or mfi package.

For the OTA, you might need to do some customization in OTA update tool to add the support for your custom board config. You can refer to the patch in the following thread for details.
How to generate OTA payload for custom baords - #7 by KevinFFF

8

Hi Kevin,

thanks for your reply.
I now roughly understand that using the corresponding board conf file and flash command, you can flash the corresponding board or generate the corresponding mfi package or ota package. If you use the Linux_for_Tegra flashing environment, you can achieve version unification (different boards can use the same BSP, just need to specify different conf files), but currently we are releasing mfi and ota packages instead of the Linux_for_Tegra flashing environment.
Now my question is whether it is possible to generate only one mfi package and ota package that can flash or ota upgrade both agx_version_a and agx_version_b boards.
My use case is that we have different hardware versions, and if each hardware version uses one mfi or ota package, the maintenance cost is too high, requiring different code branches and build version pipelines. Do you have any suggestions?

Thanks

9

I think you should release the BSP package instead of just the mfi or OTA payload as the flashing tool is included in BSP package. Without the flashing tool, you would not be able to flash. Most of our partner would create their own custom BSP package with custom board config included.

We use the board config to distinguish which board should be flashed.
You can add some logics inside the board config to make it compatible with different modules but not for the different boards.

What’s the difference between those boards?
Which part in board config would be different for them?

10

Hi Kevin,
The BSP package indeed has more features, but it is too large. A compiled BSP package (which has run the flash script with “no flash” to generate images) is about 300-400G, while the mfi package is more concise, only 30G in size, and can be flashed by executing the mass flash command after unzipping.

What’s the difference between those boards?

The main differences are in pinmux.dts, gpio.dts, and the device tree, as well as application differences. These differences mainly come from the design of the hardware circuit and different peripherals. For example, on agx_version_a, a certain GPIO is used as UART, while on agx_version_b, the same GPIO is used as GPIO. We can distinguish the upper-level differences at runtime using our own boardID. The device tree can also be distinguished in UEFI through boardID combined with extlinux.conf.
However, configurations like pinmux.dts, gpio.dts, and ODMDATA cannot be distinguished at runtime. I think they should take effect at the MB1 stage. So, I want to see if we can distinguish them during the flashing process.

Which part in board config would be different for them?

The main differences should be in these three parts: DTB_FILE PINMUX_CONFIG ODMDATA.

Thanks

11

You need to customize and add something to distinguish for the flash script.
In original case, we can read the data from CVM EEPROM to know the module in use and select for the correct configurations in board config.

It seems 20-30G for the whole BSP package in my case.
You can also remove the used files inside.

13

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