Miles Nordin writes:
> 
> This is the problem I ran into when I looked at it.  The ROM and card I
> have available for now are 16kB max.

This is pretty tight. :-) 

> You might be able to backport the Linux ROM compression code--they based
> their bootroms on ours, and then added compression.  Their decompressor is
> only about 1.5kB, and they claim it will compress well enough to break
> even on an 8kB ROM. Indeed, I use an 8kB ROM right now, and it does.  I
> was using Etherboot 4.0.

Just looking at the assembler versions of the lzo decompressor, it *looks*
like it would be about 1.7K or so.  I may have my math wrong though.

The lzo author also has a 'NZR' compression that apparently has an assembler
decompression needing about 100 *bytes*, or 200 *bytes* for the fast version.
This isn't available under the GPL like the lzo code though.

> Compression is critical for them, because they use gobs of layered
> real-mode code.  Some of their notBSD ROMs are like 32kB and include DOS
> packet driver .COM files cat'ed into them.  I don't know if this is the
> state-of-the-art, but remember being amused by the idea.  They seem to
> have good compression, but maybe that lzo stuff is just as good.

This is kind of interesting, and would allow much wider support, but it
is not really what I am looking for.  From looking at their code they
have a buffer problem with their decompressor, that limits it to under
32k of code. (at least from my reading of the docs)

> 
> Another thing to consider is using a two-stage boot process like every
> other NetBSD port.  The first stage could simply load <IPAddr_in_hex>.i386
> via TFTP.  That way, things like NFS, Direct Serial, boot parameter
> structures, could be left out of stage 1, and maybe it would fit in 16kB
> again.  There is, for example, not quite so much need for serial console
> in Stage 1 since it's not yet time to enter a kernel name and parameters. 

I agree that two stages would be much better.  Then a ROM could get by
with BOOTP/TFTP, or RARP/TFTP and still load the kernel via NFS, have the
ability to switch to a serial console on command, etc. (and have a
fairly expanded set of commands)

For myself, I would like to have pseudo Open Firmware type functionality
*burned in* (or stuffed into my Award BIOS), to provide more flexible and
robust options:
	- switchable console (serial <-> VGA/BIOS)
	- ability to load from network or BIOS devices
	- mini-fdisk (or at least active partition changer)
	- mini-dd (or just ability to zero the @#$&@ MBR, part of above?)
	- load kernels, or stage 2 bootloaders/programs.
	  (e.g. standalone fdisk, standalone 'dd if=/net/blah of=bios(0,1)')

Right now I'm just dreaming though.  My first goal is to reliably(*) be able
to have a nice fast PII or Celeron box with no video or hard drive, an ok
NIC and a serial console.  Then I can get my cluster built, and running
stable. :-)

(*) I am trying to get to the point where clear the CMOS will still allow
the machine to boot far enough to activate netboot.rom, and to have a good
10/100 NIC that can netboot fairly quickly/reliable via DHCP.  Currently
my SMC Ultra (10Mbps) seems flakey. (could easily be the card)
The CMOS issue is a bit tricky, but I'm hoping to figure out how to set
the 'halt on errors: none' option permanently in my BIOS via 'MODBIN' or
something.  So if the CMOS is trashed, the BIOS *should* keep going.

> Then you get your full 64kB in Stage 2.  This is also good because:
> 
>  o you can play with more #define's before you must resort to reburning
>    the chip.

Yup, and mistakes don't require turning off the machine, removing an
expansion board, or the system BIOS, and reflashing, etc.

> I'd love to have a go at all this, but I'd love even more for someone else
> to do it :).

I feel the same way. :-)

> In my opinion it's kind of sad that this architectural stupidity is
> consuming anyone's time, and think we should solve this problem simply or
> not at all.  The real way to fix network booting problems is to replace
> the defective computer--we have that luxury.

Ha!  Show me a faster, architecturally "better" machine for less(*).
Oh, and should I say it really needs to be able to play Quake III Arena
at decent speeds on my TNT2 Ultra? (oh, I already said "faster")

(*) and I might even allow a several $$$ "better" adjustment.

:-) :-)

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | This space left blank
gillham@whirlpool.com                     | inadvertently.
I speak for myself, not for my employer.  | Contact the publisher.