[RFC] Monster boot cleanup patch #1

[Benjamin Herrenschmidt]

Hi !

I've been working on making kexec possible the past couple of weeks,
in order to real that goal, we need to cleanup significantly the
interactions between prom_init and the rest of the kernel in order
to provide a useable entry point _after_ prom_init.

This is the first product of that cleanup. It's the minium necessary
to start working on kexec, it's not by far doing all the cleanups that
can be done though it makes a lot of them easier, see below for some
notes about this. It's also not "finished" in that sense that I don't
expect it to be merged as-is. I want to work a little bit more on it
and test it on more than just a POWER4 LPAR & a G5

First of all, prom.c is split in two: what is run in OF environment
now goes into prom_init.c, the rest is in prom.c

The root of the issue is to have prom_init() now be totally distinct
from the kernel. No global of the kernel is written, at all. Actually,
if it wasn't for some makefile munging and copying some asm functions
it uses, prom_init.c could be a completely separate link entity.

The only relationship between them is that prom_init() now calls the
kernel entry point with a pointer to a block of memory, which contains
a flattened version of the OF device tree and a map of reserved areas
of physical memory (for various reasons, it's _much_ simpler to pass
the map this way than trying to put it inside of the device-tree itself,
there's some chicken & egg stuff going on there). The format of that
stuff if quite flexible, but I'll let you look at the patch and make
your opinion.

Anything that prom_init() has to pass to the kernel is done via the
device-tree.

The result is that I ended up rewriting a good bunch of prom_init(),
changing completely the way it manages & allocates memory (I expect
things to be much more sane now). It's also a lot more simple !

On the kernel side, the two calls to stab_initialize() and stab_initialize()
that are done in real mode are replaced by a call to early_init() (which
lives in setup.c). This new function calls early_init_devtree (in prom.c)
which uses a couple of small functions in there to do a linear parsing
of the flattened device-tree. Not much is done at this point, just enough
to retreive some critical properties from the device-tree, like the
platform number, and build the LMBs. At this point, the hash size is
calculated and we can move on to stab/htab_initialize (which are called
from C code now).

Later on, in setup_system(), the flattened device-tree is converted into
the familiar pointer-based tree of struct device_node. I did some
significant shuffling & cleanup of some of the things happening at this
stage of the boot, but here again, I'll let you discover reading the
patch.

On the TODO or CAN-BE-DONE list, in no special order:

 - CONFIG_BOOTX_TEXT is not "fixed" yet

 - setup_system() should die completely. All of this can be done from
setup_arch(). Also, we should call those switch/case based on platform
and avoid having 3 or more init points in there. I think I'll just find
a way to fill up ppc_md. for the platform at early_init() time, and do
some calls through that to the init function(s) from setup_arch, trying
to shrink that to one init function if possible.

 - iSeries need to be ripped out of setup.c completely and have it's
own setup file. Too much ifdef mess & cruft that we don't want in our
feet anymore

 - CONFIG_PPC_PSERIES must become what CONFIG_PPC_PMAC is, that is a
boolean option for IBM-pSeries machine support on top of the "common"
config. A lot of code that is now in ifdef CONFIG_PPC_PSERIES should
just be moved out of the ifdef's, since it's really just !ISERIES, and
iSeries just moved to separate files.

 - Right now, I don't release the flattened device tree memory, I need
to change a few things in the way it's extracted do be able to do that.

That's all I have in mind at the moment. The patch is really too big for
an email, you'll find it at:

http://gate.crashing.org/~benh/ppc64-monster-boot-cleanup-1.diff

Enjoy !

Ben.