Linux: boot arguments with U-Boot and flat image tree (FIT)

Question

I am trying to get my own U-Boot assembly for booting Linux on a Jetson TK1 board. Since we insist on a verified boot, I use the Flat Image Tree (unifying kernel image, blob block, ...) to describe my system. U-Boot may load the ITB file and try to start the kernel, but the system freezes after this message.

I assume this is because no boot arguments are passed to the kernel (the initial start adds a lot of arguments), but I'm a little overwhelmed by how to pass arguments to the kernel. I tried to set the bootargs environment variable, but that did not change the situation.

How to pass kernel arguments to the kernel when using an ITB file?

Command line arguments (taken from the APPEND command of extlinux.conf examples):

console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 video=tegrafb mem=1862M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M@3945M tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal usb_port_owner_info=0 fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 tegra_fbmem=32899072@0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt 

ITS file content:

 /dts-v1/; / { description = "Simple image with single Linux kernel and FDT blob"; #address-cells = <1>; images { kernel@1 { description = "Vanilla Linux kernel"; data = /incbin/("./zImage"); type = "kernel"; arch = "arm"; os = "linux"; compression = "none"; load = <0x81008000>; entry = <0x81008000>; hash@1 { algo = "crc32"; }; hash@2 { algo = "sha1"; }; }; fdt@1 { description = "Flattened Device Tree blob"; data = /incbin/("./tegra124-pm375.dtb"); type = "flat_dt"; arch = "arm"; compression = "none"; hash@1 { algo = "crc32"; }; hash@2 { algo = "sha1"; }; }; }; configurations { default = " conf@1 "; conf@1 { description = "Boot Linux kernel with FDT blob"; kernel = " kernel@1 "; fdt = " fdt@1 "; }; }; }; 

U-Boot Output:

 Tegra124 (Jetson TK1) # fatload mmc 1 0x90000000 /kernel_fdt.itb reading /kernel_fdt.itb 5946200 bytes read in 497 ms (11.4 MiB/s) Tegra124 (Jetson TK1) # bootm 0x90000000 ## Loading kernel from FIT Image at 90000000 ... Using ' conf@1 ' configuration Verifying Hash Integrity ... OK Trying ' kernel@1 ' kernel subimage Description: Vanilla Linux kernel Type: Kernel Image Compression: uncompressed Data Start: 0x900000ec Data Size: 5910168 Bytes = 5.6 MiB Architecture: ARM OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: crc32 Hash value: c5b4b377 Hash algo: sha1 Hash value: f001007efe83f563425bfe0659186a32395c946c Verifying Hash Integrity ... crc32+ sha1+ OK ## Loading fdt from FIT Image at 90000000 ... Using ' conf@1 ' configuration Trying ' fdt@1 ' fdt subimage Description: Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x905a30ac Data Size: 34678 Bytes = 33.9 KiB Architecture: ARM Hash algo: crc32 Hash value: e466b23e Hash algo: sha1 Hash value: ec909ae16e62233d0ed1e1f4c909085abc9b5879 Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0x905a30ac Loading Kernel Image ... OK Using Device Tree in place at 905a30ac, end 905ae821 Starting kernel ... 

Answer 1

The significant problem is that the system seems to freeze after U-Boot displays text

 Starting kernel ... 

If the uncompressed kernel Image is loaded, then the actual kernel launch code will be run.
But if a uImage or zImage file has been loaded (which also appears as "uncompressed" because it is self-extracting), then the next code executed will be decompression that is bound to the zImage file. Typically, this decompression procedure displays text, for example

 Uncompressing Linux............ done, booting the kernel. 

before the actual kernel start code is run before any processing of the kernel command line before any processing of the device block tree and before any console leaves the kernel (including earlyprintk).

---

There is a discrepancy between the kernel load and the start addresses indicated in the image header

  Load Address: 0x00000000 Entry Point: 0x00000000 

in comparison with what is indicated in the DT:

  load = <0x81008000>; entry = <0x81008000>; 

Since the kernel image is temporarily loaded in

 ## Loading kernel from FIT Image at 90000000 ... 

the addresses in the DT look correct, and the addresses in the image header are dummy.

Assuming that there is no physical RAM at 0x00000000, the result is that the kernel image will be copied (or unpacked) to the fictitious boot address 0, and then the kernel image will be executed by branching to the fictitious entry point 0. The CPU will probably hang, trying to execute garbage from non-existent memory, and this is perfectly consistent with what you are reporting.

Solution (1) confirms that the kernel is associated with the correct address and (2) to specify the correct addresses in the mkimage command using the -a and -e command options.
This correction should at least pass this point.

Answer 2

When using the device tree, you still use bootargs to provide arguments.

Make sure that:

• You compiled the tree (using the scripts/dtc/dtc compiler inside the Linux kernel)
• Device tree support is included in the kernel configuration (symbol CONFIG_USE_OF ) (where OF stands for "Open Firmware").
• You specified the U-Boot address of the tree: bootm <uImage address> - <dtb address>
• The serial console is included in the kernel configuration under "Device Drivers" → Symbol Devices → Serial Drivers
• The console is included in bootargs (e.g. console=ttyS0,115200 )

Answer 3

I am having the same or similar problem. My solution (or work around) for this problem was to set the U-Boot initrd_high and fdt_high environment variables to the address in RAM before the moved U-boot (in my case 8effffff).