OTA issues with custom images and custom carrier boards

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hello everyone, I’ve customized two versions of the JetPack firmware for my custom carrier board: JetPack 5.1.3 and JetPack 6.2.

I want to create an OTA package to upgrade from JetPack 5.1.3 to JetPack 6.2. The configuration file for my custom carrier board is called recomputer-orin-j40mini.conf, so I ran the following command to generate the OTA payload:

export BASE_BSP=/home/pss/mydisk/D/jetson/JP5.1.3/Linux_for_Tegra
export TARGET_BSP=/home/pss/mydisk/D/jetson/JP6.2/Linux_for_Tegra
cd $TARGET_BSP
sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh   --external-device nvme0n1 -S 80GiB   recomputer-orin-j40mini R35-5

It shows that my carrier board is not supported, so I tried to use `jetson-orin-nano-devkit` to see if I can generate an OTA payload package:

sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh   --external-device nvme0n1 -S 80GiB   jetson-orin-nano-devkit R35-5

The script runs successfully here, but an error message appears at the end:

*** Sign and generate BUP... *** 
t23x payload generation complete with 5 failure(s)

SUCCESS: cleaned up BUP tmp files prior to payload creation
FAILURE: no payload made for config "boardid=3767;fab=000;boardsku=0000;boardrev=;fuselevel_s=1;chiprev=;chipsku=00:00:00:D3;board=jetson-orin-nano-devkit;rootdev=nvme0n1p1;bup_type=bl;signed_img_dir=images-R36-ToT"
FAILURE: no payload made for config "boardid=3767;fab=000;boardsku=0001;boardrev=;fuselevel_s=1;chiprev=;chipsku=00:00:00:D4;board=jetson-orin-nano-devkit;rootdev=nvme0n1p1;bup_type=bl;signed_img_dir=images-R36-ToT"
FAILURE: no payload made for config "boardid=3767;fab=000;boardsku=0003;boardrev=;fuselevel_s=1;chiprev=;chipsku=00:00:00:D5;board=jetson-orin-nano-devkit;rootdev=nvme0n1p1;bup_type=bl;signed_img_dir=images-R36-ToT"
FAILURE: no payload made for config "boardid=3767;fab=000;boardsku=0005;boardrev=;fuselevel_s=1;chiprev=;chipsku=00:00:00:D5;board=jetson-orin-nano-devkit;rootdev=nvme0n1p1;bup_type=bl;signed_img_dir=images-R36-ToT"
FAILURE: no payload made for config "boardid=3767;fab=000;boardsku=0004;boardrev=;fuselevel_s=1;chiprev=;chipsku=00:00:00:D6;board=jetson-orin-nano-devkit;rootdev=nvme0n1p1;bup_type=bl;signed_img_dir=images-R36-ToT"
SUCCESS: cleaned up BUP tmp files after payload creation
Failed to run ROOTFS_AB= ROOTFS_ENC=  /home/pss/mydisk/D/jetson/JP6.2/Linux_for_Tegra/l4t_generate_soc_bup.sh -f /tmp/board_spec_file -e tmp_board_spec -b jetson-orin-nano-devkit t23x

I don’t quite understand what this error means. Is there something wrong with my steps? How can I generate the OTA payload package correctly?

3

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

Based on the provided context, I’ll try to help you troubleshoot the issue.

Firstly, it’s great that you’ve customized two versions of the JetPack firmware for your custom carrier board. To create an OTA package to upgrade from JetPack 5.1.3 to JetPack 6.2, you’ll need to generate an OTA payload package.

The error message you’re encountering suggests that your custom carrier board is not supported by the OTA payload generation script. This is likely because the script is looking for a specific configuration file that matches your carrier board.

Here are a few potential issues with your steps:

  1. Incorrect configuration file: You mentioned that your configuration file is called <custom_carrier_board_name>, but you didn’t specify the exact name. Make sure that the configuration file name matches the one expected by the OTA payload generation script.
  2. Missing or incorrect board specs: The script might be looking for specific board specs in the ota_board_specs.conf file. Ensure that the board specs for your custom carrier board are correctly defined in this file.
  3. Unsupported carrier board: Although you’ve customized the JetPack firmware for your carrier board, it’s possible that the OTA payload generation script doesn’t support your specific carrier board. You might need to modify the script or add custom support for your carrier board.

To generate the OTA payload package correctly, you can try the following:

  1. Verify the configuration file name: Double-check that the configuration file name matches the one expected by the script.
  2. Check the board specs: Ensure that the board specs for your custom carrier board are correctly defined in the ota_board_specs.conf file.
  3. Use the jetson_orin_nano_devkit configuration: Since the script runs successfully with the jetson_orin_nano_devkit configuration, you can try modifying this configuration to match your custom carrier board. This might involve updating the board specs, kernel device tree, and other configurations to match your custom carrier board.
  4. Consult the documentation: Review the documentation for the OTA payload generation script and the JetPack firmware to ensure that you’re following the correct procedures.
  5. Seek additional support: If you’re still encountering issues, you may want to reach out to the NVIDIA developer community or seek additional support from NVIDIA or other experts familiar with the JetPack firmware and OTA payload generation.

By following these steps, you should be able to generate the OTA payload package correctly and upgrade your custom carrier board from JetPack 5.1.3 to JetPack 6.2.

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

5

jetson_orin_nano_devkit is the configuration file of the official board. I am sure that I have done everything that this big model said.

6

My implementation process is based on: Software Packages and the Update Mechanism — NVIDIA Jetson Linux Developer Guide Is there anything else I should pay attention to? Also, based on my log, can you observe any incorrect places?

7

Hi shuisheng.peng,

It seems you are developing a custom board and you want to implement OTA support from Jetpack 5.1.3 to Jetpack 6.2

To support your custom board configuration for OTA, you have to customize the OTA tool to make it recognize your custom carrier board.
You can simply refer to the patch in the following thread when we add support for super mode configuration.
How to generate OTA payload for custom baords - #7 by KevinFFF

8

Thank you, this is effective; in addition, the solution to the following error is to create a /usr/bin/python file, which can be linked to the python3 file used by your host

FAILURE: no payload made for config "boardid=3767;fab=000;boardsku=0000;boardrev=;fuselevel_s=1;chiprev=;chipsku=00:00:00:D3;board=jetson-orin-nano-devkit;rootdev=nvme0n1p1;bup_type=bl;signed_img_dir=images-R36-ToT"
1 Like
9

Now I’ve encountered another problem: my OTA was successful, and after restarting the device, it updated to ProjectPack 6.2, but I can no longer log in with my original system username and password. Is there any solution?

10

I found that it was because there was a file system in my OTA package. When the OTA was successful, the system would use the new file system, and the username and password of the original file system would no longer be valid.

11

Correct, I would suggest you referring to Skipping oem-config to pre-configure the username/password in BSP package before creating OTA package.

13

If I have done a series of development on 5.1.3 and there are various programs of mine in the system, is there a way to keep these programs after OTA?

14

It depends on what do you want to preserve.
If you just want to keep some files, then you can specify them in ota_backup_files_list.txt. If you want to preserve some program/applications installed in rootfs, you may try clone and restore the APP partition.(i.e. system.img.raw). You can use the cloned rootfs image to create the OTA payload.

15

If use the backup image, will the old root file system still be used after OTA? For example, after upgrading from jectPack5 to jectPack6, normally the Ubuntu version and other NVIDIA software versions will be upgraded; if use the backup image after OTA, Are Ubuntu and other NVIDIA packages from JetPack 5 still being used?

16

Yes, the old rootfs will still be used. I’m not sure if it may cause unexpected behavior. Some packages from JP5 may not work well in JP6 and they should be updated. They are all handled by Debian packages.
We will suggest not using the rootfs from old release but create a new rootfs based on new release with all required packages installed.

17

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