Subject: Re: What happens when the floppy's too big?
To: None <current-users@netbsd.org>
From: Chris Tribo <ctribo@del.net>
List: port-macppc
Date: 04/10/2001 00:46:11
on 3/24/01 6:04 PM, Bill Studenmund at wrstuden@zembu.com wrote something
like:

<snip of USB/OHCI stuff>

    And in reality, OFW 3.x users *shouldn't* be booting boot.fs anyway. As
to why they continue doing this with a nearly weekly frequency, and then
posting on port-macppc that their keyboards don't work after booting, is
beyond me. Do we need a 255 point font banner that says this is for machines
with built-in floppies only, maybe put a banner at boot in the kernel "There
is no USB support in this kernel, use netbsd.RAM.gz instead"?

>>> No. I think what we should do is something like i386, where they have
>>> INSTALL, INSTALL_LAPTOP, INSTALL_SMALL, and INSTALL_TINY. I don't think
>>> we need 4, but more than one would be good. And they have provided prior
>>> art on this. ;-)

    I suggested this earlier in the thread, but it's not so easy. See
bottom.

<snip>

> People who do CD boots need a full-blown INSTALL (the one we have
> now). And they certainly work w/ OF 3. :-) So we can make for-floppy
> (smaller) INSTALL kernels, and CD (general use) INSTALL kernels.

    Where General use = {ZIP disk, USB, FireWire, SyQuest, netboot, what
have you}
  
<snip>

> I'l admit some of this code makes me dizzy, but as long as either OF will
> let us keep the floppy device open after we eject and insert the next
> floppy, or we can close & re-open, we should be able to supprt mutliple
> floppies.

    Yes and no. You are correct that we _can_ break the install disk image
into two parts with libsa, and "that's how multi-floppy kernels load" [on
i386], that's not the problem. The problem is how do we re-assemble the two
parts and execute it on macppc. This will require either:

a.) ofwboot.{xcf,elf} to be re-written with the needed bits to copy each
disk chunk into RAM sequentially, and then boot the resulting "RAM disk"
image in OFW (as you suggested); or

b.) make a second stage booter that is loaded from ofwboot.{xcf,elf} in its
current incarnation that has support for putting the two image chunks
together and booting the actual compressed kernel/ramdisk.

c.) some type of CHRP script or OFW only booter (i.e. the MacOS ROM,
yaboot(?) )


    For some reason, I am personally in favor of b.) because it reduces the
amount of interaction and coding we have to do in OpenFirmware, which I'm
sure we can agree is pretty version & machine dependent.

<Pie in the sky> This approach also adds a little bit more leeway for
(eventual hopefully) multi-floppy boot of Non-OFW PPC's, HFS/HFS+ support in
the kernel, better support for booting a kernel not on the boot device on a
file system that OFW doesn't support (i.e. FFS/LFS/RAID/HFS(?)/UDF, etc.),
might not need OF 1.x and 2.x users to modify the Real-base, allow possible
booting a kernel from devices that don't have OFW on them. </Pie in the sky>

    One could also easily argue that it would be better to have one booter
and deal with it all in one step right in OFW.

    Is there anything else I'm missing? Am I OpenFirmware phobic?


    Chris

-- 

Murphy was an optimist.