Hi Simon,
In the normal u-boot, they used extlinux to specify the ramdisk. I was using bootm to load the ramdisk.
This is the normal boot up terminal logs.
"MMC: no card present switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 727 bytes read in 105 ms (5.9 KiB/s) L4T boot options 1: primary kernel Enter choice: 1: primary kernel Retrieving file: /boot/initrd 5565090 bytes read in 213 ms (24.9 MiB/s) Retrieving file: /boot/Image 34179080 bytes read in 857 ms (38 MiB/s) append: root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 ## Flattened Device Tree blob at 80000000 Booting using the fdt blob at 0x80000000 reserving fdt memory region: addr=80000000 size=10000 Using Device Tree in place at 0000000080000000, end 0000000080058f8e
Starting kernel ..."
My sequence with vboot was to set the bootargs first,then the initrd_high and fdt_high and then load to e-mmc and then call bootm. In the u-boot env, the following values were there. I am attaching the output of printenv here, if that could give some clues on what I am doing differently.
kernel_addr_r=80280000 kernel_addr_r_aliases=loadaddr loadaddr=80280000 ramdisk_addr_r=82a00000
"U-Boot 2016.07-dirty (Oct 16 2019 - 16:12:24 -0700)
TEGRA186 Model: NVIDIA P2771-0000-500 DRAM: 7.8 GiB MC: Tegra SD/MMC: 0, Tegra SD/MMC: 1 *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: eth0: ethernet@2490000 Hit any key to stop autoboot: 0 Tegra186 (P2771-0000-500) # setenv bootargs root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 Tegra186 (P2771-0000-500) # setenv initrd_high 8effffff Tegra186 (P2771-0000-500) # setenv fdt_high 8effffff Tegra186 (P2771-0000-500) # ext2load mmc 0 0x90000000 /boot/tegra.fit 40090346 bytes read in 1051 ms (36.4 MiB/s) Tegra186 (P2771-0000-500) # bootm 0x90000000 ## Loading kernel from FIT Image at 90000000 ... Using 'conf@1' configuration Verifying Hash Integrity ... sha256,rsa4096:tx2_key+ OK Trying 'kernel@1' kernel subimage Description: Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0x900000c8 Data Size: 34179080 Bytes = 32.6 MiB Architecture: AArch64 OS: Linux Load Address: 0x80280000 Entry Point: 0x80280000 Hash algo: sha256 Hash value: 417be59a15deda06283bdfdc2ef08911c27c0fbb3e4581fdf1f94f8ca7ee6193 Verifying Hash Integrity ... sha256+ OK ## Loading ramdisk from FIT Image at 90000000 ... Using 'conf@1' configuration Trying 'ramdisk@1' ramdisk subimage Description: Ramdisk Image for Tegra TX2 Type: RAMDisk Image Compression: gzip compressed Data Start: 0x920eca74 Data Size: 5565090 Bytes = 5.3 MiB Architecture: AArch64 OS: Linux Load Address: 0x82a00000 Entry Point: 0x82a00000 Hash algo: sha256 Hash value: b248b753bb8c599756c40fc3f11b9c418e6638872f6af3ee44243af69a4f0b3f Verifying Hash Integrity ... sha256+ OK Loading ramdisk from 0x920eca74 to 0x82a00000 ## Loading fdt from FIT Image at 90000000 ... Using 'conf@1' configuration Trying 'fdt@1' fdt subimage Description: DTB for Tegra TX2 Type: Flat Device Tree Compression: uncompressed Data Start: 0x920989cc Data Size: 344019 Bytes = 336 KiB Architecture: AArch64 Hash algo: sha256 Hash value: f2b4b8ac842eac0acfe25e129e102d9919ad16ce40499b079b4a73eb1f39f059 Verifying Hash Integrity ... sha256+ OK Booting using the fdt blob at 0x920989cc Loading Kernel Image ... OK reserving fdt memory region: addr=80000000 size=10000 Loading Ramdisk to 8eab1000, end 8efffaa2 ... OK Loading Device Tree to 000000008ea5a000, end 000000008eab0fd2 ... OK
Starting kernel ..."
Thanks again for your time.
- Rayees
-----Original Message----- From: Simon Glass sjg@chromium.org Sent: Monday, October 21, 2019 2:13 PM To: Rayees Shamsuddin Rayees.Shamsuddin@intusurg.com Cc: u-boot@lists.denx.de Subject: [EXTERNAL] Re: Need help with verified u-boot on Tegra TX2
Hi Rayees,
On Sat, 19 Oct 2019 at 20:14, Rayees Shamsuddin Rayees.Shamsuddin@intusurg.com wrote:
Simon,
Thanks for all your great and pioneering effort on verified u-boot. I am benefiting a lot for your work. I am trying to implement verified u-boot on Tegra TX2.
Based on the wonderful documentation that you provided, I was able to successfully create a fit image and got the dtb and kernel to boot. But I ran into some issues when I incorporated ramdisk into the fit image. Initially, it would get stuck on “Starting kernel …”. Then I modified the environment as follows setenv initrd_high 8effffff setenv fdt_high 8effffff
Initially it was set to fdt_high=ffffffffffffffff initrd_high=ffffffffffffffff
I haven’t quite understood why this change caused the kernel to load. Is it because initrd_high=ffffffffffffffff overwrites the relocatable u-boot code?
Anyway after this change, I got the kernel to boot, but with one caveat – the RAMDISK couldn’t be loaded.
Booting using the fdt blob at 0x920989cc Loading Kernel Image ... OK reserving fdt memory region: addr=80000000 size=10000 Loading Ramdisk to 8eab1000, end 8efffaa2 ... OK Loading Device Tree to 000000008ea5a000, end 000000008eab0fd2 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x100
However, I saw the message [ 5.403174] RAMDISK: Couldn't find valid RAM disk image starting at 0.
I would be grateful if you could provide me some guidance on what might be causing this issue or how to go about resolving this.
Are you saying that it works correctly without verified boot?
Normally U-Boot should pass a pointer to the ramdisk to linux. That should not change with vboot.
Regards, Simon
Thanks and Regards Rayees Shamsuddin Product Security Engineer Intuitive Surgical
Tegra.its
/dts-v1/; / { description = "fitImage for Tegra TX2"; #address-cells = <1>; images { kernel@1 { description = "Linux kernel"; data = /incbin/("Image"); arch = "arm64"; os = "linux"; type = "kernel"; compression = "none"; load = <0x80280000>; entry = <0x80280000>; hash@1 { algo = "sha256"; }; }; fdt@1 { description = "DTB for Tegra TX2"; data = /incbin/("tegra186-quill-p3310-1000-c03-00-base.dtb"); type = "flat_dt"; arch = "arm64"; compression = "none"; hash@1 { algo = "sha256"; }; }; ramdisk@1 { description = "Ramdisk Image for Tegra TX2"; data = /incbin/("initrd"); type = "ramdisk"; arch = "arm64"; os = "linux"; compression = "gzip"; load = <0x82a00000>; entry = <0x82a00000>; hash@1 { algo = "sha256"; }; }; }; configurations { default = "conf@1"; conf@1 { description = "Boot Linux kernel, FDT blob and ramdisk"; kernel = "kernel@1"; fdt = "fdt@1"; ramdisk = "ramdisk@1"; signature@1 { algo = "sha256,rsa4096"; key-name-hint = "tx2_key"; sign-images = "fdt", "kernel", "ramdisk"; }; }; }; };
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- NOTE THAT THIS EMAIL ORIGINATED FROM OUTSIDE OF INTUITIVE SURGICAL.. Be alert for fraudulent emails that spoof internal “@intusurg.com” email addresses. Report these or other security threats to: ITHelpNow@intusurg.com.