[U-Boot] [help] how does u-boot passing ``fdt'' to linux kernel & where is cmd_line?
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
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
On Mon, Jul 13, 2009 at 10:27 PM, Kumar Galagalak@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
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
On Mon, Jul 13, 2009 at 10:53 PM, Kumar Galagalak@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
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
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 Zundeldzu@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@denx.de
participants (3)
-
Baojun Wang -
Detlev Zundel -
Kumar Gala