Orin Nano R36.3.0 and R36.4.0 stuck at bootloader

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

Hi I got a issue with a SOM enable secure boot, which was working fine at R35.5.0
However when I either re-flash or OTA to 36.3 or 36.4 I got the issue
I> RSA PSS signature check: OK
E> tos: digest on binary did not mat¦¦¦

I already rebuilt eks_t234.img with our keys via command
python3 source/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py -chip t234 -oem_k1_key oem_k1.key -in_sym_key sym_t234.key -in_sym_key2 sym2_t234.key -in_auth_key auth_t234.key -out bootloader/eks_t234.img

I’m attaching both logs for you, please help me know why I can’t boot up the board.

flash_2-3_0_20241004-110226.log (89.4 KB)
uartlog.txt (30.7 KB)

2

Just add a comment that on R35.5.0 I have updated capsule payload to apply this patch from Orin NX hangs on optee (r35.5.0) - #5 by WayneWWW

4

hello anhhao.hcmus,

may I know your board authorization types (i.e. PKC, SBK…etc)
please also share the complete steps you’re used to re-flash the target with r36.4 release version.

5

Hi Jerry, I have reflashed to R35.5.0 and then OTA to 36.3 the issue doesn’t appear anymore.
If I can reproduce the issue I will capture all complete logs.
BTW, can I downgrade R36.3 to R35.5 by using OTA?

6

no, it’s not support to downgrade remotely.
you must re-flash the target with earlier release for moving backward.

7

Okay, thanks.

8

Hi Jerry, I met the issue again when manual upgrade 35.5 to 36.3
I> cpubl_params: nsdram: carveout: 1, encryption: 1
I> cpubl: Authentication Finalize Done
I> Binary cpubl loaded successfully at 0x272000000
▒▒ RSA PSS signature check: OK
[0000.076] I> MB1 (version: 1.4.0.1-t234-54845784-08e631ca)
[0000.081] I> t234-A01-1-Silicon (0x12347) Prod
[0000.085] I> Boot-mode : Coldboot
[0000.089] I> Entry timestamp: 0x00000000
please check the log I attached

ota-35.5-36.3.txt (60.6 KB)

9

hello anhhao.hcmus,

may I have your complete steps for cross-checking.
furthermore, did you running oem-config? or, you may try Skipping oem-config to set up your system.

10

Hi Jerry I was trying OTA from 35.5.0 to 36.3 by my own way, which works fine 35.5.0 to 35.5.0. Here are my breakdown steps:

  1. Extract rootfs to rootfs B
  2. dd boot.img to boot B partition
  3. Copy TEGRA_BL.cap to esp and trigger update by set efi variable
  4. Clean boot failure of chain B
  5. Reboot
    I do see boot loader update progress however it goes back to slot A and mark B unbootable
    Nvidia OTA method is working fine. Do I miss major steps?
11

One thing I noticed that I don’t have UEFI Menu after failure OTA

▒▒I/TC: Secondary CPU 1 initializing
I/TC: Secondary CPU 1 switching to normal world boot
I/TC: Secondary CPU 2 initializing
I/TC: Secondary CPU 2 switching to normal world boot
I/TC: Secondary CPU 3 initializing
I/TC: Secondary CPU 3 switching to normal world boot
I/TC: Secondary CPU 6 initializing
I/TC: Secondary CPU 6 switching to normal world boot
I/TC: Secondary CPU 7 initializing
I/TC: Secondary CPU 7 switching to normal world boot

12

hello anhhao.hcmus,

there’re some difference between rel-35 and rel-36, as you can see… From Rel-35 Kernel 5.10 to Rel-36 Kernel 5.15.
please follow developer guide, Over-the-Air Update to update public release versions.

13

Hi Jerry, how important of nv-l4t-bootloader-config.service during OTA upgrade?
I see if upgrade from 35.5 to 36.3, we have a function that use nv-l4t-bootloader-config.sh from 36.3 to run before OTA upgrade happens

14

hello anhhao.hcmus,

it checks partition layout, to see if need to update QSPI partitions.

it’s suggest to follow the steps (in the doc) for moving from 35.5 to 36.3

16

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