How to update u-boot binary on the LNX partition for Jetson Nano without flashing

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
, ,
1

Hi,

This topic is created to ask for a method to update the bootloader (u-boot) of Jetson Nano, after being logged into it, without flashing.

We have changes to u-boot as per this topic: Jetson Nano production module does not boot on custom carrier board, but does so on auvidea's - #41 by jetson_user

And we are looking for a solution for updating the u-boot with the above changes using a partition update, as can be done for dtb. For the dtb update, we use the method mentioned here: How to update dtb without flashing on Jetson Nano production module - #7 by WayneWWW.

Also, do we need to use a signed-encrypt method for updating u-boot? If so, what would be the command for it, or could you please direct us to related info in the Jetson Nano design guide, if present?

2

Sorry, just realized there is documentation regarding this already in the design guide here: https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_update_nano_tx1.html#wwpID0E03E0HA

So as a first step I am generating a single-spec BUP, using the command:

sudo BOARDID=3448 FAB=B00 ./build_l4t_bup.sh jetson-nano-emmc mmcblk0p0

But I get the error: “SyntaxError: Missing parentheses in call to ‘print’. Did you mean print(‘PARTITION INFO :’, arg.entry_list)?”

What would be the correct value for BOARD and FAB env variables for Jetson Nano production module, given that we have our custom carrier board. Also, are any other env variables needed?

4

hello jetson_user,

which JetPack release version you’re using. this may not support with the latest r32.6.1 release.

6

We are using Jetpack 4.2.1. With r32.2 release.

7

The bootloader update mechanism you see in the document does not support jetson nano when it was on jetpack4.2.1.

8

Hi WayneWWW,

Thanks for your reply.

Then what would be an alternative to update the bootloader as mentioned in the question?

9

Are you saying that you want to upgrade it on device instead of flashing from host?

10

Yes, directly on the device while being logged into it (via SSH). As there is no possibility for flashing as our units are within a casing which does not support USB.

11

But of course the bootloader binary needs to be built on the host first.

12

Hi,

Any updates on this issue yet?

13

You can try to use dd to write the binary to partition.

14

Don’t know if it would matter, but some partitions need content signed. If you do use dd, and it does not work, then try signing first (and then using dd to add the signed content). See:
https://forums.developer.nvidia.com/t/can-runtime-update-sdmmc-boot-partition-after-enabling-fuse-by-rcm-boot-nfs-or-ota-upgrade/82334/2

Also, whether signed or not, make sure your content which you are overwriting with fits in the partition. You might examine the size of non-formatted partitions with a command such as “lsblk -b” (you could name a specific device or partition with that command as well).

15

Hi linuxdev and WayneWWW,

Thanks for your responses. Indeed the issue in the link provided above is similar to ours. But my question is how to generate the signed encrypted binary parition update file. Like what command to use. I tried the one mentioned in my first reply and it does not work. Also stated by WayneWWW that it wont work for this Jetpack, so what is an alternative command to generate such a file in the first place?

After I have this file, I will be able to update using the ‘dd’ command.

I need it specifically for the bootloader, because we already can update the device tree partition using the dd command.

16

That is given in the URL I provided above. The “--no-flash” option to flash.sh causes some temporary files to remain, and to not actually flash a Jetson. Basically file setup prior to flashing. The encrypted version of the file would then remain in place. I suggest trying this, along with logging what goes on as a way to see what files are where. Example from that URL, modified to log:

sudo ./flash.sh --no-flash -u <keyfile> -v <sbk_keyfile> -k <partition-id> jetson-xavier mmcblk0p1 2>&1 | tee log_keyfile.txt

(note the " 2>&1 | tee log_keyfile.txt" is the part which logs to file “log_keyfile.txt”)

17

Thanks linuxdev!

I saw the command but thought it was specific to Xavier and we are using Nano. Anyway, I’ll try this for Nano, and I found this link: https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3261/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootloader_secure_boot.html#wwpID0E0SG0HA to generate the keyfile. Will update here once I have the results.

18

Note that each host PC flash directory (~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/") has many “jetson-*.conf” files. If you leave off the “.conf” suffix, then these are valid flash targets named after the hardware. Most are symbolic links pointing at the file named after the module and carrier board combination, whereby the symbolic links could be considered the “plain English” naming convention. Example of a file there:
jetson-nano-devkit.conf
…which implies this is a flash target:
jetson-nano-devkit

You would name that instead of “jetson-xavier”.
(note that there are QSPI versions of the above if you are not flashing the SD card itself and want just the boot content stored in QSPI)

19

Hi,

I tried this command:
sudo ./flash.sh --no-flash --sign -x 0x21 -y PKC -u <path_to_rsa_priv_2048.pem> jetson-nano-emmc mmcblk0p1

but I got an error:

Error: Return value 3
Command tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.

Please find attached the full logs here: boot_update.txt (1.4 KB)

Then I tried without signing, Just simply the command: sudo ./flash.sh –-no-flash jetson-nano-emmc mmcblk0p1

I see the boot.img being generated. Is this the file to be written to the LNX partition (/dev/mmcblk0p11)?

20

I couldn’t answer the cause of the failure, but if this worked, then there’d be a both a “boot.img” and an encrypted version, something like “boot.img.sign” (not sure of the name). Someone else would have to tell you the partition label, as there is both a kernel partition (not always used) and a bootloader partition (I don’t know if the one you named is for the kernel or not, I’d have to look it up).

If you don’t mind “normal” flashing, then I’d suggest you log that as a reference, and save the log. This would tell you exactly what to expect, although it would not save any signed version (the signed version would be created and the log would show it being transferred to the Jetson, and then the file would be deleted). Example:
sudo ./flash.sh jetson-nano-emmc mmcblk0p1 2>&1 | tee log_flash.txt

This assumes you have an eMMC model…if you have an SD card dev kit, then this would fail.

Note: I do advise that once you have an install the way you like it that you save a clone of the rootfs for future use (including restore if something goes wrong).

21

Hi linuxdev,

Thanks for your reply. The command which failed did not generate a boot.img or its signed version. And within a working Nano, I ran this command: ls -al /dev/disk/by-partlabel, which gives the following output:

total 0
drwxr-xr-x 2 root root 320 nov 14 02:14 .
drwxr-xr-x 8 root root 160 nov 14 02:14 ..
lrwxrwxrwx 1 root root  15 nov 14 02:14 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root  16 nov 14 02:14 BMP -> ../../mmcblk0p13
lrwxrwxrwx 1 root root  15 nov 14 02:14 BPF -> ../../mmcblk0p6
lrwxrwxrwx 1 root root  15 nov 14 02:14 BPF-DTB -> ../../mmcblk0p7
lrwxrwxrwx 1 root root  16 nov 14 02:14 DTB -> ../../mmcblk0p10
lrwxrwxrwx 1 root root  15 nov 14 02:14 EBT -> ../../mmcblk0p4
lrwxrwxrwx 1 root root  16 nov 14 02:14 EKS -> ../../mmcblk0p12
lrwxrwxrwx 1 root root  15 nov 14 02:14 FX -> ../../mmcblk0p8
lrwxrwxrwx 1 root root  16 nov 14 02:14 LNX -> ../../mmcblk0p11
lrwxrwxrwx 1 root root  15 nov 14 02:14 RP1 -> ../../mmcblk0p3
lrwxrwxrwx 1 root root  16 nov 14 02:14 RP4 -> ../../mmcblk0p14
lrwxrwxrwx 1 root root  15 nov 14 02:14 TBC -> ../../mmcblk0p2
lrwxrwxrwx 1 root root  15 nov 14 02:14 TOS -> ../../mmcblk0p9
lrwxrwxrwx 1 root root  15 nov 14 02:14 WB0 -> ../../mmcblk0p5

So I think LNX can be safely assumed to be /dev/mmcblk0p11.

Interestingly when I ran the other command to generate the dtb, I get the boot.img.encrypted file inside <top>/Linux_for_Tegra/bootloader/signed. This is the command I ran:

sudo ./tegraflash.py --bl cboot.bin --bct P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg --odmdata 0x94000 --bldtb tegra210-p3448-0000-p3449-0000-a00.dtb --applet nvtboot_recovery.bin --cmd "flash; reboot" --cfg flash.xml --chip 0x21 --bins "EBT cboot.bin; DTB tegra210-p3448-0000-p3449-0000-a00.dtb" --cmd "sign;

I ran this command to get the dtb signed and encrypted. We had an issue that some Nanos do not boot on our custom carrier boards, for which the solution was to disable UART internally, full discussion here: Jetson Nano production module does not boot on custom carrier board, but does so on auvidea's. This required change in dtb and bootloader. Now with the solution, we can flash a non-booting Nano and get it to booting state again always. But we need to put these changes into the Nanos on field, which are running on our custom carrier board, so that in future it doesn’t happen that the Nanos suddenly stop booting (main cause being some Nanos being more susceptible to noise on uart-debug rx - pin 238). Since these Nanos are on-field, we cannot flash them, so we need to update them by logging in via ssh and updating the DTB and LNX partitions. Now we generate the dtb.encrypt using the above command, based on our discussion here: How to update dtb without flashing on Jetson Nano production module. And this command also generates boot.img.encrypt.

Since Nanos always boot on auvidea carrier boards, I use them for flashing. I tried this: I flashed our old <top> directory (without the fix for UART noise) on one of the noise-susceptible Nanos, and then put this Nano on our custom carrier board as a test. Naturally this did not boot, as our custom carrier board has noise on pin 238 and this Nano is susceptible to that noise. Now I put this Nano back on the auvidea carrier board and updated partition LNX with boot.img.encrypt, and the DTB partition with tegra210-p3448-0000-p3449-0000-a00.dtb.encrypt from the <top> directory with the fix. This was the fix for the UART noise, from what I understood. But even with this update, the Nano did not boot on our custom carrier board. So this tells me that either the bootloader changes have not gone under boot.img.encrypt, or that updating LNX partition with boot.img.encrypt has not effect.

Can someone verify if boot.img.encrypt file so generated is the one to use? It did not work in our case.

22

You are probably right about it being the LNX partition, but I have not kept up with this. There are some differences between systems using U-Boot versus CBoot, and I have not kept up with those differences. Someone else will know if U-Boot uses LNX on a Nano.

You are correct, if the signing is valid, that you could use something like dd on a running eMMC Nano to update that partition (provided the new binary fits within the space of the partition). One reason this might fail would be if the binary is from the wrong release, so do be sure you build based on the correct release. Being able to stop the serial console activity from stopping boot should do the job in this case with a correctly signed binary replacing the original U-Boot binary to disable U-Boot serial console.