Jetson Nano Production integrity check after flashing

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
,
1

Hi,

I was wondering if there is a way to check the eMMC integrity after the flashing process, i.e. is there a way to validate the images written to the eMMC are correct via a checksum validation?

  1. I believe (correct me if I am wrong) that during the flashing process in the RCM boot mode, the initial ramdisk image used for flashing, validates the checksum of the binaries before flashing them to the eMMC. Is this correct?

  2. If #2 is correct, is there any post flashing integrity validation to ensure the partitions are flashed properly?

  3. My understand is that the initram image used for RCM boot is different from the initrd image commonly used (l4t_initrd), is there a way to modify the RCM initram image to modify or add additional recovery/installation steps during the flashing process? Is this image the nvtboot_recovery.bin file?

Thanks in advance!

Best Regards,
-Marco

3

hello MarcoMadrigal,

may I know what’s the use-case for checking images written to the eMMC after the flashing process?
assume you had enable Secureboot feature, those bootloader binaries must be signed and encrypted with the keys you’d burn to the platform.
thanks

4

Hi @JerryChang,

Thanks for your reply. The idea is to validate that the eMMC flashing process finishes correctly and the images on the eMMC (u-boot, cboot, bct, dtb, and mostly all the 40 partitions and extra partitions are written with no errors).

I read on the below document that the flashing process might validate the checksum for every image within the ramdisk before writing it to the eMMC, does this apply nowadays for the latest flashing process?

The ultimate goal is to provide feedback at the production level on whether each device is flashed correctly and the integrity of the images is correct, without needing each device to be booted.

Secureboot is useful, but it might not provide this feedback at flashing time during production for every image. Its goal is more for security purposes.

From my questions above and based on that document and your answer, might I assume the following answers are correct?

  1. Yes, based on the document a pre-validation of the images is performed prior to flashing the eMMC
  2. No, there is not post-flashing verification of the integrity of the eMMC

Still, for #3 I have no clues yet, based in the tegraflash output it looks like nvtboot_recovery.bin is the ramdisk image used during the flashing process and should match the old reference (from de document) of the mb1_recovery_prod.bin. Is there a way to regenerate this ramdisk?

Thanks in advance!

-Marco

5

Just a thought, never tested this, but if you were to flash with the option to not delete the signed files on the host side (which probably applies to every directory except the rootfs/APP), then you could check the sha1sum of each of the signed partitions. Then, on the Jetson, you could use dd to go through each partition (other than APP) and compare checksums.

Example from the Jetson:
dd if=/dev/mmcblk0p2 | sha1sum

The rootfs is problematic because it has metadata about mount counts, and temporary files change additional content as soon as you boot. During a flash the Jetson will automatically reboot at the end of the flash, and so you could not even rely on a clone of rootfs/APP for checksum purposes.

7

Hi @linuxdev,

Thanks for commenting! Despite I haven’t tried that neither I agree it is an option, however it requires the system to be up and running and someone to verify that from the Jetson. I was wondering o a method a little bit more production oriented, like running the same validation steps you are suggesting from the ramdisk used during the flashing process. As per the document provided above it should be feasible but obviously it requires to regenerate the ramdisk used during flashing.

Comparing the document with the current tegraflash behavior it looks like the process is quite different and some things like the ACM link are not valid anymore. There is very little information about the flashing process or how to access the ramdisk which I assume is intentional to avoid a total chaos out there.

I know the document is not NVIDIA official and is quite old but it really provides a good insight of what is going on.

Any input from @JerryChang would be also much appreciated.

Best Regards,
-Marco

8

Hi @MarcoMadrigal did you find a solution to check the integrity of the flashed image? I would like to do the same on the Xavier NX, because I would like to guarantee that the image flashed is the same is not corrupted, i.e by verifying the checksum with the image that I flashed.
Any suggestion is welcome.