boot methods

[Michael Sokolov]

Paul Mackerras <paulus at samba.org> wrote:

> There is improvement because you can have a separate wrapper for each
> firmware, if necessary.  At present if we want to change the way
> information is passed into the kernel, we have to synchronously change
> several different firmware/booter implementations, which are
> maintained in separate places by separate people.  The list includes
> (at least) BootX, miboot, yaboot, PPCBoot, and Michael Sokolov's VAX
> console.  This is a logistical nightmare.  Just getting the updates
> into the firmware/booters is bad enough, but then you create problems
> for users who then can't boot old kernels with the new firmware or new
> kernels with the old firmware.

Just for the record, in my case there is no problem with either getting the
changes into the Linux booter or new and old kernels coexisting. My firmware,
which is indeed a VAX console clone for PPC, knows absolutely nothing about how
to boot Linux or any other OS, just like the real VAX console. Just like the
real VAX console, it hands the problem of booting the user's OS of choice to
the OS vendor. To boot Linux I have an entity called ppc-linux-boot, which is
completely free, maintained in public CVS, and not tied to or controlled by SBS
or any other hardware/firmware vendor.

As ppc-linux-boot is free, public, and independent of the SBS firmware, there
can no problem with people changing it any way they want. It is not part of the
system ROM, it is a user-installed utility stored in the user console store, so
any user can easily and legitimately change it whenever s/he likes without
needing any blessing from the hardware manufacturer, and can use experimental
versions hacked by anyone in the world if s/he likes.

When the vmlinux boot interface changes for a platform supported by ppc-linux-
boot, I'll change runlnx (the part of ppc-linux-boot that actually transfers
control to vmlinux) accordingly. I can make the new version support both old
and new kernels by having a boot flag (the user always has to set the correct
boot flags anyway) select the kernel boot interface.

> The reason that nothing has been done is precisely because it is so
> hard at present to change the way that information is passed into the
> kernel, because we still boot the vmlinux directly in some situations.

But currently the vmlinux boot interface is defined per platform: the generic
code passes the initial R3-R7 to platform_init(). It should be possible for a
board port maintainer to change this interface in his/her port without
affecting anyone else.

> If we absolutely *have* to boot a vmlinux directly without a wrapper,
> then probably the best thing is to use bi_recs and pass in a pointer
> to them, since that is reasonably flexible and can be made to be
> forwards and backwards compatible without too much pain.

Yes, and I'm looking forward to usable bi_recs.

> Changing to
> this scheme is going to cause considerable pain in the short term,
> though.

Not at all. Here's how you can make it painless. In arch/ppc/kernel/setup.c
change the division of labor between machine_init and parse_bootinfo. Move the
current logic for locating bi_recs in memory from parse_bootinfo to
machine_init, passing the pointer to bi_recs to parse_bootinfo() as an
argument. Then new board ports can be designed with a bi_recs interface instead
of the current traditional one by doing something like parse_bootinfo(r3) in
platform_init. Existing ports can be converted gradually as their users work
out the transition. I would gladly change the SBS board ports. In fact, one
should first check if the current memory-based bi_recs are being used by anyone
at all. If they aren't, change parse_bootinfo() to take a pointer, remove its
invokation from machine_init altogether, and leave it up to subarch maintainers
to call it from their platform_init's when they are ready to change. Or if the
current memory-based bi_recs are only used on CONFIG_ALL_PPC, do the same but
put the code for locating them and calling parse_bootinfo() in pmac_init,
prep_init, and chrp_init for now. This would have zero impact on CONFIG_ALL_PPC
users while clearing the way for board port maintainers to convert to bi_recs
individually when they are ready.

--
Michael Sokolov				5791 VAN ALLEN WAY
Software Engineer			CARLSBAD CA 92008-7321 USA
SBS Technologies, Inc.			Phone: +1-760-438-6900 x2347
Communications Products			    or  1-888-SBS-COMM x2347
					Fax:   +1-760-438-6985
					E-mail: msokolov at sbs.com
					     or msokolov at ivan.Harhan.ORG

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