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:
[url]https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fbootflow_jetson_xavier.html%23[/url]
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:
- SoC BootROM
- MB1
- TBoot-BPMP (MB2)
- Monitor/ATF (TOS)
- Cboot
- 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!