Does kernel config option "Use appended device tree blob to zImage (EXPERIMENTAL)" work?

[EdSutter]

I tried enabling this, and then used bootm with just two arguments (omitting the fdt pointer).

Can't get the kernel to boot regardless of how I try it.

I assume the image is created with:

cat zImage <filename>.dtb > zImage_w_dtb

and then zImage_w_dtb is loaded, correct?

Has anyone tried this with success?

I like the idea of using this just because it eliminates the need to manage one additional file in /tftpboot.

Ed

[fabio_estevam]

Ed,

Make sure you have these options enabled:

CONFIG_ARM_APPENDED_DTB=y

CONFIG_ARM_ATAG_DTB_COMPAT=y

Also, the U-boot command 'bootm' expects to load a uImage type, not a zImage.

To boot a zImage, you need to use 'bootz'

Regards,

Fabio Estevam

[EdSutter]

Fabio,

Thanks for responding.

Ok, my stated steps in the initial post weren't complete.

At the top-level directory for the kernel (in my case linux-3.11.4) I did this (after completion of the build):

$ cat arch/arm/boot/zImage arch/arm/boot/dts/imx6q-sabresd.dtb >zImage_with_dtb

$ mkimage -A arm -O linux -T kernel -C none -a 0x10008000 -e 0x10008000 -d zImage_with_dtb /tftpboot/uImage_w_dtb

then on the target I did:

U-Boot> setenv bootargs 'console=ttymxc0,115200 ip=dhcp'

U-Boot>  tftpboot 0x11800000 uramdisk.img

U-Boot> tftpboot 0x12000000 uImage_w_dtb

U-Boot> bootm 0x12000000 0x11800000

I didn't originally have the kernel built with the CONFIG_ARM_ATAG_DTB_COMPAT=y setting, so I also rebuilt the kernel with that (note that the bootup works fine if I separate the .dtb image and just use the 3-argument bootm).  Anyway, even with that setting enabled, it still didn't work.  Seems like the issue may not even be the dtb stuff  because I get a panic saying it can't find rootfs, and I also notice that despite my setting of bootargs, the kernel startup says:

Kernel command line: noinitrd console=ttymxc0,115200

I must still be doing something wrong with bootm.

Ed

[fabio_estevam]

In U-boot prompt you can do:

setenv boot_fdt no

save

Then just boot the uImage as it was a standard uImage type.

Mainline U-boot will call bootm with a single argument in this case.

Regards,

Fabio Estevam

[fabio_estevam]

Just tried it and it worked fine here:

- Pastebin.com

Regards,

Fabio Estevam

[EdSutter]

Ok, so I'm apparently doing something stupid here...

I added the boot_fdt variable, made no difference. 

So, it seems my problem is not fdt as much as it is figuring out why the command line is getting scrogged.

I tried "bootm 0x12000000" with bootargs now having initrd=0x11800000.

I also tried "bootm 0x12000000 0x11800000".

Both gave me the same result.

Regardless of what I do, when the kernel starts up, it overrides the bootargs that should be used as the kernel command line...

Kernel command line: noinitrd console=ttymxc0,115200

Note that when I supply the three arguments (third being the address of a downloaded FDT binary) the command line is correct.

Anyway, my corporate firewall won't let me get to pastebin.com, could you email me that trace (I assume that's what you put there)?

(ed.sutter@alcatel-lucent.com)

[fabio_estevam]

The problem is that you are not running the part of the script that setup your command line.

You should run the same boot scripts that you do in the dt case, except that now you will boot a single uImage.

Regards,

Fabio Estevam

[EdSutter]

Isn't the content of "bootargs" what is supposed to be passed to the kernel as the command line?

[fabio_estevam · Accepted solution]

Yes, but the bootargs you posted has no rootfs information.

Also, you seem to be using the default command line from the kernel.

On my menuconfig I have

[*] Use appended device tree blob to zImage (EXPERIMENTAL))

[*]  Supplement the appended DTB with traditional ATAG informati

Kernel command line type (Use bootloader kernel arguments if available)  --->

(noinitrd console=ttymxc0,115200) Default kernel command string

You seem to be in the default kernel command string instead of the one from the bootloader.

:

[EdSutter]

Fabio,

Ok, I got it.  I mistook your instruction...

[*]  Supplement the appended DTB with traditional ATAG information

for

[*] Support for the traditional ATAGS boot data passing

Note I think this this corresponds to:

CONFIG_ARM_ATAG_DTB_COMPAT=y

CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

in .config.  So, just to recap for anyone interested in appending the .dtb image to the kernel (this applies to the SABRESDB, but should work with others by changing 'imx6q-sabresd.dtb to your board-specific .dtb file)...

1. In menuconfig boot->options:

[*] Use appended device tree blob to zImage (EXPERIMENTAL)

[*]    Supplement the appended DTB with traditional ATAG information

2. After building kernel...

$ cat arch/arm/boot/zImage arch/arm/boot/dts/imx6q-sabresd.dtb >zImage_with_dtb

$ mkimage -A arm -O linux -T kernel -C none -a 0x10008000 -e 0x10008000 -d zImage_with_dtb /tftpboot/uImage_w_dtb

3. At u-boot, use uImage_w_dtb as your 'kernel' variable at boot time.

Thanks Fabio (if I misstated anything above, please inform),

Ed

[fabio_estevam]

Glad you got it working, Ed

Please mark this thread as 'answered'.

Thanks,

Fabio Estevam

[EdSutter]

Note in one of my later posts...

> I tried "bootm 0x12000000" with bootargs now having initrd=0x11800000.

Your right, it is using the default command line, but I do have "use bootloader kernel arguments if available" set in the kernel.

That's what I don't understand... If I'm specifying a bootargs setting, then *even if it is incorrect*, why is the default being used instead of what I have set?

I'd really like to avoid digging into the ~1900 lines of cmd_bootm.c in uboot if possible.  :-(

In any case, the bootargs I'm using is:

setenv bootargs 'console=ttymxc0,115200 initrd=0x11800000 ip=dhcp'