On Tue, 21 Dec 1999, Andrew Gillham wrote:

> Yeah, this is going to be a problem.  A 64K ROM size is sort of ideal
> I guess, unless some sort of compression hack is used.  It would be nice
> to have something like this:
> |---------------|
> | decompressor  |
> | (xx K bytes)  |
> |---------------|
> | actual ROM    |
> | or just raw   |
> | code. gzip -9 |
> | compressed.   |
> |---------------|

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

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.

http://www.slug.org.au/etherboot/

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.


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. 
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.
 o if later on someone wants to improve the code in more complicated ways,
   he or she will have a much easier development cycle.
 o the load-and-jump-to-another-ROM code might help people who wanted to
   do compression.

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

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.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US