bootloader & head.S weirdness (patch)

[Benjamin Herrenschmidt]

On Tue, Nov 23, 1999, Cort Dougan <cort at fsmlabs.com> wrote:

>Do you keep the list around after the initialization?  We do something
>similar with the prep residual data but after we grab what we want we free
>the RAM. 

As I just wrote to Cort, we already have something for that on PPC, it's
the device tree. Having a tagged data structure _and_ a device tree looks
to me like having twice the same things (humm .. almost).

If we remove all the prom_init stuff from the kernel, we can simplify
kernel entry by always entering the kernel with a known MMU state (let's
say OFF) and with one parameter: the offset from _start to the device
tree image.

Non-OF machines can easily build a very simple tree with the various
residual datas from the bootloader and Mac/CHRP machines can have the
kernel image appended to a bootloader that fills the device tree from OF
and adds whatever supplementary stuffs we need (initrd, cmd_line, ...) to
the tree in a given node.

There are two things not yet clear to me with this scheme:

 - We'll need to have RTAS instanciated at a fixed address choosen by the
bootloader. I don't think it's a problem if the bootloader puts it as
high as possible in memory, but it would have been better to have the
kernel have control on it. But we can live with this limitation

 - on SMP machines, the other CPUs must be started by OF code. That means
that the bootloader must also start them in an idle loop. I beleive the
code for the idle loop can be in the device tree too with all the infos
required by the kernel to take over.

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