Subject: Re: What happens when the floppy's too big?
To: None <>
From: Matt Thomas <>
List: current-users
Date: 04/09/2001 23:09:19
At 12:46 AM 4/10/2001 -0400, Chris Tribo wrote:
>on 3/24/01 6:04 PM, Bill Studenmund at wrote something
><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"?

Except that netbsd.ram.gz used the INSTALL kernel as well so ...

> >>> No. I think what we should do is something like i386, where they have
> >>> 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

For 1.5.1_BETA I remove PCMCIA/CARDBUS support from the INSTALL to make
a FLOPPY.  This saved quite a bit of space.

> > 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}

That's what I've done.

> > 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 trimmed kernel and a shrunk ofwboot (no net but ustarfs) will save 

>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(?) )


Matt Thomas               Internet:
3am Software Foundry      WWW URL:
Cupertino, CA             Disclaimer: I avow all knowledge of this message