[U-Boot] [EXTERNAL] Re: Need help with verified u-boot on Tegra TX2
Rayees Shamsuddin
Rayees.Shamsuddin at intusurg.com
Tue Oct 22 00:21:45 UTC 2019
Hi Simon,
Thanks again for all your help. The one thing I wasn't sure is regarding the compression type for the ramdisk. It is gzip compressed, but some commit comments indicated that I should keep compression type as none since the kernel should be uncompressing the ramdisk.
https://gitlab.denx.de/u-boot/u-boot/commit/bddd985734653c366c8da073650930fb2e9b5003
The version of u-boot that I used doesn't support gzip compression. Hence I am assuming that u-boot doesn't do any decompression.
I can instrument the code in image_setup_libfdt() and see what address is used with the normal u-boot stock version from the Tegra bsp and try to mimic that.
I am not sure if you meant to cc Stephen - didn’t see Stephen cc'ed in the previous email.
- Rayees
-----Original Message-----
From: Simon Glass <sjg at chromium.org>
Sent: Monday, October 21, 2019 3:54 PM
To: Rayees Shamsuddin <Rayees.Shamsuddin at intusurg.com>
Cc: u-boot at lists.denx.de
Subject: Re: [EXTERNAL] Re: Need help with verified u-boot on Tegra TX2
Hi Rayees,
On Mon, 21 Oct 2019 at 15:55, Rayees Shamsuddin <Rayees.Shamsuddin at intusurg.com> wrote:
>
> 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 at 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 at 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 at 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 at 1' configuration
> Verifying Hash Integrity ... sha256,rsa4096:tx2_key+ OK
> Trying 'kernel at 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 at 1' configuration
> Trying 'ramdisk at 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 at 1' configuration
> Trying 'fdt at 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.
+Stephen Warren who may have some ideas.
I think that you should turn off vboot and get the FIT image running without that, to eliminate any problems. To me it seems that U-Boot is working correctly, but I'm not sure why the RAM disk cannot be found.
In terms of the U-Boot code:
image_setup_libfdt() sets up the device tree (which contains info about the initrd)
fdt_initrd() is the function that actually writes the info to the DT
I suppose it is possible that the device tree does not have any spare space in it, and the error handling is broken in some way so it is not telling you. Other than that, I'm not sure.
Regards,
Simon
More information about the U-Boot
mailing list