|
From: Geert U. <ge...@li...> - 2001-10-12 08:23:31
|
---------- Forwarded message ---------- Date: Fri, 12 Oct 2001 17:32:34 +1000 (EST) From: Paul Mackerras <pa...@sa...> To: lin...@li... Subject: boot methods 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/ |