[Linuxppc-dev] boot code rework

[Peter Bergner]

Anton Blanchard wrote:
:> 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).

As I mentioned before, a zImage.initrd can get quite large so if we
try loading it below OF, we just might overlay OF with our ramdisk.
We probably only want to load yaboot below OF.  Everything else
should probably be loaded above OF.



: 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 :(

Yaboot has some special magic addresses it knows about when it attempts
to load a binary like vmlinux or zImage.  It looks at the e_entry field
in the binary's ELF header and if it's the special value KERNEL_LINK_ADDR_PPC64
(which is 0xC000000000000000ULL for us currently), then it ignores
this value and loads the binary at KERNELADDR (0x01400000).  Otherwise,
it attempts to load it at it's e_entry value.  So, if you change the
link addr to 0xC00....4000, you'll need to update the value of
KERNEL_LINK_ADDR_PPC64 in Yaboot, otherwise that's where we'll try and
load it!  Or it may just be easier to change the test from:

     if (e->e_entry == KERNEL_LINK_ADDR_PPC64) {

to:

     if ((e->e_entry & ~((Elf64_Addr)0xffffff) == KERNEL_LINK_ADDR_PPC64) {

This should allow both 0xC000000000000000 and 0xC000000000004000 to
work with Yaboot.



: 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 don't think hard coding the addr is a good thing.  Particularly since
we've seen some machines (Condor?) where the 20M area was already claimed
and not available.  We had to add hacks in Yaboot to work around this
when loading a vmlinux...



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

I think we need to know a little more than that.  We need to know
what memory has been claimed.  This includes OF, but on some of the
Condor boxes, we've seen other areas at or around 20M that were also
being claimed.  I'm not sure exactly what they were/are used for, but
I'm guessing OF was using it for something.  We don't' want to stomp
on that either.



: 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 hesitate to rely on OF's claim/free code.  I seem to recall that
there is a limit to how much information it can remember.  I'd feel
better if we determine what is claimed when we first start up and
then handle all our own allocations/frees ourselves.

My thoughts on how this should work is:

  1) Boot into zImage from either yaboot or OF.
  2) 32-bit zImage code should be compiled fully relocatable
     similar to paulus' prom.c changes to ppc32 kernel.
  3) Allow yaboot to load the zImage wrapper anywhere it can
     find space, rather than using it's e_entry value in case
     that space it already claimed.  Prefer addrs above OF.
  4) zImage code will make _all_ OF calls, so will need to pass
     information like device tree, claimed memory, RTAS addr/size
     and others to the kernel via birecs.
  5) Have the zImage code relocate the kernel to phys addr 0...
     rather than having the kernel do it.
  6) Early kernel code still runs relocate off, but since realmode
     ignores the upper addr bits, no RELOC needed.
  7) rm arch/ppc64/kernel/prom.c  :)

Did I forget anything???


Peter


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