[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Baojun Wang]

hi, list:

  I've read Documentation/powerpc/booting-without-of.txt & some
documents about fdt/dtb, as booting-without-of.txt said, the
bootloader like u-boot should passing fdt as $r3, the kernel entry
(physical) address as $r4;

                r3 : physical pointer to the device-tree block
                (defined in chapter II) in RAM

                r4 : physical pointer to the kernel itself. This is
                used by the assembly code to properly disable the MMU
                in case you are entering the kernel with MMU enabled
                and a non-1:1 mapping.

                r5 : NULL (as to differentiate with method a)

I see fdt is something like:

struct fdt_header {
        uint32_t magic;                  /* magic word FDT_MAGIC */
        uint32_t totalsize;              /* total size of DT block */
        uint32_t off_dt_struct;          /* offset to structure */
        uint32_t off_dt_strings;         /* offset to strings */
        uint32_t off_mem_rsvmap;         /* offset to memory reserve map */
        uint32_t version;                /* format version */
        uint32_t last_comp_version;      /* last compatible version */

        /* version 2 fields below */
        uint32_t boot_cpuid_phys;        /* Which physical CPU id we're
                                            booting on */
        /* version 3 fields below */
        uint32_t size_dt_strings;        /* size of the strings block */

        /* version 17 fields below */
        uint32_t size_dt_struct;         /* size of the structure block */
};

My question is how does the kernel cmd line being passed? I know it's
possible for u-boot to patching the target uImage (assume we're using
kernel image cuImage.bamboo)'s dtb by overwrite the dtb ``chosen''
section, but I didn't find any code in u-boot trying to do this.

Even more, after the kernel is bootstraping, (assume we're using a
bamboo board), we'll run into:

static bd_t bd;

...
void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
		unsigned long r6, unsigned long r7)
{
	CUBOOT_INIT();
	bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
}

...

void bamboo_init(void *mac0, void *mac1)
{
	platform_ops.fixups = bamboo_fixups;
	platform_ops.exit = ibm44x_dbcr_reset;
	bamboo_mac0 = mac0;
	bamboo_mac1 = mac1;
	fdt_init(_dtb_start);
	serial_console_init();
}
...

this code will assume $r3 is passed as a ``bd_t'' structure, but $r3
passed in I think it's the dtb address (not bd_t), and bamboo_init
will set the NIC wrong MAC addresses. I'm quite sure I misunderstand
something between u-boot & linux kernel, could some help me to figure
it out? Thanks in advance!

  Best Regards,
Wang Baojun

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Kumar Gala]

> My question is how does the kernel cmd line being passed? I know it's
> possible for u-boot to patching the target uImage (assume we're using
> kernel image cuImage.bamboo)'s dtb by overwrite the dtb ``chosen''
> section, but I didn't find any code in u-boot trying to do this.

Did you look at common/fdt_support.c and fdt_chosen()

The command lines is passed in there as "bootargs"

> Even more, after the kernel is bootstraping, (assume we're using a
> bamboo board), we'll run into:
>
> static bd_t bd;
>
> ...
> void platform_init(unsigned long r3, unsigned long r4, unsigned long  
> r5,
> 		unsigned long r6, unsigned long r7)
> {
> 	CUBOOT_INIT();
> 	bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
> }
>
> ...
>
> void bamboo_init(void *mac0, void *mac1)
> {
> 	platform_ops.fixups = bamboo_fixups;
> 	platform_ops.exit = ibm44x_dbcr_reset;
> 	bamboo_mac0 = mac0;
> 	bamboo_mac1 = mac1;
> 	fdt_init(_dtb_start);
> 	serial_console_init();
> }
> ...
>
> this code will assume $r3 is passed as a ``bd_t'' structure, but $r3
> passed in I think it's the dtb address (not bd_t), and bamboo_init
> will set the NIC wrong MAC addresses. I'm quite sure I misunderstand
> something between u-boot & linux kernel, could some help me to figure
> it out? Thanks in advance!

Where is the code you are referencing above?  This is the "old" bd_t  
style of booting.  Only the boot wrapper code or and old kernel would  
still be using this.

- k

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Baojun Wang]

On Mon, Jul 13, 2009 at 10:27 PM, Kumar Gala<galak@kernel.crashing.org> wrote:
>> My question is how does the kernel cmd line being passed? I know it's
>> possible for u-boot to patching the target uImage (assume we're using
>> kernel image cuImage.bamboo)'s dtb by overwrite the dtb ``chosen''
>> section, but I didn't find any code in u-boot trying to do this.
>
> Did you look at common/fdt_support.c and fdt_chosen()
>
> The command lines is passed in there as "bootargs"

That's all I need ;-)

>> Even more, after the kernel is bootstraping, (assume we're using a
>> bamboo board), we'll run into:
>>
>> static bd_t bd;
>>
>> ...
>> void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> ? ? ? ? ? ? ? ?unsigned long r6, unsigned long r7)
>> {
>> ? ? ? ?CUBOOT_INIT();
>> ? ? ? ?bamboo_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
>> }
>>
>> ...
>>
>> void bamboo_init(void *mac0, void *mac1)
>> {
>> ? ? ? ?platform_ops.fixups = bamboo_fixups;
>> ? ? ? ?platform_ops.exit = ibm44x_dbcr_reset;
>> ? ? ? ?bamboo_mac0 = mac0;
>> ? ? ? ?bamboo_mac1 = mac1;
>> ? ? ? ?fdt_init(_dtb_start);
>> ? ? ? ?serial_console_init();
>> }
>> ...
>>
>> this code will assume $r3 is passed as a ``bd_t'' structure, but $r3
>> passed in I think it's the dtb address (not bd_t), and bamboo_init
>> will set the NIC wrong MAC addresses. I'm quite sure I misunderstand
>> something between u-boot & linux kernel, could some help me to figure
>> it out? Thanks in advance!
>
> Where is the code you are referencing above? ?This is the "old" bd_t style
> of booting. ?Only the boot wrapper code or and old kernel would still be
> using this.
>
> - k
>

the code is from arch/powerpc/boot/cuboot-bamboo.c, and the kernel is
2.6.30.1, the boot image I'm using is something like cuImage.bamboo, I
checked zImage.ld.S, and found that when we're running cuImage.bamboo,
we actually fall into arch/powerpc/boot/crt0.S:_zimage_start(), which
will call platform_init() and then bamboo_init() finally. but sounds
like if we passing r3 as fdt, then the code (platform_init, etc.., and
even arch/powerpc/kernel/head_xxx.S start() function, only comments,
though) is actually wrong, isn't it? Thank you very much for help.

  Best Regards,
Wang

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Kumar Gala]

On Jul 13, 2009, at 9:39 AM, Baojun Wang wrote:

>>
>> Where is the code you are referencing above?  This is the "old"  
>> bd_t style
>> of booting.  Only the boot wrapper code or and old kernel would  
>> still be
>> using this.
>>
>> - k
>>
>
> the code is from arch/powerpc/boot/cuboot-bamboo.c, and the kernel is
> 2.6.30.1, the boot image I'm using is something like cuImage.bamboo, I
> checked zImage.ld.S, and found that when we're running cuImage.bamboo,
> we actually fall into arch/powerpc/boot/crt0.S:_zimage_start(), which
> will call platform_init() and then bamboo_init() finally. but sounds
> like if we passing r3 as fdt, then the code (platform_init, etc.., and
> even arch/powerpc/kernel/head_xxx.S start() function, only comments,
> though) is actually wrong, isn't it? Thank you very much for help.

This is the boot wrapper code only used if you are trying to boot a  
new kernel w/an old u-boot.  If you are using a current u-boot you  
should just be using a plain old uImage as produced by the kernel build.

- k

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Baojun Wang]

On Mon, Jul 13, 2009 at 10:53 PM, Kumar Gala<galak@kernel.crashing.org> wrote:
>
> On Jul 13, 2009, at 9:39 AM, Baojun Wang wrote:
>
>>>
>>> Where is the code you are referencing above? ?This is the "old" bd_t
>>> style
>>> of booting. ?Only the boot wrapper code or and old kernel would still be
>>> using this.
>>>
>>> - k
>>>
>>
>> the code is from arch/powerpc/boot/cuboot-bamboo.c, and the kernel is
>> 2.6.30.1, the boot image I'm using is something like cuImage.bamboo, I
>> checked zImage.ld.S, and found that when we're running cuImage.bamboo,
>> we actually fall into arch/powerpc/boot/crt0.S:_zimage_start(), which
>> will call platform_init() and then bamboo_init() finally. but sounds
>> like if we passing r3 as fdt, then the code (platform_init, etc.., and
>> even arch/powerpc/kernel/head_xxx.S start() function, only comments,
>> though) is actually wrong, isn't it? Thank you very much for help.
>
> This is the boot wrapper code only used if you are trying to boot a new
> kernel w/an old u-boot. ?If you are using a current u-boot you should just
> be using a plain old uImage as produced by the kernel build.

do you mean the default ``uImage'' file? I'm using u-boot-2009.06, and
I can boot successfully with cuImage.mpc8548cds (I'm actually working
on a mpc8548 cds board), but unable to boot ``uImage'', I'm sure the
``vmlinux'' is the same.


tftp 1000000 uImage
bootm 1000000


Bytes transferred = 1619661 (18b6cd hex)
=> bootm 1000000
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-2.6.31-rc2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1619597 Bytes =  1.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

acording the arch/powerpc/boot/Makefile:

# dtbImage% - a dtbImage is a zImage with an embedded device tree blob
$(obj)/dtbImage.initrd.%: vmlinux $(wrapperbits) $(obj)/%.dtb
        $(call if_changed,wrap,$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)

$(obj)/dtbImage.%: vmlinux $(wrapperbits) $(obj)/%.dtb
        $(call if_changed,wrap,$*,,$(obj)/$*.dtb)

# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
# prefix
$(obj)/vmlinux.strip: vmlinux
        $(STRIP) -s -R .comment $< -o $@

# The iseries hypervisor won't take an ET_DYN executable, so this
# changes the type (byte 17) in the file to ET_EXEC (2).
$(obj)/zImage.iseries: vmlinux
        $(STRIP) -s -R .comment $< -o $@
        printf "\x02" | dd of=$@ conv=notrunc bs=1 seek=17

$(obj)/uImage: vmlinux $(wrapperbits)
        $(call if_changed,wrap,uboot)


It seems the right image should be dtbImage.XXXX because it embedes
with dtb while uImage does not, however, mpc8548_cds (mpc85xx) doesn't
produce the dtbImage..

I'm sorry I can't quite follow you, get confused again -_-

  Regards & Thanks
Wang

> - k
>

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Detlev Zundel]

Hi Wang,

>>> the code is from arch/powerpc/boot/cuboot-bamboo.c, and the kernel is
>>> 2.6.30.1, the boot image I'm using is something like cuImage.bamboo, I
>>> checked zImage.ld.S, and found that when we're running cuImage.bamboo,
>>> we actually fall into arch/powerpc/boot/crt0.S:_zimage_start(), which
>>> will call platform_init() and then bamboo_init() finally. but sounds
>>> like if we passing r3 as fdt, then the code (platform_init, etc.., and
>>> even arch/powerpc/kernel/head_xxx.S start() function, only comments,
>>> though) is actually wrong, isn't it? Thank you very much for help.
>>
>> This is the boot wrapper code only used if you are trying to boot a new
>> kernel w/an old u-boot. ?If you are using a current u-boot you should just
>> be using a plain old uImage as produced by the kernel build.
>
> do you mean the default ``uImage'' file? I'm using u-boot-2009.06, and
> I can boot successfully with cuImage.mpc8548cds (I'm actually working
> on a mpc8548 cds board), but unable to boot ``uImage'', I'm sure the
> ``vmlinux'' is the same.

Booting such a new kernel, you'll need to pass an adress of an fdt too:

=> help bootm
bootm [addr [arg ...]]
    - boot application image stored in memory
    passing arguments 'arg ...'; when booting a Linux kernel,
    'arg' can be the address of an initrd image
    When booting a Linux kernel which requires a flat device-tree
    a third argument is required which is the address of the
    device-tree blob. To boot that kernel without an initrd image,
    use a '-' for the second argument. If you do not pass a third
    a bd_info struct will be passed instead

So try "bootm <kernel> - <fdt>"

Cheers
  Detlev

-- 
"The number you have dialed is imaginary. Please rotate your phone 90
degrees and try again."
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?

[Baojun Wang]

Thank you very much, also found the method is documented the new u-boot wiki.

  Best Regards,
Wang


On Tue, Jul 14, 2009 at 7:24 PM, Detlev Zundel<dzu@denx.de> wrote:
> Hi Wang,
>
>>>> the code is from arch/powerpc/boot/cuboot-bamboo.c, and the kernel is
>>>> 2.6.30.1, the boot image I'm using is something like cuImage.bamboo, I
>>>> checked zImage.ld.S, and found that when we're running cuImage.bamboo,
>>>> we actually fall into arch/powerpc/boot/crt0.S:_zimage_start(), which
>>>> will call platform_init() and then bamboo_init() finally. but sounds
>>>> like if we passing r3 as fdt, then the code (platform_init, etc.., and
>>>> even arch/powerpc/kernel/head_xxx.S start() function, only comments,
>>>> though) is actually wrong, isn't it? Thank you very much for help.
>>>
>>> This is the boot wrapper code only used if you are trying to boot a new
>>> kernel w/an old u-boot. ?If you are using a current u-boot you should just
>>> be using a plain old uImage as produced by the kernel build.
>>
>> do you mean the default ``uImage'' file? I'm using u-boot-2009.06, and
>> I can boot successfully with cuImage.mpc8548cds (I'm actually working
>> on a mpc8548 cds board), but unable to boot ``uImage'', I'm sure the
>> ``vmlinux'' is the same.
>
> Booting such a new kernel, you'll need to pass an adress of an fdt too:
>
> => help bootm
> bootm [addr [arg ...]]
> ? ?- boot application image stored in memory
> ? ?passing arguments 'arg ...'; when booting a Linux kernel,
> ? ?'arg' can be the address of an initrd image
> ? ?When booting a Linux kernel which requires a flat device-tree
> ? ?a third argument is required which is the address of the
> ? ?device-tree blob. To boot that kernel without an initrd image,
> ? ?use a '-' for the second argument. If you do not pass a third
> ? ?a bd_info struct will be passed instead
>
> So try "bootm <kernel> - <fdt>"
>
> Cheers
> ?Detlev
>
> --
> "The number you have dialed is imaginary. Please rotate your phone 90
> degrees and try again."
> --
> DENX Software Engineering GmbH, ? ? ?MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, ?Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
>