Re: boot methods

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/