[Linuxppc-dev] boot code rework

Anton Blanchard anton at au1.ibm.com
Wed Jun 12 22:14:50 EST 2002



> Only problem I see is that the zImage can be quite large if
> we have an attached ramdisk/initrd.  We might want to think
> about linking it above OF too.

Agreed. I had a rethink about it today and my current tree does:

1. yaboot and the zImage wrapper operate as normal, ie they load
somewhere below OF and load the kernel above OF (say 20MB or higher).

2. The first thing the kernel does is relocate down to 0x4000 and
then jumps into it.

This allows the current yaboot to work. Unfortunately I had to make
one change, I was linking the vmlinux at 0xc....4000 so that in theory
a loader could load it at its final physical address. However this
confuses yaboot (possibly because the ELF rules say you should have
things on a 64kB alignment).

In the end I had to link at 0xc...0000 to keep yaboot happy. This
means there is 16k of zeroes where the exception vectors should be and
if we were loaded into our final position we'd overwrite the OF
vectors :(

Now the final thing is to find a place for RTAS. At this stage we've
claimed all over the place (above and below OF) and havent freed
the memory, so I made the arbitrary decision to use our original load
address (ie 20MB or so) as the RTAS area :)

Ive tested this on a p690 that was having problems and it seems OK
(it uses yaboot). I need to build a massive kernel (say 9MB big) and
see if it still works.

> I can make yaboot do whatever we need it to do! :)  Yaboot just loads the
> zImage LOAD segments where the zImage program header tells it to.  If you
> want it to load somewhere else, we just need to update arch/ppc64/boot/
> files to put it somewhere else.  No changes to Yaboot should be required.
> Since the zImage wrapper is tightly connected to the kernel, we can make
> any changes we want to it and not have to worry about backward
> compatability.

OK, if we are going to go the zImage direction in yaboot we can probably
clean it up some more. Any suggestions for the best place to lay all
this out? We have OF, RTAS, birecs, initrd, kernel image (anything
else??) to look out for. I was thinking it would be nice to claim
and free memory in OF as we go but they may turn out to be too much
work.

I guess all we really need to know is where OF starts and finishes
since everything else is ours for the taking (I hope).

> The plan is to also move to requiring booting a zImage rather than a
> vmlinux,
> but we haven't done this yet...  I'm not sure whether you forward ported
> our latest 2.4.X zImage changes, but that would be good to have in 2.5.X.
> I'm including the entire vmlinux in it's own elf section so it can now be
> extracted with objcopy.  Before, we stripped the elf header so you couldn't
> objdump the extracted vmlinux.

I havent yet but it was on my list of things to do.

Anton

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





More information about the Linuxppc64-dev mailing list