Assertion issue
I follow this post, apply patch in my 35.6.0(5.1.4) modules.
Some modules are reflashed with patch, and some are not.
I try Image-Based OTA update 36.4.3(6.2) on them. Ota payload package is include boot and rootfs.
I get different results!
Original 35.6.0(5.1.4) modules are successed 36.4.3(6.2).
Patched modules are failed.No progress show out in screen, and finally stop in shell.
I also find the nvme is 36.4.3(6.2) already. And it can work with other 36.4.3(6.2) module.
And no “/ota_log” dir in nvme.
But the patched modules boot are still in 35.6.0(5.1.4).
I tried replace tos-img when generate Ota payload package. But it doesn’t work.
How to solve this problem.
hello xiaokerui,
may I also know what’s your board authentication types, for instance, did you enable disk encryption?
besides, why you need to apply the patches manually since the latest JP-6 (i.e. JetPack 6.2/r36.4.3) has the fixes included.
No disk encryption. No internet access.
Many applications associated install in nvme. At first, I just reflash the assertion issue modules with patch to solve this problem. And there’s no need to upgrade the entire system and reinstall all the applications.
Consider future upgrade, I try to update the modules by ota package, and keep all the applications and user config. But it failed.
The original modules can update success, but the applications and user config lost.
Is there a method that can both upgrade and keep user configurations.
hello xiaokerui,
but.. how you perform remote update without internet access?
I can put the package into the local FTP server, or USB storage device. Then download or copy into the nvme.
All attempts are aimed at updating modules boot and nvme, keeping all applications and user configs.
hello xiaokerui,
did you have error logs for reference?
please see-also Topic 332530 to check whether it’s due to incorrect storage types.
I connect serial console, get the log.
ota-succ.txt (456.3 KB)
ota-fail.txt (147.3 KB)
The main differ in succ log is "Update Progress - 100% " ,and then “Shutdown state requested”.
The failed log Shutdown state requested immediate.
Jetson UEFI firmware (version 6.0-37391689 built on 2024-08-28T08:47:11+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
Update Progress - 100% **************************************************����Shutdown state requested 1
Rebooting system …
hello xiaokerui,
may I know what’s the difference of those ota-succ.txt (456.3 KB) and ota-fail.txt (147.3 KB)? were they based-on different hardwares?
FYI, updating the bootloader is executed in UEFI. once updating rootfs is finished, the device reboots, and then UEFI updates the bootloader through UEFI capsule update.
you may apply debug version UEFI binary to gather more details of the failure use-case.
Same Orin NX modules.
Success log is original 35.6.0(5.1.4) boot.
Fail log is 35.6.0(5.1.4) boot replaced tos-img with assertion issue patch.
hello xiaokerui,
may I know your steps for building STMM?
for instance, please refer to Topic 317579, Post #21 for reference.
I follow the Assertion issue post. And the atf_and_optee_README.txt steps.
- unpack atf and optee code, docker clone env.
- apply the patch.
- edk2-nvidia/Platform/NVIDIA/StandaloneMmOptee/build.sh build stmm(images/uefi_StandaloneMmOptee_RELEASE.bin)
- ./optee_src_build.sh -p t234 build optee/build/t234/core/tee-raw.bin
- dtc -I dts -O dtb -o ./optee/tegra234-optee.dtb ./optee/tegra234-optee.dts
- ./nvbuild.sh build atf/arm-trusted-firmware/t234-t234/tegra/t234/release/bl31.bin
- ./gen_tos_part_img.py
–monitor $ATF_IMG
–os $TEE_RAW
–dtb $TEE_DTB
–tostype optee
./patched-tos.img
Use the patched-tos.img replace the tos-img file in bootloader dir, then flash orin nx qspi.
Hi xiaokerui,
Do you export UEFI_STMM_PATH with the image you built(uefi_StandaloneMmOptee_RELEASE.bin) before you build OP-TEE source here?
Have you verified if the patch has been applied correctly after you run the command to flash?
If so, you can try to perform capsule update to apply the change instead.
It seems from JP6.2(r36.4.3).
And this is from JP5.1.4(r35.6.0).
Do you want to perform OTA update from r35.6.0(w/o fix) to r36.4.3(with fix)?
If so, you don’t need to apply the patch manually.
You can simply perform the image-based OTA update(from r35.6.0 to r36.4.3) since the fix has been included in JP6.2(r36.4.3).
Have you confirmed if the OTA failed is caused from the patch?
If so, you can simply use flash command to update them to JP6.2(r36.4.3).
I export the UEFI_STMM_PATH with the images/uefi_StandaloneMmOptee_RELEASE.bin (built in docker), before building tee-raw.bin.
I follow the verify steps in assertion issue post. And check the op-tee build time string in serial console log.
These two ota logs are both form r35.6.0. Only original r35.6.0 orin nx modules boot can update.
Now, all the modules in use are r35.6.0. Some modules with assertion issue return to me. I only can reflash the same verion with patch on these modules boot qspi. If I reflash other version and return back, they can’t work with the external nvme(r35.6.0).
Consider future update, So I try to update the modules by ota package many times.
From these two ota log, I can sure that the patched r35.6.0 boot modules can not go into update progress.
Are there any check here blocked the update process from continuing?
Could you elaborate on this? Are you saying that flashing the module with r36.4.3 could result in a boot failure from the NVMe SSD?
It is the expected result that it triggers the reset when bootloader update is completed.
It seems the issue caused from the following part in ota-fail.txt.
It does not perform the update for bootloader so that UEFI still shows version 6.0-37391689
Jetson UEFI firmware (version 6.0-37391689 built on 2024-08-28T08:47:11+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
â–’â–’â–’â–’Shutdown state requested 1
Rebooting system ...
â–’â–’
Please use debug UEFI binary and share the full serial console log for further check.
Do you check the OP-TEE version/date as following to clarify it is patched?
I/TC: OP-TEE version: 3.22 () #2 Thu Apr 24 17:39:08 UTC 2025 aarch64
Have you confirmed that you used the correct OP-TEE source for r35.6.0 when you were updating tos image?
I mean only update modules r36.4.3, but external nvme ssd still r35.6.0.
This result in boot failure.
About OP-TEE version/date string, there are indeed differences in gcc version. Why?
fail: (with patch I build)
I/TC: OP-TEE version: 3.22 () #2 Thu Apr 24 17:39:08 UTC 2025 aarch64
succ: (original)
I/TC: OP-TEE version: 3.22 (gcc version 9.3.0 (Buildroot 2020.08)) #2 Wed Aug 28 08:55:22 UTC 2024 aarch64
OP-TEE source code are unpack from public_source(r35.6.0), nvidia-jetson-optee-source.tbz2 file.
About debug UEFI bin, how to build and replace, then flash?
Okay, it is also the expected result since they are from different codebase. (R35 and R36).
Please refer to the steps in Build with docker · NVIDIA/edk2-nvidia Wiki · GitHub to build UEFI source and use uefi_Jetson_DEBUG.bin to replace <Linux_for_Tegr>/bootloader/uefi_jetson.bin.
uefi_debug_ota_fail_log.txt (382.1 KB)
I rebuild a uefi debug version, and get more info form the log.
Jetson UEFI firmware (version 202210.5-Unknown built on 2025-05-20T01:49:09+00:0
0)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
Failed to find memory test protocol
FmpDxe(NVIDIA System Firmware): CheckTheImage() - FmpDeviceLib CheckImage failed. Status = Not Ready
FmpDxe(NVIDIA System Firmware): SetTheImage() - Check The Image failed with Not Ready.
HandleCapsules: capsule update complete, resetting ...
▒▒▒▒Shutdown state requested 1
Rebooting system ...
▒▒
Something wrong in FmpDxe when check the image. How to fix it?
How did you clone the source for UEFI?
From the log you shared, it seems the capsule payload is not expected.
edkrepo clone $EDK2_BUILD_ROOT NVIDIA-Platforms r35.6.0
The same ota payload pkg updates successfully on r35.6.0 modules without tos img patch.
I reveiw the source code.
TegarFmp.c: L1354
if (!mFmpLibInitialized) {
*ImageUpdatable = IMAGE_UPDATABLE_INVALID;
*LastAttemptStatus = LAS_ERROR_FMP_LIB_UNINITIALIZED;
return EFI_NOT_READY;-------------> "Status = Not Ready"
}
VOID
EFIAPI
FmpDeviceFwImageCallback (
VOID
)
{
EFI_STATUS Status;
if (mTegraVersionStatus == EFI_UNSUPPORTED) {
Status = GetVersionInfo ();
if (!EFI_ERROR (Status)) {
mFmpLibInitialized = TRUE; -------------> // something error before
} else if (Status == EFI_NOT_FOUND) {
return;
}
}