Re: [Etherboot-developers] NIC file and ROM images

[<ja...@Mc...>]

Interesting thread about the multiple PCI headers in a
bootrom.

I realize this would take alot of reworking how an
Etherboot bootrom image is put together, but I'm thinking
that much of the code in bootrom is common code that
is used in all bootroms.  That is, the tftp, dhcp/bootp,
main, and probably more.

Concatenating the bootrom images would just duplicate the
same code over and over again.

I don't know what the ratio of unique code to common code
is, but it seems like it is far more common code than unique.

What if you (we) could build a bootrom that knows about ALL
pci network chipsets.

It would start with a whole bunch of 512 byte PCI headers.
Followed by the main() and other common code,  Then, the 
unique routines that each card needs. I don't know how big
that is, but it seems pretty small, per chipset.

I use 29ee512 chips for the Linksys and 3Com cards, 
I'll bet we could fit support for a lot of chipsets into 64k.

Well, it's just a random thought.

Thanks,

Jim McQuillan
ja...@Lt...


On Thu, 18 Apr 2002, Ken Yap wrote:

> >That wouldn't have worked because I wasn't using that checksum
> >algorightm.  Ever since playing with BASIC I'm alergic to using
> >programming languages where you must use the builtins to get
> >performance.
> 
> Well then the answer would have been one of the following:
> 
> Find a CPAN module that does what you want. E.g. there's a MD5 module.
> Write an extension in C.
> Don't use Perl
> 
> Perl doesn't cover all applications, but it's perfectly adequate in many
> places where you't think only C will do the job, e.g. mknbi which does
> binary manipulations and a streaming video server. It may be a long time
> before we see an Etherboot in Perl though.
> 
> >What is clear is that you can have multiple rom images, with their
> >own rom header on a 512 byte boundary.  What I don't know yet is
> >if the rom scan algorithm supports those images overlapping.
> 
> I don't think the header has any "data offset" fields, the body just
> follows the header.
> 
> >If they can overlap it is probably worth doing, without the ability
> >to overlap we can just make certain etherboot rom images are in
> >multiples of 512 bytes and concat rom images together if there are
> >big enough roms.
> 
> That's easy, just concatenate the ROM images. At the moment they aren't
> as small as they could be because they are padded out to the next power
> of 2, but an additional option could allow them to be padded to the next
> block only.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

--