Linux: boot arguments with U-Boot and Flat Image Tree (FIT)

Question

I am trying to get my own build of U-Boot to boot Linux on a Jetson TK1 board. As we are pushing for verified boot I am using the Flat Image Tree (unifying kernel image, device tree blob, ...) to describe my system. U-Boot can load the ITB file and tries to start the kernel but the system hangs after this message.

I assume that this is because no boot arguments are passed to the kernel (the original startup adds loads of arguments) but I am a little dumbfounded on how to pass the arguments to the kernel. I tried setting the bootargs environment variable but this did not change the situation.

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

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

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

Content of ITS file:

/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 ...

Impassable

Can you please provide console output and current bootargs so we can check where the boot stops ? – Petras

Answer 1

The salient issue is that the system seems to hang after U-Boot outputs the text

Starting kernel ...

If an uncompressed kernel Image file has been loaded, then the actual kernel startup code would be executed next.
But if a uImage or zImage file has been loaded (which are also reported as "uncompressed" because they are self-extracting), then the next code executed would be the decompression routine that is attached to the zImage file. Normally this decompression routine will output text such as

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

before the actual kernel startup code would be executed, before any processing of the kernel command line, before any processing of the Device Tree blob, and prior to any console output from the kernel (including earlyprintk).

---

There's a discrepancy between the kernel load & start addresses specified in the image header

 Load Address: 0x00000000
 Entry Point:  0x00000000

versus what is specified in the DT:

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

Since the kernel image is temporarily loaded at

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

the addresses in the DT would seem to be correct, and the addresses in the image header are bogus.

Assuming that there is no physical RAM at 0x00000000, the result will be that the kernel image is copied (or decompressed) to the bogus load address of 0, and then the kernel image will be executed by branching to the bogus entry point of 0. The CPU is likely to hang trying to execute garbage from nonexistent memory, and that correlates perfectly with what you report.

Solution is (1) confirm that the kernel is linked to 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 get you past this one point.

Crankshaft

Answer 2

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

Check that:

• You have compiled the tree (using compiler scripts/dtc/dtc inside the Linux kernel)
• Support for device tree is enabled in the kernel config (symbol CONFIG_USE_OF) (where OF stands for "Open Firmware")
• You provided U-Boot the address of the tree: bootm <uImage address> - <dtb address>
• Serial console is enabled in the kernel config under Device Drivers -> Character Devices -> Serial Drivers
• Console is enabled in bootargs (e.g., console=ttyS0,115200)

Petras

Please be aware that I am using an image tree which unites kernel image, device tree blob and other things (configurations, ramdisks, ...) into one file. – Impassable

Better. Have you enabled CONFIG_USE_OF and the console in bootargs ? – Petras

You have both console=ttyS0,115200n8 console=tty1 in your bootargs. Check which one is correct (start the machine w/out DTB and check) and remove the wrong one. – Petras

I have to add that these bootargs work in the case of using them in an extlinux.conf file to boot Linux on the same board – Impassable

Also removing tty1 (as tty0 is the one I'm retrieving output on) does not change anything :-/ – Impassable

Answer 3

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

Thunell