[U-Boot] Coldfire: bootm: How does bootm pass bootargs to linux?
Hello,
I am using u-boot 2009.01 and linux kernel 2.6.27 from kernel.org compiled for MCF5271 tested using the M5271EVB eval board.
I am trying to pass kernel boot arguments and initrd from u-boot to the kernel.
There is a patch on the DENX-linux-2.6 http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=8f849c3f31ce3f0c3f257ca5...
that I am using as a starting point. This implementation assumes that u-boot passes the arguments beginning from the stack pointer as such
/* * U-Boot calling convention: * theKernel (linux_argc, linux_argv, linux_env, 0); */
Meanwhile, in the bootm command comments for $u-boot/lib_m68k/bootm.c says this /* * Linux Kernel Parameters (passing board info data): * r3: ptr to board info data * r4: initrd_start or 0 if no initrd * r5: initrd_end - unused if r4 is 0 * r6: Start of command line string * r7: End of command line string */
But based on the probing I did (notes below), I don't think the bootm implementation for coldfire is passing arguments to the kernel using either of these methods.
My question is, how does bootm passes arguments to the kernel for the coldfire (M5271 specifically)? And what is the recommended way to capture and process the info in the kernel?
Thank you for all your time.
- Richard Retanubun.
=======================================================================================
<verbose debug notes>
Since the coldfire does not have rN (it has d[0:7] and a[0:7]) -unless I misunderstood someting- I read this as meaning that the args in the list are passed in one of the d[0:7] or a[0:7]. I saved what the initial values of d[0:7] and a[0:7] (using the same method of how _init_sp is saved in the patch) at the _start routine of the kernel so I can print them later.
Putting the experiment in practice <<
U-Boot 2009.01dvl-00300-ga86ef03-dirty (Feb 13 2009 - 10:45:18)
CPU: Freescale ColdFire MCF5270 rev. 1, at 150 MHz Board: Ruggedcom MCF5270 I2C: ready DRAM: 8 MB FLASH: 4 MB In: serial Out: serial Err: serial MAC: ethaddr 00:00:00:00:05:00 Net: FEC0 [PRIME] => imls Legacy Image at FFC40000: Image Name: uImage Image Type: M68K Linux Kernel Image (gzip compressed) Data Size: 747665 Bytes = 730.1 kB Load Address: 00020000 Entry Point: 00020000 Verifying Checksum ... OK => bootm ffc40000 ## Booting kernel from Legacy Image at ffc40000 ... Image Name: uImage Image Type: M68K Linux Kernel Image (gzip compressed) Data Size: 747665 Bytes = 730.1 kB Load Address: 00020000 Entry Point: 00020000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## cmdline at 0x007877a0 ... 0x007877bd ## Transferring control to Linux (at address 00020000) ... Linux version 2.6.27-00004-g286c2cc-dirty (rr@rcws-214) (gcc version 4.1.1) #10 Fri Feb 13 08:53:36 EST 2009
The regval at init output <<
0017bd1c D _init_d0 00000000 0017bd20 D _init_d1 ffffffff 0017bd24 D _init_d2 007f99b8 0017bd28 D _init_d3 00000000
0017bd2c D _init_d4 00000000 0017bd30 D _init_d5 007f7454 0017bd34 D _init_d6 00000002 0017bd38 D _init_d7 00797f88
0017bd3c D _init_a0 007dbc04 0017bd40 D _init_a1 007ebbec 0017bd44 D _init_a2 00020000
0017bd48 D _init_a3 007f992c 0017bd4c D _init_a4 00000000 0017bd50 D _init_a5 007f5000 0017bd54 D _init_a6 00787cb8 0017bd58 D _init_a7 00787c74
0017bd5c D _init_sp 00787c74
/end of debug <<
Unless I am missing something, none of these matches the r3-r7 notation.
The only further trace is this:
md 00787c74 << Printing the address pointed to by the stack pointer. 00787c74: 007eee96 00787760 00000000 00100000 .~...xw`........ 00787c84: 00787cd4 00787c98 007e34d2 00000034 .x|..x|..~4....4 00787c94: 00000001 00787ca8 007e8d84 00787cd4 .....x|..~...x|. 00787ca4: 007f5000 00787cb8 007e8eb6 00000001 ..P..x|..~...... 00787cb4: 00787cd4 00787dec 007e8f2a 00787cd4 .x|..x}..~.*.x|. 00787cc4: 00787cd4 007f48c9 00787df8 00000034 .x|...H..x}....4 00787cd4: 340099b8 00020000 00176000 80000000 4.........`..... 00787ce4: 00000000 007988e0 00000002 007f7454 .....y........tT
The 2nd longword after the stack looks promising ...
md 00787760 00787760: 00000000 00800000 ffc00000 00400000 .............@.. 00787770: 00000000 20000000 00001000 40000000 .... .......@... 00787780: 00000000 00787f88 00000000 00000000 .....x.......... 00787790: 0500000a 08f0d180 047868c0 0001c200 .........xh..... 007877a0: 636f6e73 6f6c653d 24636f6e 736f6c65 console=$console 007877b0: 6465762c 24626175 64726174 65000000 dev,$baudrate... 007877c0: 0078f930 ffffffff 00000012 007879ba .x.0.........xy. 007877d0: 00000008 00000059 00000041 00787890 .......Y...A.xx.
Hey, the first 64-bytes is the board info structure followed by the bootargs!
Now does this mean that we should save the 00787760 address at kernel start, then offset it by 64-bytes? or am I missing the mechanism of passing the r3-r7 arguments as mentioned in the comments?
</verbose debug notes>
Richard,
/*
- Linux Kernel Parameters (passing board info data):
- r3: ptr to board info data
- r4: initrd_start or 0 if no initrd
- r5: initrd_end - unused if r4 is 0
- r6: Start of command line string
- r7: End of command line string
*/
Above is the copy and paste from PPC.
My question is, how does bootm passes arguments to the kernel for the
coldfire In ColdFire, the Linux Kernel Parameters is located at u-boot's stack.
(M5271 specifically)? And what is the recommended way to capture and
process the info
in the kernel?
In kernel/head.S, Save the location of u-boot info - cmd line, bd_info, etc movel %a7, uboot_info_stk /* save uboot info to variable */
In kernel/setup.c, unsigned long uboot_info_stk; EXPORT_SYMBOL(uboot_info_stk); static struct uboot_record uboot_info;
int __init uboot_comandline(char *bootargs) { ... uboot_info.bd_info = (*(u32 *)(uboot_info_stk)); uboot_info.initrd_start = (*(u32 *)(uboot_info_stk+4); ... }
Regards, TsiChung
From e2e085f8b8e638762c59b0bc5376b241b0046132 Mon Sep 17 00:00:00 2001 From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing.
Signed-off-by: Richard Retanubun RichardRetanubun@RuggedCom.com --- Hi Tsi-Chung,
Thanks for the response, I found the solution after using a hw debugger to step through the code. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which puts the next instruction after the jsr into the stack pointer so there is an 'off-by-one' effect from the stack pointer.
This patch cleans up the comment to clarify the boot arg passing. I'll try to push a patch for the kernel as well.
Thanks for your time
lib_m68k/bootm.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) mode change 100644 => 100755 lib_m68k/bootm.c
diff --git a/lib_m68k/bootm.c b/lib_m68k/bootm.c old mode 100644 new mode 100755 index 0798e07..958c5ce --- a/lib_m68k/bootm.c +++ b/lib_m68k/bootm.c @@ -111,11 +111,12 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
/* * Linux Kernel Parameters (passing board info data): - * r3: ptr to board info data - * r4: initrd_start or 0 if no initrd - * r5: initrd_end - unused if r4 is 0 - * r6: Start of command line string - * r7: End of command line string + * sp+00: Ignore, side effect of using jsr to jump to kernel + * sp+04: ptr to board info data + * sp+08: initrd_start or 0 if no initrd + * sp+12: initrd_end - unused if initrd_start is 0 + * sp+16: Start of command line string + * sp+20: End of command line string */ (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end); /* does not return */
On Friday 20 February 2009 11:34:06 Richard Retanubun wrote:
From e2e085f8b8e638762c59b0bc5376b241b0046132 Mon Sep 17 00:00:00 2001 From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing.
Signed-off-by: Richard Retanubun RichardRetanubun@RuggedCom.com
Hi Tsi-Chung,
Thanks for the response, I found the solution after using a hw debugger to step through the code. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which puts the next instruction after the jsr into the stack pointer so there is an 'off-by-one' effect from the stack pointer.
This patch cleans up the comment to clarify the boot arg passing. I'll try to push a patch for the kernel as well.
comments for the changelog go above the ---, not below
use git and put it into the commit message: $ git commit --amend blah blah the patch summary
a paragraph about the changes .... -mike
Hi Mike,
wow, that a more rapid response that I am used to :)
Mike Frysinger wrote:
On Friday 20 February 2009 11:34:06 Richard Retanubun wrote:
From e2e085f8b8e638762c59b0bc5376b241b0046132 Mon Sep 17 00:00:00 2001 From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing.
Signed-off-by: Richard Retanubun RichardRetanubun@RuggedCom.com
Hi Tsi-Chung,
Thanks for the response, I found the solution after using a hw debugger to step through the code. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which puts the next instruction after the jsr into the stack pointer so there is an 'off-by-one' effect from the stack pointer.
This patch cleans up the comment to clarify the boot arg passing. I'll try to push a patch for the kernel as well.
comments for the changelog go above the ---, not below
Yep, I thought this is what I did, the commit message is
"Cleanup the comment for m68k linux boot argument passing."
The stuff under the --- Is just continuing a conversation thread. I tend to keep the commit message short and be more verbose in the code comments.
use git and put it into the commit message: $ git commit --amend
Thanks for the tip. I'll submit a V2.
blah blah the patch summary
a paragraph about the changes .... -mike
From d1e6b372d1781f15f1042fa379562f85c873405a Mon Sep 17 00:00:00 2001 From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which pushes the program counter for the instruction after the jsr into the stack pointer.
Signed-off-by: Richard Retanubun RichardRetanubun@RuggedCom.com --- V2: Now with more verbose commit message :)
lib_m68k/bootm.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) mode change 100644 => 100755 lib_m68k/bootm.c
diff --git a/lib_m68k/bootm.c b/lib_m68k/bootm.c old mode 100644 new mode 100755 index 0798e07..958c5ce --- a/lib_m68k/bootm.c +++ b/lib_m68k/bootm.c @@ -111,11 +111,12 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
/* * Linux Kernel Parameters (passing board info data): - * r3: ptr to board info data - * r4: initrd_start or 0 if no initrd - * r5: initrd_end - unused if r4 is 0 - * r6: Start of command line string - * r7: End of command line string + * sp+00: Ignore, side effect of using jsr to jump to kernel + * sp+04: ptr to board info data + * sp+08: initrd_start or 0 if no initrd + * sp+12: initrd_end - unused if initrd_start is 0 + * sp+16: Start of command line string + * sp+20: End of command line string */ (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end); /* does not return */
On Friday 20 February 2009 12:22:46 Richard Retanubun wrote:
From d1e6b372d1781f15f1042fa379562f85c873405a Mon Sep 17 00:00:00 2001 From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which pushes the program counter for the instruction after the jsr into the stack pointer.
there has to be a new line between the summary and the explanatory paragraph, otherwise the entire text is used as the subject ... as for the actual content, i have no comment as i dont know m68k at all ;) -mike
From 4adb975b29acdd64e7ea37f3d8ecd14d77c844b4 Mon Sep 17 00:00:00 2001 From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing.
This patch clarifies the way m68k passes linux boot argument. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which pushes the program counter for the instruction after the jsr into the stack pointer.
Signed-off-by: Richard Retanubun RichardRetanubun@RuggedCom.com --- V2.1: Now with more lines :)
lib_m68k/bootm.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) mode change 100644 => 100755 lib_m68k/bootm.c
diff --git a/lib_m68k/bootm.c b/lib_m68k/bootm.c old mode 100644 new mode 100755 index 0798e07..958c5ce --- a/lib_m68k/bootm.c +++ b/lib_m68k/bootm.c @@ -111,11 +111,12 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
/* * Linux Kernel Parameters (passing board info data): - * r3: ptr to board info data - * r4: initrd_start or 0 if no initrd - * r5: initrd_end - unused if r4 is 0 - * r6: Start of command line string - * r7: End of command line string + * sp+00: Ignore, side effect of using jsr to jump to kernel + * sp+04: ptr to board info data + * sp+08: initrd_start or 0 if no initrd + * sp+12: initrd_end - unused if initrd_start is 0 + * sp+16: Start of command line string + * sp+20: End of command line string */ (*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end); /* does not return */
Dear Richard Retanubun,
In message 499EF014.4030908@RuggedCom.com you wrote:
From 4adb975b29acdd64e7ea37f3d8ecd14d77c844b4 Mon Sep 17 00:00:00 2001
This line should NOT be indented.
From: Richard Retanubun RichardRetanubun@RuggedCom.com Date: Fri, 20 Feb 2009 11:06:36 -0500 Subject: [PATCH] Cleanup the comment for m68k linux boot argument passing.
This patch clarifies the way m68k passes linux boot argument. The one gotcha here is that the assembly instruction that the compiler uses to jump to the kernel is 'jsr' which pushes the program counter for the instruction after the jsr into the stack pointer.
Signed-off-by: Richard Retanubun RichardRetanubun@RuggedCom.com
V2.1: Now with more lines :)
lib_m68k/bootm.c | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) mode change 100644 => 100755 lib_m68k/bootm.c
Thanks, applied (after manually fixing the commit message).
Best regards,
Wolfgang Denk
participants (4)
-
Mike Frysinger -
Richard Retanubun -
TC Liew -
Wolfgang Denk