[U-Boot] Coldfire: bootm: How does bootm pass bootargs to linux?

[U-Boot] Coldfire: bootm: How does bootm pass bootargs to linux?

[Richard Retanubun]

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=8f849c3f31ce3f0c3f257ca5e21eaf8f9fdc7239

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,@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 at 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    ............. at ..
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>

[U-Boot] Coldfire: bootm: How does bootm pass bootargs to linux?

[TC Liew]

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

[U-Boot] [PATCH] Cleanup the comment for m68k linux boot argument passing.

[Richard Retanubun]

 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 */
-- 
1.5.6.5

[U-Boot] [PATCH] Cleanup the comment for m68k linux boot argument passing.

[Mike Frysinger]

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

[U-Boot] [PATCH] Cleanup the comment for m68k linux boot argument passing.

[Richard Retanubun]

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

[U-Boot] [PATCH V2] Cleanup the comment for m68k linux boot argument passing.

[Richard Retanubun]

 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 */
-- 
1.5.6.5

[U-Boot] [PATCH V2] Cleanup the comment for m68k linux boot argument passing.

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090220/f9fe7326/attachment.pgp 

[U-Boot] [PATCH V2] Cleanup the comment for m68k linux boot argument passing.

[Richard Retanubun]

 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 */
-- 
1.5.6.5

[U-Boot] [PATCH V2] Cleanup the comment for m68k linux boot argument passing.

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Where there's no emotion, there's no motive for violence.
	-- Spock, "Dagger of the Mind", stardate 2715.1