# ASSERT FvbNorFlashStandaloneMm.c(978): ((BOOLEAN) (0==1)) **URL:** \ **Category:** Jetson Xavier NX\ **Tags:** uefi, boot, ota\ **Created:** [February 1, 2026, 5:29pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276 "2026-02-01T17:29:39Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 12, 2026, 6:38am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/42 "2026-02-12T06:38:16Z")
> [@KevinFFF](#): > > Do you mean that you used the _tos-optee\_t194.img_ from R35.6.4 BSP package for the BSP 35.6.0? 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. ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 12, 2026, 6:39am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/43 "2026-02-12T06:39:20Z")
> [@KevinFFF](#): > > Is this issue specific to your custom carrier board? (i.e. could you reproduce the similar issue on the devkit?) Yes, I will try and update … ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [February 12, 2026, 6:52am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/44 "2026-02-12T06:52:43Z")
> [@adit\_bhrgv](#): > > No, I mean when I updated to new BSP r35.6.4 and then didn’t recreated the tos\_t194.img, Could you check if there’s the similar issue if you update the board through image-based OTA update? > [@adit\_bhrgv](#): > > Yes, I will try and 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? ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 12, 2026, 2:15pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/45 "2026-02-12T14:15:16Z")
> [@adit\_bhrgv](#): > > > [@KevinFFF](#): > > > > Is this issue specific to your custom carrier board? (i.e. could you reproduce the similar issue on the devkit?) 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 ! ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 12, 2026, 2:26pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/46 "2026-02-12T14:26:58Z")
> [@KevinFFF](#): > > Thanks, we (and many users) don’t hit such assertion issue after applying the patch. did you test it with secureboot and disk encryption too ? ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [February 13, 2026, 12:45am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/47 "2026-02-13T00:45:59Z")
> [@adit\_bhrgv](#): > > The 2 boards failed after BL capsule is 100% complete and then encountered ASSERT issue Have you performed the similar steps again and check if it can be reproduced 100% on these 2 boards? > [@adit\_bhrgv](#): > > did you test it with secureboot and disk encryption too ? We didn’t verify them with secureboot and disk-encryption enabled. Could you also help to clarify if the issue is specific to them? ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 20, 2026, 1:53pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/48 "2026-02-20T13:53:37Z")
> [@KevinFFF](#): > > Have you performed the similar steps again and check if it can be reproduced 100% on these 2 boards? 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. ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 24, 2026, 9:58am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/49 "2026-02-24T09:58:04Z")
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](https://github.com/NVIDIA/edk2-nvidia/pull/110/commits) 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 . ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 24, 2026, 10:07am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/50 "2026-02-24T10:07:24Z")
> [@KevinFFF](#): > > For the board not yet hit the issue, both `applying the change manually+capsule update` and `updating to r35.6.4` would work to fix the issue. > For the board has been in failed state, the manual reflashing QSPI is required. As this is what you mentioned earlier ! ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 24, 2026, 1:32pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/51 "2026-02-24T13:32:20Z")
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 \/bootloader/standalonemm\_optee\_t194.bin is still old without patch. ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 24, 2026, 11:36pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/52 "2026-02-24T23:36:16Z")
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:** 1. 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? 2. 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? ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 25, 2026, 3:15pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/53 "2026-02-25T15:15:42Z")
> [@Updating TOS in Jetpack 6](https://forums.developer.nvidia.com/t/updating-tos-in-jetpack-6/302620/7): > > It seems you disable the assert when there is a non-erased variable integrity space. You can run the following command to check the status of capsule update. $ sudo nvbootctrl dump-slots-info Referring this post, I tried to disable reboot on Assert error but then my nvbootctrl status is something like this with slot 1 : unbootable: ```auto 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 : ```auto �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 �� ``` ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [February 26, 2026, 9:48am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/54 "2026-02-26T09:48:13Z")
@KevinFFF could you please suggest something to fix this ? ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [March 2, 2026, 7:28am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/55 "2026-03-02T07:28:03Z")
Hi adit\_bhrgv, Sorry for the late reply as there were the holidays and I was in vacation. > [@adit\_bhrgv](#): > > Unfortunately, I couldn’t verify the case without secureboot as all my boards are fused. 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. > [@adit\_bhrgv](#): > > 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 ? Yes, please also update the _bootloader/standalonemm\_optee\_t194.bin_ before generating capsule payload. > [@adit\_bhrgv](#): > > 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. Could you also try update from **r35.6.0** to the latest **r35.6.4** which should include all fixes for assertion issue? ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [March 2, 2026, 12:21pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/56 "2026-03-02T12:21:22Z")
> [@KevinFFF](#): > > 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. ! ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [March 2, 2026, 12:22pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/57 "2026-03-02T12:22:00Z")
> [@KevinFFF](#): > > Could you get a board to clarify if the issue is specific to secureboot/disk-encryption enabled? I’ll try to isolate that but meanwhile could you please also test the same with secureboot / disk encryption at your end ? ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [March 2, 2026, 1:03pm UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/58 "2026-03-02T13:03:54Z")
> [@adit\_bhrgv](#): > > ```auto > ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t194-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(978): ((BOOLEAN)) > > ``` > [@adit\_bhrgv](#): > > ```auto > 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 > > ``` 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 ! ---
**Author:** ![KevinFFF](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/kevinfff/32/15508_2.png) [@KevinFFF](https://forums.developer.nvidia.com/u/KevinFFF)\ **Post date:** [March 5, 2026, 9:06am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/59 "2026-03-05T09:06:06Z")
> [@adit\_bhrgv](#): > > could you please also test the same with secureboot / disk encryption at your end ? Sorry that I don’t have the fused Xavier NX module to verify this case currently. > [@adit\_bhrgv](#): > > 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) 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. ---
**Author:** ![adit\_bhrgv](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@adit\_bhrgv](https://forums.developer.nvidia.com/u/adit_bhrgv)\ **Post date:** [March 5, 2026, 9:12am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/60 "2026-03-05T09:12:25Z")
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 ! ---
**Author:** ![system](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/system/32/68080_2.png) [@system](https://forums.developer.nvidia.com/u/system)\ **Post date:** [March 23, 2026, 6:25am UTC](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276/62 "2026-03-23T06:25:29Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed. [Previous page](https://forums.developer.nvidia.com/t/assert-fvbnorflashstandalonemm-c-978-boolean-0-1/359276.md?page=2)