bi_record and initrd

[Magnus Damm]

> Can you give more information about where everything is loaded up at?  I
> thought this was a non-issue, but it's been a while since I tested
> initrds.

Sure.
The first example below does not trigger the bug.
The second one shows the bug.

First example:

loaded at:     00180000 0023C1D0
board data at: 00239124 00239140
relocated to:  001852FC 00185318
zimage at:     00185880 00214ADE
initrd at:     00215000 002388D9
avail ram:     0023D000 04000000

gunzip() unzips the zimage to address 0 and sets zimage_size to 0x00148A6C.
I'm not sure about the _ALIGN() macro and how it's used, but in this case
rec gets calculated to 0x00300000.
I thought the idea was to get a address that is aligned to the nearest
1-megabyte boundary.
(2 megabyte in this case - but that would overwrite the zimage...)

anyhow, the rec at 3 megabytes is inside of the available ram - good.

this mail says something about typos or misuse of _ALIGN().
http://www.geocrawler.com/archives/3/8358/2002/9/0/9715261/

If _ALIGN() now is used correctly, then the align definition
maybe chould be changed from
#define _ALIGN(addr,size)        (((addr)+size-1)&(~(size-1)))
to
#define _ALIGN(addr,size)        (((addr)+(size)-1)&(~((size)-1)))
to make sure that size is treated correctly. Or maybe it's a feature. =)

Second example:

loaded at:     FE2226F0 FE3098C0
relocated to:  00180000 002671D0
board data at: 00264124 00264140
relocated to:  001852E8 00185304
zimage at:     00185840 001CCEAB
initrd at:     001CD000 00263A21
avail ram:     00268000 04000000

I have not been able to output the value of zimage_size for this case, but I'm
sure that my initrd gets overwritten with the bi_record at 0x00200000.
We read out the initrd memory area with a BDM debugger and compared with the
original compressed filesystem image. So rec gets set to 2 megabytes.
This results in a initrd with bad crc. If it would help you I could get the value
of zimage_size, but it's on another machine and I don't have the time today.

Another thing - why is the second argument (dstlen) to gunzip() always 4 megabytes?
Maybe it could be set to the address that the image is loaded at / relocated to?
(0x180000 above) That way the gunzip function wouldn't overwrite the running code,
if I understand the dstlen argument correctly that is.

I'm using a 2.4.18 kernel patched up to 2.4.19-pre9 with more patches to match
linuxppc_2_4 (downloaded from ppckernel.org). So if you've made any changes
recently then I don't have them. But I compared my bi_record code with the
latest code available via rsync and they look identical.

thanks /

magnus

Tom Rini wrote:
>
> On Thu, Nov 14, 2002 at 04:54:47PM +0100, Magnus Damm wrote:
>
> > The bi_record setup code in linux/arch/ppc/boot/simple/misc-embedded.c
> > doesn't care about the initrd size. So, if you are using a initrd that
> > crosses a megabyte-boundary you will have your initrd overwritten with
> > the bi_record. This results in crc error when unpacking the initrd.
> >
> > The quick fix is to add a offset to the boot-code and to
> > arch/ppc/kernel/setup.c.
> >
> > So, what's the long term solution?
> > Passing a pointer to the kernel?
>
> Can you give more information about where everything is loaded up at?  I
> thought this was a non-issue, but it's been a while since I tested
> initrds.
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/