Experiment changing from config2 to config5 hangs my boot with a UTMP error

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hi this is kind of an odd one…

Situation: I can deploy the original config2 L4T to my (custom) Tx2i carrier. Attempting to deploy my config5 modifications breaks the deploy process. So when I saw a recent post about signing the various materials that went in the partitions I decided to try an experiment. (Note: I can deploy the config5 system on the nvidia developer carrier.)

The experiment:
A. deploy the original config2 L4T system on a TX2i module (using the nvidia carrier) and use dd to capture all the partitions (except mmcblk0p1, the APP partition)
B. deploy my modified L4T config5 system on a TX2i module (using the nvidia carrier) and use dd to capture all the partitions (except mmcblk0p1).

Note that the Jetson Flash routines were used so that all captured partitions are correctly signed. Both modules can boot in either the nvidia or custom (config5) carrier. But some hardware does not work in the mismatched cases.

I used diff to determine that my changes modified the following partitions:

Binary files ../mmcblk0boot0 and ./mmcblk0boot0 differ
Binary files ../mmcblk0boot1 and ./mmcblk0boot1 differ
Binary files ../mmcblk0p26 and ./mmcblk0p26 differ
Binary files ../mmcblk0p27 and ./mmcblk0p27 differ
Binary files ../mmcblk0p28 and ./mmcblk0p28 differ
Binary files ../mmcblk0p29 and ./mmcblk0p29 differ
Binary files ../mmcblk0p6 and ./mmcblk0p6 differ
Binary files ../mmcblk0p7 and ./mmcblk0p7 differ

I then used dd to copy the modified config5 partitions on the TX2i programmed with config2.

Use the following to enable writing for the boot partitions:
echo 0 > /sys/block/mmcblk0boot0/force_ro
echo 0 > /sys/block/mmcblk0boot1/force_ro
and remember to set it to 1 after writing...

The mystery: After doing this the modified module hangs with the following message:

Started Update UTMP about System Runlevel Changes.

This is a gnome error and I am at a loss for why it appears after updating the boot and dtb for config5.

I did also try the above with copying the boot directory from the config5 system to the config2 modules just in case having the kernel and dtb changes in the APP partition would help solve this. No luck though.

Any suggestions or ideas. I am missing something basic here?

Eventually the goal is to generate and sign the various boot and dtb files and then deploy them on the TX2i using dd instead of flashing on the OTG port. I have read a couple other posts in the forum but have not found a complete summary on how to do this… does a good summary for doing something like this exist yet?

Note: Partition list (please correct me if I have got something wrong)

From the partition cfg file in l4t/bootloader/t186ref/cfg/
mmcblk0p6 = TBCDTB-NAME    bootloader-dtb
mmcblk0p7 = TBCDTB-NAME_b
mmcblk0p26 = LNXNAME       kernel - the secondary bootloader that loads the kernel from /boot
mmcblk0p27 = LNXNAME_b            - or it can contain the actual kernel.
mmcblk0p28 = KERNELDTB-NAME kernel-dtb  contains the actual blob that is also in /boot
mmcblk0p29 = KERNELDTB-NAME_b

Question: on tx2 and tx2i does LNXNAME contain UBOOT or the actual linux kernel as a default?

#2

“dd” copy between units is problematic. Long ago the non-rootfs partitions were not signed, but now they are. Whatever content is present in those partitions is now signed during flash prior to being copied to the Jetson. I suspect all of the check sums have failed.

#3

Thanks very much for your comment, your comment raises a few questions.
Does the signing key change after different builds using the same source tree?
When does the signing key change?
What paths are associated with the signing keys in the build area?

I’ll try to establish whether these two builds had the same signing keys.
I suspect they did because the boot progresses to the point of booting the
Linux kernel. But the kernel fails with a gnome issue.
It seems like the wrong signing key would have cause a halt as soon as
a bad key was detected.

#4

Those are good questions, and ones I cannot answer. I suspect that the key in part depends on the hardware involved, but that is only a guess. One can set up a key and create those files without actually flashing, and then use dd to copy, but someone else would need to provide that procedure. Basically, if I am right (and I might not be right), I think you would need to build your boot content, and then sign it separately for each flashed system.

#5

hello crveit,

there’s process to parse the platform information and generate sing/encrypt binaries.
you may dig into flashing message to have more details.
for example,
there’s tegrasign_v2 binary to fill SBK key, it’ll be all zero if no specify the key.
you should use flash script by adding “–no-flash” option for the quickest way to generate these sign/encrypt binaries.
it’ll store in your local host as below.
thanks

$OUT/Linux_for_Tegra/bootloader/signed/*

#6