U-boot flashing r28.2

Hi,

I have managed to setup a redundant bootloader (r28.2), based on the instructions described in the file TX1_boot-firmware-redundancy.txt

The bootloader works as expected and can be updated using the flash.sh script (I have a custom bootloader). However, I need to be able to update it remotely, i.e. overwrite the LNX partition from the TX1, using a script and a bootloader file, generated on the host machine. U-boot is contained in boot.img. However, the actual file written is signed i.e. boot.img.signed. I have tried to generate the boot.img.signed file by using the following instruction on the host

sudo ./flash.sh --no-flash -k LNX jetson-tx1 mmcblk0p1

The script fails due to communication issues, but a folder is produced, called signed, which contais a lot of .signed files. This is where I pick up the boot.img.signed file i used to update my TX1. The bootloader is identical with the one currently flashed (using flash.sh), so I know it works. I just compile it at a later time, so that I can spot the difference. I use the following command to update the TX1, issued on the TX1

sudo dd if=boot.img.signed of=/dev/mmcblk0p3
sync
sync

When I reboot, the first bootloader (KFS0) fails and it automatically boots from KFS1 instead of KFS0. I have made the necessary changes in the kernel, as described in other threads, so that the boot partitions are visible and writable.

Why does this method fail?

  1. Do I use the wrong file? If yes, how do I generate the boot.img.signed file?
  2. Do I need to flash the signed dtb as well? Again, what is the proper way of generating it.
  3. Do I miss any steps in the update, is my procedure wrong? If yes, what is the correct procedure to update the first bootloader in a r28.2 installation, where multiple bootloaders are enabled. Thanks in advance.

Joseph

I would also be curious if there is a single document which describes the signing? Probably there is and I just haven’t seen it. One thought is that perhaps partitions which are signed all have to be signed with the same signature/hash and that being signed individually doesn’t work…in which case knowing how to set a signature itself would be the key (the logs of this method of flash may have clues but I have not yet had time to test).

hi all,

FYI,
there’s [Security] chapter in the [Release 28.2 developer guide], which describe signing authority.
thanks

Hi,

I have read this chapter. It has no information about how to generate, lets say a bootloader file. What I need is more information on the process. To clarify something. I am not using secure boot.

hello piperak,

we need to ‘flash’ the LNX partition through nvflash to update the u-boot.
thanks

Hi,

the whole point of my question was to flash u-boot without using an nvidia tool. If you had read my initial description it is obvious that I know what partition needs to be flashed. My problem is I do not know how to produce a valid update file, when I overwrite that partition without using any NVIDIA supplied tool. I have made all the necessary changes in the kernel and bootloader so that the partition is readable, visible and writable, so there is no doubt I can overwrite it.
So, I repeat the question: How do I produce a valid image that can be written on the LNX partition (mmcblk0p3 in my case) for r28.2.

Thanks

I was personally unable to find notes on the signing process in the Documentation “Security” section…it basically just says it is signed by an open source method without details:

Uboot/Kernel        NVIDIA-adapted OSS code. Signed/encrypted by OEM.

Then I found the “Flashing with Signed Boot File Binaries” section:

Flashing with Signed Boot File Binaries

1. Navigate to the directory where you installed L4T.

2. Place the Tegra device into force recovery mode.

• To flash the Tegra device with PKC signed binaries, execute:
sudo ./flash.sh -x <chipid> -y PKC -u <keyfile> <device name> mmcblk0p1

• To flash the Tegra device with clear binaries, execute:
sudo ./flash.sh <device name> mmcblk0p1

Where <device name> is:
• Jetson TK1: jetson-tk1
• Jetson TX1: jetson-tx1
• Jetson TX2: jetson-tx2

So it looks like the key is to use open source PKC when signing, but signing is not needed. This still leaves some room for information since this is probably the OpenSSL tools doing the work and there are many options (it seems it is probably pkcs11 but I’m not sure what actual commands are used). I would personally find an example of using OpenSSL tools for signing to be very useful.

One thing I did see was a case of using OpenSSL to sign smart cards (and eMMC is much like this):
https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC

The description there is with pkcs15, but all of the packages I see from Fedora are for pkcs11…I myself wonder which pkc versions may be supported. This has a list of the different PKCS standards:
https://en.wikipedia.org/wiki/PKCS
(this looks more or less like pcks11 and pkcs15 are interchangeable for some purposes)

Would someone be able to verify if the open source signing uses PKCS11 and if there is a particular OpenSSL tool to do this? This would be the key (no pun intended:) missing step.