We have been making cameras using the Orin Nano 8GB SOM with Micron DRAM (D8BFW).
We run this script “burn_fuses.sh” which basically runs odmfuse.sh -i 0x23 -k rsa.pem -S sbk.key -X fuse.xml jetson-orin-nano-devkit while connecting our target SOM to NVIDIA’s Orin Nano Dev Kit.
After that, then we run “flash_som.sh” which basically runs sudo ROOTFS_AB=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 -u rsa.pem -v sbk.key -i sym2_t234.key -p “-c ./bootloader/t186ref/cfg/flash_t234_qspi.xml” --show-logs jetson-orin-nano-devkit internalwhile the target SOM is still on NVIDIA’s Orin Nano Dev Kit.
Things have been ok with this hardware.
However we recently obtained Orin Nano SOMs with Samsung DRAM, as noted in PCN210361. Because we are running L4T 35.5.0, we should already have the necessary files (BCT, DVFS, etc) already in the “Linux_for_Tegra” environment. We can run “burn_fuses.sh” successfully, but then “flash_som.sh” terminates early. Please look at the attached log file for terminal logs.
Can you please help us troubleshoot this issue? We are doing the same operations, but for some reason they are not working with SOMs that have Samsung DRAM. Have you had trouble burning fuses to SOMs with Samsung DRAM?
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, I’ll try to help you troubleshoot the issue.
Summary of the issue:
You’re experiencing problems with burning fuses to Jetson Orin Nano SOMs with Samsung DRAM (PCN210361) using the burnfusessh and flashsomsh scripts. The same scripts work fine with SOMs that have Micron DRAM.
Possible causes:
DRAM type incompatibility: Although you’re running L4T 35.50, which should have the necessary files for Samsung DRAM, it’s possible that there’s an incompatibility issue between the DRAM type and the firmware.
Firmware version mismatch: Ensure that the firmware version on the Orin Nano Dev Kit is compatible with the Samsung DRAM SOMs.
Script or configuration issue: There might be a problem with the burnfusessh or flashsomsh scripts, or the configuration files used by these scripts.
Troubleshooting steps:
Verify firmware version: Check the firmware version on the Orin Nano Dev Kit and ensure it’s compatible with the Samsung DRAM SOMs.
Check script and configuration files: Review the burnfusessh and flashsomsh scripts, as well as the configuration files used by these scripts, to ensure they’re correct and compatible with the Samsung DRAM SOMs.
Compare logs: Compare the terminal logs from the successful burn and flash operations with the Micron DRAM SOMs to the logs from the failed operations with the Samsung DRAM SOMs. This might help identify any differences or errors.
Try a different flash method: If possible, try using a different flash method, such as the flash.sh script, to see if the issue persists.
Additional information:
The burnfusessh script is used to burn fuses to the SOM, while the flashsomsh script is used to flash the SOM.
The flash.sh script is a more comprehensive flash script that can be used as an alternative to flashsomsh.
Comparison with other modules:
The issue seems to be specific to the Jetson Orin Nano SOMs with Samsung DRAM.
Other modules, such as the Jetson AGX Orin, might not be affected by this issue.
If none of these troubleshooting steps resolve the issue, it may be helpful to provide more information about the error messages or logs from the failed operations.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
please double check your fuse.xml file,
please refer to Jetson Orin Series Modules Fuse Update Field Services Bulletin for the details of FUSE_BOOT_SECURITY_INFO_0 fuse for ALL Jetson Orin Series Modules.
the fuse value for boot_security_info was burned (by manufacturing) to 0x1E0.
you must bitwise logically OR the desired value with 0x1E0 in the fuse programming flow.
Can you explain to me why NVIDIA has changed the “Fuse Boot Security Info” fuse?
I imagine this has caused a lot of issues with customers when you change these bits, so what is the benefit of it?
FUSE_BOOT_SECURITY_INFO_0
…
Bits [8:4] Reserved (may not be logic 0 by default)
for instance,
assume your BOOT_SECURITY_INFO should be 0x209 per your key combination.
you should program this fuse variable to 0x3E9 (an OR of 0x209 and 0x1E0) for your use-case.
it’s okay for those 0x0 or 0x1E0 modules, you may program boot_security_info as 0x3E9 to them directly since it’s the “Reserved” fuse variable.
Hi Jerry, suppose we deployed old SoM with BOOT_SECURITY_INFO 0x209 and now we’re deploying new SoM with 0x3E9 all same RSA and SBK key. I’m thinking would it be fine if one OTA package using for both SoM?
this is a good question, you should have two OTA payloads for this scenario, ideally.
however, you may give it a try since during the flashing process, it will also check board authentication status via BOOT_SECURITY_INFO.
for instance, there’re NS (not fused with PKC or SBKPKC), PKC (previously fused with PKC only), and SBKPKC ( previously fused with PKC and SBK), it’s reported from Bits [3:0] of BOOT_SECURITY_INFO. it should not check reserved bits for image flash/update.
you may put the device into forced-recovery mode for fuse read,
here’s an example, $ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>