hello rd1,
assume device still able to enter forced-recovery mode.
you may enable odmfuseread.sh
, to read the fuse info from the target board.
thanks
hello rd1,
assume device still able to enter forced-recovery mode.
you may enable odmfuseread.sh
, to read the fuse info from the target board.
thanks
how to enable odmfuseread.sh ,we didn’t find it in our code
I download the newest tools, didn’t find the file odmfuseread.sh
hello rd1,
sorry, odmfuseread.sh
it only supports Jetson TX2 series and Jetson Xavier series platforms so far.
Hi Jerry:
I used “sudo ./odmfuse.sh --noburn -i 0x21 -c PKC -p -k rsa_priv.pem” to generate efuse blob,
and then used"sudo ./fusecmd.sh" to burn efuse blob ,it is successful , but I try to flash no signed image ,however it unexpectedly flashed ok,
after boot.I checked “sudo ./tegrafuse.sh”
It return:
arm_jtag_disable : 0x00000000
odm_lock : 0x00000000
odm_production_mode : 0x00000001
pkc_disable : 0x00000001
sec_boot_dev_cfg : 0x00000000
sec_boot_dev_sel : 0x00000000
I see odm_production_mode had changed 1, but pkc_disable is not 0, I think it should 0.
what is the problem?
hello rd1,
may I know which JetPack release and which secureBoot package you’re working with?
Hi Jerry:
I had update our secureboot package ,please help to check the problem.
hello rd1,
could you please share your TNSPEC of your board, i.e. $ cat /etc/nv_boot_control.conf
there’s known issue that pkc_disable
fuse is programmed to 0x1 with -p
option enabled.
please also check Topic 144888 to download nvtboot binaries to correct the issue for fuse burn.
thanks
hello rd1,
is this a duplicate issue with Topic 173794 Flash failed after burnned efuse?
please check post #3 for the suggestions to handle your efuse/no efuse scenarios.
let’s keep Topic 173794 for tracking device disconnected issue for further supports.
thanks
Hi Jerry:
$ cat /etc/nv_boot_control.conf
TNSPEC 3448-400-0002–1-0-jetson-nano-emmc-smpsq-mmcblk0p1
TEGRA_CHIPID 0x21
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
I see Topic 14888, you mean we should:
hello rd1,
you should have flashing environment for JetPack release image,
please update those nvtboot*.bin binaries with the attachment.
for example,
$OUT/Linux_for_Tegra/
./bootloader/nvtboot_recovery.bin
./bootloader/nvtboot_cpu.bin
./bootloader/nvtboot_recovery_cpu.bin
./bootloader/t210ref/nvtboot.bin
BTW,
if you’re installing the latest JetPack release, (i.e. JetPack-4.5) it will already include those nvtboot fixes.
thanks
thank you Jerry,
I download these files,and if we generate fuse blob ,shoud we use -p or not use -p?
you mean our JetPack is old ,te old JetPack had the bug of pkc_disable fuse not programmed to 0x1 used the same method “-p” ?
hello rd1,
there’s an issue with fusing utility, which burn PKC Disable accidently. you should apply nvtboot fixes to address them.
this is a bug for the early JetPack releases on the Nano platform, (i.e. before JetPack-4.5).
it’s up to your decision after you’d include the fix.
note, program fuse is non-reversible. Once odm_production_mode (-p
options) is fused with value of 0x1, all further fuse write requests are blocked.
thanks
thank you, the corrcet PKC Disable efsue value is 0 or 1 for T210?
For T210,
±------±--------------------±----------------------------------+
|bitsize| name | default value set by odmfuse.sh |
±------±--------------------±----------------------------------+
| 1| odm_production_mode | 0x1 |
| | | |
| 256| public_key_hash | RSA Public Key Hash |
| | | |
| 1| pkc_disable | PKC - 0x0, NS - 0x1 |
| | | |
| 128| secure_boot_key | Secure Boot Key (SBK) |
| | | AES encryption key for other |
| | | security applications. If no |
| | | other security application is |
| | | used, leave it untouched. |
| 32| device_key | Device key for other security |
| | | applications. If no other |
| | | security applications are |
| | | used, leave it untouched. |
±------±--------------------±----------------------------------+
I mean if we used “sudo ./odmfuse.sh -i 0x21 -c PKC -p -k rsa_priv.pem” to burn efuse,
then after boot,used “sudo ./tegrafuse.sh” to check.
the pkc_disable should 0x00000001 or 0x00000000, I am puzzled for this.
hello rd1,
to clarify, there’s a bug when enable -p
options, it burn pkc_disable accidently.
so,
for the correct fuse process. $ sudo ./odmfuse.sh -c PKC
, it should program pkc_disable=0x0
note, nvtboot fixes should be applied before verify this.
it’s -c PKC
to program pkc_disable fuse, so it should be pkc_disable= 0x0
.
the -p
options to program odm_production_mode fuse bit, it’ll be odm_production_mode=0x1
when enabled.
thanks
ok ,thank you very much!