boot methods

Val Henson val at
Wed Oct 17 09:49:35 EST 2001

	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.


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

More information about the Linuxppc-dev mailing list