Hello, I have two questions about TX2 NX.
- In the URL below, “Support flashing, available as a different mb1_recovery.bin binary”, I cannot understand about it. What kind of function is it?
- Is it possible to create a carrier board implemented with SPI Flash and boot with the data stored in SPI Flash on the carrier board?
We are considering using secure SPI Flash to protect the FW, detect anomalies, and recover from it on the SPI Flash side. So I would like to know if Jetson can boot with SPI Flash data on the carrier board.
It is unlikely to support what you want.
Actually, mb1 is not opened for public customization.
Custom changes may only start from cboot.
Thank you, I understand that it is impossible to boot from SPI Flash on the carrier board.
Can you answer the questions below?
In the URL below, “Support flashing, available as a different mb1_recovery.bin binary”, I cannot understand about it. What kind of function is it?
please check the flow chart, MB1 is the first boot code and can be viewed as an extension of BootROM to provide more flexibility of boot support.
you’ll see different mb1 binaries if you look into JetPack installation path, i.e.
$OUT/Linux_for_Tegra/bootloader/. one is used while you’ve putting device enter RCM, there’ll output logs if you setup serial console and flashing the target; in the other hand, the other one is the mb1 binary that flashed to mb1 partition, that handles the cold-boot.
Thnak you som much. I have four additional questions.
If the verification result of MB1 is Fail using Secure Boot, can later FW (for example, MB2, Cboot, etc.) be detected? Or does it stop when MB1 fails?
Also, if the above is possible, is it possible to implement a mechanism to flash with MB1 data for recovery stored elsewhere, such as SPI flash on the carrier board?
3.Can I save MB1 data for recovery in Jetson?
4.We want to realize Chain Of Trust. (BootRom verifies MB1 → MB1 verifies MB2 → MB2 verifies the next FW) If possible, where are the FW that need to be customized to achieve?
BootROM validates MB1: NVIDIA prepares or needs customization
MB1 validates MB2: NVIDIA prepares or needs customization
MB2 validates Cboot: NVIDIA needs preparation or customization)
let’s say your board is fused and signed with PKC, here’s Secureboot to prevent execution of unauthorized code during boot process through chain of trust. The root-of-trust is on-die bootROM code that authenticates boot components such as BCT (boot configuration table), Bootloader, and warmboot vector etc. using Public Key Cryptography (PKC) keys stored in fused device. you may further use SBK for encryption.
hence, you don’t need firmware customization. please assign keys to sign (PKC) or sign+encrypt (PKC+SBK) the target.
please check developer guide, Jetson Security for the features of Secureboot and TrustyOS.
you may also refer to Tutorials page for the training video, Jetson Security and Secure Boot.
Tahnk you so much! I have three additional questions about boot.
Is there a way to check the MB1 authentication result by secure boot?
Which media (eMMC, USB, SSD, SD, etc.) can the a / b root file system be placed on?
Can MB1 be placed on different media?
How can I specifically use the mb1_recovery.bin binary? Do you have an instruction manual?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.