boot methods

[Val Henson]

Gemini:
	zImage.gemini loaded with Smon

We already have a zImage wrapper to translate things between Smon
format and the current kernel format.  No constraints to freedom on
Gemini's account.

Sorry for the late response.

-VAL

On Fri, Oct 12, 2001 at 05:32:34PM +1000, Paul Mackerras wrote:
>
> I would like to make a complete list of the methods people use to boot
> the PPC/Linux kernel on different platforms.  As a start, here is what
> I can think of off the top of my head:
>
> Powermac:
> 	vmlinux loaded with BootX
> 	vmlinux loaded with quik
> 	vmlinux loaded with yaboot
> 	vmlinux.coff loaded via OF netboot
> 	vmlinux.elf-pmac loaded via OF (disk or net boot)
>
> RS/6000 CHRP:
> 	vmlinux loaded with yaboot
> 	zImage.chrp-rs6k loaded via OF netboot
>
> RS/6000 43p-140:
> 	zImage.prep loaded via OF (floppy or hard disk)
>
> Can others contribute entries to this list please?
>
> I am particularly interested in the cases where the kernel vmlinux
> binary is loaded directly from some external software, because those
> are the cases that constrain our freedom to choose how information
> gets passed in to the kernel.  From a long-term maintainability
> viewpoint, it would be better if we could say that we always have a
> zImage-style wrapper, because then we could change the interface
> between the wrapper and the kernel at will without breaking anything.
> It would then be up to the wrapper to do any translation needed
> between what the external software passed in to it and what the kernel
> is expecting.
>
> Along those lines, I have been thinking that it would be good if the
> wrapper built a data structure describing the hardware in the system,
> particularly things like:
>
> - the amount of RAM and any holes
> - type and register addresses for PCI host bus adaptors
> - ditto for interrupt controllers
> - interrupt mapping
>
> The open firmware device tree does a good job of describing things
> like this, so I would suggest it as the structure.  Whatever structure
> we use needs to be flexible and open-ended rather than only describing
> a fixed set of things, as well as being easy to traverse and
> interpret (so I don't think prep-style residual data is an option).
>
> Thoughts?
>
> Paul.
>

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