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>