No, I mean when I updated to new BSP r35.6.4 and then didn’t recreated the tos_t194.img,
I didn’t build tos_t194.img myself but just used the one came with r35.6.4.
Yes, I will try and update …
Could you check if there’s the similar issue if you update the board through image-based OTA update?
Thanks, we (and many users) don’t hit such assertion issue after applying the patch.
May I also know how do you reproduce the assertion issue?
This issue seems to be specific to our custom carrier board from the same vendor. I tested on 6 boards, same Bootloader capsule works on 4 boards, but fails on 2 boards with ASSERT error.
FYI: All boards had functional R35.6.0 SW before I tried BUP capsule to update them to R35.6.4 version. The 2 boards failed after BL capsule is 100% complete and then encountered ASSERT issue
Could you please comment why this would likely be the case although all 6 boards are same ? Some boards encounter the ASSERT issue and others don’t ?
Only way to avoid the error on the 2 failing boards, is to first flash them with R35.6.4 massflash image(setting them in recovery mode) and then if I try capsule update from r35.6.4 → r35.6.4, then it works !
did you test it with secureboot and disk encryption too ?
Have you performed the similar steps again and check if it can be reproduced 100% on these 2 boards?
We didn’t verify them with secureboot and disk-encryption enabled.
Could you also help to clarify if the issue is specific to them?
yes 100% reproducible on these 2 boards.
This ASSERT issue comes only when I try to update the BSP R35.6.0 → R35.6.4 or even same BSP update R35.6.0.
If I try to update from BSP R35.4.1→ R35.6.0, then this ASSERT error doesn’t pop up.
Unfortunately, I couldn’t verify the case without secureboot as all my boards are fused.
Recently one of our another vendor board, also faced the same issue updating the rootfs and bootloader from BSP r35.6.0 to r35.6.0 (bootloader remains the same). The board had been flashed with Massflash image including QSPI and was running successfully.
Could you please update why this ASSERT occur in the first place when the QSPI state was OK ?
There were no VarStore or Measurement partition issues after applying the Massflash image. The assertion only occurred after attempting to apply the Bootloader Capsule update. The bootloader capsule was created with the new tos_optee_t194.img with the patch for Memory leak error.
Patch : Varint readfix r35.5.0 by gmahadevan · Pull Request #110 · NVIDIA/edk2-nvidia · GitHub
Switch to r35.6.0 uefi branch,merged this patch and then built tos.img using STMM image.
How can we resolve it remotely when this ASSERT error occurs ? As we just simply can’t bring the boards to flash QSPI manually in recovery mode .
As this is what you mentioned earlier !
While generating BUP capsule, I regenerated the tos image (and placed it in bootloader/ ) using standalonemm_optee_t194.bin generated by uefi , but do I also need to place standalonemm_optee_t194.bin in bootloader/ folder for generating BUP Capsule for it to write this image in secure_os partition ?
In summary, in bootloader folder , the tos.img is newly generated with patch but <Linux_for_Tegra>/bootloader/standalonemm_optee_t194.bin is still old without patch.
I am hitting an intermittent ASSERT [FvbNorFlashStandaloneMm] ... FvbNorFlashStandaloneMm.c(978) error on a Jetson Xavier NX (T194) after a UEFI Capsule update reaches 100% progress.
Environment:
-
Hardware: Xavier NX (T194)
-
L4T Version: R35.6.0
-
Security: Secure Boot (PKC+SBK) and Disk Encryption enabled.
The Issue:
When updating from R35.6.0 to R35.6.0 using a TEGRA_BL.Cap payload via OsIndications, the update often reaches 100% and reboots, but then hits the VarIntValidate ASSERT.
I have applied the official patch to FvbNorFlashStandaloneMm.c (to handle VAR_INT_PENDING and set RecommitRec = TRUE), but the issue persists intermittently when the version number remains unchanged.
Questions for NVIDIA Support:
-
Does the UEFI Capsule manager skip critical Variable Store migration/re-initialization logic if the incoming Capsule version is identical to the currently active version?
-
Is a version bump (e.g., to r35.6.x from r35.6.0) required to force the UEFI to execute the “self-healing” logic added by the patch?
Referring this post, I tried to disable reboot on Assert error but then my nvbootctrl status is something like this with slot 1 : unbootable:
sudo nvbootctrl dump-slots-info
Current version: 35.6.0
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0, status: normal
slot: 1, status: unbootable
Serial boot logs bypassing ASSERT error :
�I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
UpdatePeCoffPermissions: Mapping section 1 of image at 0x406FC000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x000406F5000 EntryPoint=0x000406F8D84 NorFlashStandaloneMm.efi
MmInstallProtocolInterface: 989B8BE1-18FC-430D-9A4C-2907F2A728DD 40701630
UpdatePeCoffPermissions: Mapping section 1 of image at 0x406F2000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x000406E6000 EntryPoint=0x000406EC6F8 FvbNorFlashStandaloneMm.efi
FVBNORInitialize:Using Reserved Partition 33226752 65536 for VarStore Integrity
MmInstallProtocolInterface: 49DAE0B5-7994-4A9F-A129-3D19898EE913 406C5F90
MmInstallProtocolInterface: D326D041-BD31-4C01-B5A8-628BE87F0653 40701050
MmInstallProtocolInterface: D326D041-BD31-4C01-B5A8-628BE87F0653 407010D8
MmInstallProtocolInterface: D326D041-BD31-4C01-B5A8-628BE87F0653 40701160
MmInstallProtocolInterface: D1A86E3F-0707-4C35-83CD-DC2C29C891A3 0
UpdatePeCoffPermissions: Mapping section 1 of image at 0x4069D000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x00040697000 EntryPoint=0x0004069A698 OpTeeRpmbFvNv.efi
UpdatePeCoffPermissions: Mapping section 1 of image at 0x4067D000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x00040674000 EntryPoint=0x00040679938 FaultTolerantWriteStandaloneMm.efi
MmInstallProtocolInterface: 3868FC3B-7E45-43A7-906C-4BA47DE1754D 40663020
UpdatePeCoffPermissions: Mapping section 1 of image at 0x40660000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x00040657000 EntryPoint=0x0004065C8B4 FwPartitionStandaloneMm.efi
UpdatePeCoffPermissions: Mapping section 1 of image at 0x40654000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x0004064B000 EntryPoint=0x000406506BC NorFlashStandaloneMmDice.efi
IsNorFlashDeviceSupported:Device with Manu 0x01 MemType 0x02 Density 0x19 isn't supported
UpdatePeCoffPermissions: Mapping section 1 of image at 0x40648000 with RW-XN permissions and size 0x1000
Loading MM driver at 0x00040643000 EntryPoint=0x00040645D28 StandaloneMmCpu.efi
MmInstallProtocolInterface: 26EEB3DE-B689-492E-80F0-BE8BD7DA4BA7 406480A8
UpdatePeCoffPermissions: Mapping section 1 of image at 0x40616000 with RW-XN permissions and size 0x28000
Loading MM driver at 0x0004055F000 EntryPoint=0x00040566A08 VariableStandaloneMm.efi
MmInstallProtocolInterface: ED32D533-99E6-4209-9CC0-2D72CDD998A7 40616940
Var SecureBoot Doesn't exist Not Found
Var PK Doesn't exist Not Found
Var KEK Doesn't exist Not Found
Var db Doesn't exist Not Found
Var dbx Doesn't exist Not Found
VarIntValidate:ERROR Failed to match Stored Measurement with computed.
VarIntValidate: FAILED TO VALIDATE
MmFvbSmmVarReady:Var Store Validation failed Device ErrorMmFvbSmmVarReady: Corrupting FV Header
MmInstallProtocolInterface: B0D8F3C1-B7DE-4C11-BC89-2FB562C8C411 40616918
��
@KevinFFF could you please suggest something to fix this ?
Hi adit_bhrgv,
Sorry for the late reply as there were the holidays and I was in vacation.
Could you get a board to clarify if the issue is specific to secureboot/disk-encryption enabled?
We have not verified this case as we use non-fused module and there’s no assertion issue after capsule update.
Yes, please also update the bootloader/standalonemm_optee_t194.bin before generating capsule payload.
Could you also try update from r35.6.0 to the latest r35.6.4 which should include all fixes for assertion issue?
I tried that and still it gives the same ASSERT error. !
I’ll try to isolate that but meanwhile could you please also test the same with secureboot / disk encryption at your end ?
I suspect the error could be in “auth_t194.key” .
Before capsule update, the already running version on jetson was having eks.img with all zeros auth_t194.key but now the capsule uses eks.img which is created with another “auth_t194.key” (non-zeros, random hex key)
Do you think this could be the reason for this variable integrity mismatch ?
I will try to make the same auth_t194.key and update this post !
But still I wonder, why it fails only on some boards and not all, if the auth_t194.key is the probable culprit !
Sorry that I don’t have the fused Xavier NX module to verify this case currently.
Based on your latest logs, this instance looks different from the earlier VarInt/leak issue we fixed and is very likely caused by the auth_t194.key change. The stored variable measurement in QSPI was created with the old (all‑zero) key, but the new firmware is now validating it with a different key, so VarIntValidate correctly reports “Failed to match Stored Measurement with computed” and triggers the assert. If you rebuild eks.img using the original auth_t194.key and the assert disappears on the same board, that will confirm the root cause. Long‑term, all boards need to use a single, consistent auth_t194.key (or be fully reflashed, including QSPI/eks, when changing keys) so that the stored measurements and the active key always match.
1 Like
Yes, I verified at my end and re-created the capsule with same eks.img with same “auth_t194.key” and now the ASSERT error is gone. I think this was the problem.
Thanks for your support as always !
1 Like