Re: Second round of powerpc subarch investigation : boot-loaders.
On Mon, Oct 20, 2003 at 11:10:21AM -0700, Tom Rini wrote:
> On Sun, Oct 19, 2003 at 11:29:38AM +0200, Sven Luther wrote:
>
> > Hello,
> >
> > In order to continue work on making debian-installer subarch friendly, i
> > now launch a second round of investigation concerning the way different
> > subarches boot. The situation as i understand it is :
> [snip]
> > prep: no idea. yaboot doesn't work, nor does quik. There is no OF, but i
> > think some kind of direct booting as well as netbooting is available.
> > kernel with builtin initrd should work.
>
> Boots from the firmware the zImage*.prep from arch/ppc/boot/images in
> the kernel. To build a ramdisk into this, the ramdisk to be used is
> placed at arch/ppc/boot/images/ramdisk.image.gz, and 'make
> zImage.initrd' is issued. This file is used on all PReP systems, and
> the command to boot varries from Motorola to IBM PReP machines (Motorola
> has PPCBug, and for disk it's pboot ...., and 'help pboot' should
> describe the arguments, for netboot, 'help niot' or 'help noit', I
> forget which and 'nbo' to get and boot the kernel.
Ok, so you only need the zImage.initrd or the zImage (which is renamed
to /boot/vmlinuz-2.4.22-powerpc on debian).
both these methods (PPCBug ot pboot) are OF tools, not something you
need to/can take steps to install from the linux side.
> In general, to embed an initrd into an image (.coff, etc) the image must
> be at arch/ppc/boot/images/ramdisk.image.gz and then 'make
> zImage.initrd'.
Yep, i know, the problem is that the initrd must contain some kernel
modules, which are built during the kernel build phase, so it is not
possible to build the initrd before the kernel, nor it is possible to
build the kernel before the initrd, so ...
> > 2) We develop a separate tool (like sparc's piggyback i was told)
> > which is able to add a initrd onto an existing kernel.
>
> As the images used, prior to additional tools being run on them (such as
> mkprep) use an ldscript to determine locations, this might be possible.
Mmm, i think it may be possible to create such a tool, altough i have
the feeling that it must be built from the kernel sources maybe (since
there is no need to duplicate the code for it already found in the
kernel) and that it needs to be done differently for prep, chrp and
pmac. Don't know if chrp-rs6k is different from chrp though.
Friendly,
Sven Luther
Reply to: