My device is the custom jetson agx orin, jetpack 5.1.3.
It showed some boot bugs, which seem to be fixed in the new version UEFI, i.e. jetpack 5.1.5.
I compared these patchs to my current UEFI sources code (nvidia-uefi-R35.5.0-updates), and there are some other changes except for the labeled fixed parts. I’m not sure if modifying the source code based on the current version one will cause unstable issues.
Can I use the new version UEFI sources code on old jetpack? like nvidia-uefi-R36.2.0-updates.
Or, restore the old backup system.img in the new version jetpack？
Which is more reliable？
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, I’ll address your concerns and provide a comprehensive answer.
Background
You’re experiencing boot bugs on your custom Jetson AGX Orin device with Jetpack 5.1.3, which seem to be fixed in the newer version of UEFI (Jetpack 5.1.5). You’ve found a post discussing possible fixes for assertion issues in UEFI during boot, but you’re unsure about applying the patches to your current UEFI sources code (nvidia-uefi-R35.5.0-updates).
Concerns
Applying patches to the current UEFI sources code: You’re hesitant to modify the source code based on the current version, as there are other changes except for the labeled fixed parts. You’re worried that this might cause unstable issues.
Using the new version of UEFI sources code on old Jetpack: You’re considering using the newer UEFI sources code (nvidia-uefi-R36.2.0-updates) with your old Jetpack version (5.1.3).
Restoring the old backup system.img in the new version Jetpack: You’re wondering if restoring the old backup system.img in the new version Jetpack (5.1.5) is a more reliable option.
Analysis
Applying patches to the current UEFI sources code: While applying patches to the current UEFI sources code might fix the assertion issues, it’s true that there are other changes in the newer version. This could potentially introduce new issues or instability. However, if you’re comfortable with the changes and have a good understanding of the code, this might be a viable option.
Using the new version of UEFI sources code on old Jetpack: Using the newer UEFI sources code with your old Jetpack version might not be the best approach. The newer UEFI code is likely designed to work with the newer Jetpack version (5.1.5), and there might be compatibility issues or dependencies that aren’t met with the older Jetpack version.
Restoring the old backup system.img in the new version Jetpack: Restoring the old backup system.img in the new version Jetpack (5.1.5) is likely the most reliable option. This approach ensures that you’re using a known good configuration with the newer Jetpack version, which should include the fixes for the assertion issues.
Recommendation
Based on the analysis, I recommend restoring the old backup system.img in the new version Jetpack (5.1.5). This approach provides the best balance between reliability and fixing the assertion issues. If you’re not comfortable with this approach or want to explore other options, you can try applying the patches to the current UEFI sources code, but be cautious of potential instability.
Additional Considerations
Before making any changes, ensure that you have a backup of your current system and configuration. This will allow you to revert to a known good state if issues arise.
If you decide to use the newer UEFI sources code with your old Jetpack version, thoroughly test your system to ensure that there are no compatibility issues or unexpected behavior.
In summary, restoring the old backup system.img in the new version Jetpack (5.1.5) is the most reliable option, but you can also consider applying patches to the current UEFI sources code if you’re comfortable with the changes.
What’s the exact assertion issue you hit?
Please share the full serial console log for further check.
No, R35.x and R36.x are from different release so that you can not do this.
You can try using r35.5.0-updates branch from UEFI source to check if it could help for your case.
In addition, most of the assertion issue we found is fixed in tos image so that I suppose you should also update tos image for A/B_secure-os partition.
Hi KevinFFF,
I decided to upgrade the system as a whole to Jetson Linux 35.6.2.
I pulled the UEFI source code r35.6.2-updates, and I noticed that the patch for Assertion 3 hasn’t been updated.
To prevent this Assertion 3, I need to update this patch in my source code r35.6.2-updates, then rebuild the tos-optee_t234.img, all right?
It is Assertion 2. ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/FvbNorFlashStandaloneMm.c(868): ((BOOLEAN)(0==1))
By the way, I also checked source code of r35.5.0-updates and r35.6.0-updates. There are many differences between the two. I’m using branch r35.5.0-updates, is it possible to fix those problems directly on that?
If it’s possible, please tell me which part needs to be modified, thanks a lot.
Since you are using Jetpack 5.1.3, I would suggest you using r35.5.0-updates branch to prevent unexpected error.
Please note that the fix is included in tos image rather than uefi binary.
The key point is to apply the fix and build uefi_StandaloneMmOptee_RELEASE.bin, which is required before you built op-tee.