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