boot linux using cboot without uboot

Is possible to boot rich linux using cboot without uboot? With latest L4T R32.1.

The end goal: to do kernel (rich os) signature verification in cboot. using the same signature procedures as in secure boot stages. to extend trust to rich os kernel.

hello DmitriK,

were you working with Jetson-TX2?
for Jetson-TX2, linux kernel is loaded in by u-boot from root FS at /boot/Image.

also, Jetson-Xavier doesn’t uses u-boot.
thanks

I was thinking someone said Xavier in R32.1 boots directly with CBoot and without U-Boot. See the boot flow documentation here:
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fbootflow_jetson_xavier.html%23

I don’t know if that could be adapted for a TX2, but the boot flow document would be the place to start.

Jerry,
I am working with Jetson-TX2. I need cboot to load TX2 kernel (bundled with dtb) into memory (by any means). The goal is to verify signature like you already do for TOS kernel. I do not need TOS. Just need to boot rich linux with verified kernel. Have you done that?

hello DmitriK,

I had never tried to skip u-boot for Jetson-TX2.
could you please check U-Boot Customization chapter to check if any helpful details.
thanks

hello DmitriK,

By the way, Jetson-TX2 had environment variable to configure whether to use u-boot.
for example,

$ sudo USE_UBOOT=0 ./flash.sh jetson-tx2 mmcblk0p1

you may go through this approach for your development,
thanks

@DmitriK I have tried below method with TX2, it works for me.
Hope it works for u too.

diff --git a/p2771-0000.conf.common b/p2771-0000.conf.common
index 1926934..d6976b1 100644
--- a/p2771-0000.conf.common
+++ b/p2771-0000.conf.common
@@ -225,7 +225,7 @@ TBCDTB_FILE=tegra186-quill-p3310-1000-a00-00-base.dtb;
 # 1) Set environment variable USE_UBOOT to 0 or 1.
 # 2) Edit the line below to set USE_UBOOT to 0 or 1.
 if [ -z "${USE_UBOOT}" ]; then
-       USE_UBOOT=1;
+       USE_UBOOT=0;

Thanks. It boots ok for 32.1.
Is cboot source for 32.1 available for download?

Hi Guys,

I meet some side-effect after skip uboot bootup.

When bootup installed with u-boot, the u-boot root FS at /boot/Image. But when remove u-boot phase, seems it will never load Image from /boot/Image. I have remove /boot/Image file, the system can still bootup normally. And If I force to replace /boot/Image with the new one, the bootup log showing it is still onld Image file.

I have to use flash.sh to burn whole system image, the new Image fill will take effect.

So I guest The available Image is not /boot/Image, maybe burned on some special flash partition now.

Can you help me out this? And another question is if I want to update Image again, how can I get that?

CBoot does not understand ext4 file system type (ext4 does not appear to be part of what the docs call the “Common Driver Framework”, or CDF). U-Boot does understand ext4. You could move the Image file to a partition (if it isn’t already there…in part I’m looking at Xavier since it doesn’t use U-Boot) and treat it as binary data for load and copy to the initial address.

This is probably also why more recent releases moved device trees to partitions…it is often stated that earlier boot stages started needing the device tree, and since those stages do not have ext4 drivers, and thus the device tree had to become a partition. In that sense the kernel is no different from device tree…it would be easy for earlier boot stages to load the kernel if they understood ext4, but then the device tree itself could also be put in “/boot” if ext4 were understood (though I’m not sure how signing would work then). As a test you might try booting with “Image” being an empty file with no content (the one in “/boot”), and see if it still boots. Probably it will still boot.

My thought for NVIDIA: Wouldn’t it be cool if CDF understood ext4? I think most Jetson developers would think magic had returned to the world of booting :P

Similarly, wouldn’t it be cool if CDF had USB3 mode drivers?

hello 53216142,

due to u-boot loading the kernel from root file system, /boot/Image.
it’s expect that skipping u-boot and it will never load kernel image from rootfs.

you might have an alternative way to generate signed kernel image locally.
copy it to your remote target and perform dd commands to overwrite the kernel partition.
for example,

$ sudo ./flash.sh --no-flash -r -k kernel jetson-tx2 mmcblk0p1
...
[   0.0957 ] Signed file: $OUT/Linux_for_Tegra/bootloader/boot_sigheader.img.encrypt
*** boot.img has been signed successfully. ***

Hello Jerry,

Does this means that there has another kernel image somewhere besides rootfs, and skipping u-boot will load kernel from there?

I’m using Jetson-tx2.
After i read tx2’s boot flow , i have no idea which path it will go when it skip u-boot.

Yes. That is exactly what it means. Here are the partitions from the eMMC device:

Device            Size Name             UUID
/dev/mmcblk0p1     28G APP              2BDB431B-CAC9-443C-BDCE-29093101C274
/dev/mmcblk0p2      4M mts-bootpack     0CC538E1-727B-4DDC-A552-E5573544134D
/dev/mmcblk0p3      4M mts-bootpack_b   04CF934F-E606-431E-8E15-A3375185082C
/dev/mmcblk0p4    512K cpu-bootloader   42B9DD2D-BD8C-4086-934C-D51541C5E076
/dev/mmcblk0p5    512K cpu-bootloader_b 0F3C2535-3064-4EC3-83E4-AA4AE941A838
/dev/mmcblk0p6    512K bootloader-dtb   619CFCE2-80D4-49D0-BC0F-B52A88BF6341
/dev/mmcblk0p7    512K bootloader-dtb_b 278C78FD-4492-4720-91F7-94224A2CDF69
/dev/mmcblk0p8      3M secure-os        60F23A5D-A0A3-4914-9F1F-F471787DCD0C
/dev/mmcblk0p9      3M secure-os_b      7D516B6C-EE5D-4B1D-A97E-8F014DA4160A
/dev/mmcblk0p10     2M eks              78FA60D8-D18E-4974-83E8-295727F4C97D
/dev/mmcblk0p11     4M adsp-fw          0C93B795-FE11-4ECC-B879-D229C2944D4F
/dev/mmcblk0p12     4M adsp-fw_b        4F53BB9D-C60B-4FA7-845A-2E46D2E08F5E
/dev/mmcblk0p13   604K bpmp-fw          2E6AF670-3EC7-40D9-BB22-381752F30710
/dev/mmcblk0p14   604K bpmp-fw_b        4AA9BF9B-3277-41ED-9AB2-6B5198383672
/dev/mmcblk0p15   500K bpmp-fw-dtb      490D7709-A9EB-4400-A264-155C66B1FF29
/dev/mmcblk0p16   500K bpmp-fw-dtb_b    3D154A8E-84C2-4E09-9E2E-CD36FBB5663A
/dev/mmcblk0p17     2M sce-fw           4927731F-AD88-485C-885A-7D44F7D32142
/dev/mmcblk0p18     2M sce-fw_b         11D17F16-42CB-4BA7-9EC8-EB3FAB36651E
/dev/mmcblk0p19     6M sc7              2A7440DC-4197-49BE-AECB-B26D79FCC779
/dev/mmcblk0p20     6M sc7_b            296607A2-2572-43E1-8BDD-575812FED057
/dev/mmcblk0p21     2M FBNAME           44BA6439-0006-4F90-A5F1-D867D423640F
/dev/mmcblk0p22   128M BMP              317D327D-A43F-4944-AC5C-9A0186A98A7A
/dev/mmcblk0p23   128M BMP_b            2D454E2B-C14E-4DAF-AC5A-8A24B9985A6A
/dev/mmcblk0p24    32M SOS              2BB94610-89CB-4B57-B44E-C1242FB9E074
/dev/mmcblk0p25    32M SOS_b            13B43753-A8FD-493E-A68D-023769B68525
/dev/mmcblk0p26    64M kernel           04E5EBC8-5545-46EE-95ED-EA43A52C5A2F
/dev/mmcblk0p27    64M kernel_b         60AC96DC-B883-419D-9E29-22297E9E120A
/dev/mmcblk0p28   512K kernel-dtb       657EDDF5-066A-417A-919C-E3612E42392A
/dev/mmcblk0p29   512K kernel-dtb_b     710A0670-8DF6-49BC-8266-9D39EE388722
/dev/mmcblk0p30   256M CAC              03013235-C26E-4B37-B4E2-111D60804630
/dev/mmcblk0p31 394.8M UDA              18E783BC-3D61-419C-9A19-A11ACDC9A044

It will use the /dev/mmcblk0p26 (kernel) partition to find the kernel. Here is the serial console log of it booting: console-log-boot-w-no-uboot.txt (https://devtalk.nvidia.com/cmd/default/download-comment-attachment/80868/)

You can see from the timestamp 2.122 to 3.037 Cboot loads the kernel from the partition on the eMMC device. This is actually boot.img which contains the kernel, ramdisk, and the kernel command line.

If you erase /dev/mmcblk0p26 (i.e., sudo dd if=/dev/zero of=/dev/mmcblk0p26) and reset, you will get a system where the Cboot hangs trying to find the kernel. See serial console log once the kernel partition on the eMMC has been erase: console-log-boot-w-no-uboot-zerod-kernel-part.txt (https://devtalk.nvidia.com/cmd/default/download-comment-attachment/80869/)

Notice that while it is in Cboot it finds the kernel partition (near the end of the log), however the authentication/verification of the boot.img fails and Cboot prints out “kernel boot failed” and goes no further.

Here is the sequence:

  1. SoC BootROM
  2. MB1
  3. TBoot-BPMP (MB2)
  4. Monitor/ATF (TOS)
  5. Cboot
  6. Linux kernel (from eMMC partition)

Skipping U-Boot means the boot goes straight from Cboot to the Linux kernel that was fetched from the eMMC raw “kernel” partition, not the ext4 file system /boot path.

console-log-boot-w-no-uboot.txt (73.3 KB)
console-log-boot-w-no-uboot-zerod-kernel-part.txt (12.2 KB)

Thanks! This helps a lot!