etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] 3c515 driver committed

[<ke...@us...>]

>I committed the 3c515 driver to the cvs this morning.  The following 
>files were added:
>
>3c515.c
>3c515_isapnp.h
>3c515.txt
>
>It also required changes to:
>
>Makefile
>NIC
>cards.h
>config.c

Thanks for that. I've also checked in a bunch of changes I had been
holding onto.

[Etherboot-developers] 3c515 driver committed

[Timothy L. <tl...@ro...>]

Hi

I committed the 3c515 driver to the cvs this morning.  The following 
files were added:

3c515.c
3c515_isapnp.h
3c515.txt

It also required changes to:

Makefile
NIC
cards.h
config.c


ISA Plug and Play (ISAPNP) support has been added for Non-PNP Bioses.  The ISAPNP code
requires the defination of ISA_PNP as:

#define ISA_PNP

Issues:
=======
1) When ISA_PNP is defined, the etherboot probe is unable to find the card during the first probe.
This is true even though the ISA PNP code actually found and activated the card

2) When ISA_PNP is defined, the etherboot probe finds the incorrect MAC address for the card.
However, when the linux kernel boots and loads the linux 3c515 driver the correct MAC address is found.
This means that with ISA_PNP defined, you require both MAC addresses defined in the /etc/dhcpd.conf
file.  The first MAC address allows the driver to load the LTSP Linux kernel.  The second allows the
Linux dhclient to resolve its IP address.

3) Although the ISA PNP docs specify that the IRQ, DMA and IO Address needs to be assigned to the
card before it is activated, Etherboot does not seem to care.  Therefore the code does not
assign the card with these values.

If you can help address any of thse issues, please feel free.

Regards

Tim Legge

Re: Re: [Etherboot-developers] Free IRQs, DMSs and ioaddrs

[<tl...@ro...>]

> Depends on how many people you think will use your driver. The 515's an
> ISA NIC that runs at 100 Mb (but will never achieve that throughput due
> to the limits on the ISA bus). How many people do you think will not
> have a PnP BIOS for this NIC?

I suspect 1.  Me.  However, the PNP as it is currently enabled, also finds and would probably enable 3c509s in PNP mode.  I suspect it could also be used for other PNP ISA cards.  However, the 3c515 is the only one that I know of that requires PNP in order to be activated.  

Tim

Re: [Etherboot-developers] Free IRQs, DMSs and ioaddrs

[<ke...@us...>]

>I have been able to get my 3c515 card recognized on a non-PBP bios.  However,
> at present I have hard coded the IRQ, DMA and ioaddr.  I have not reviewed m
>uch of the non-driver code but is there any functionality already included to
> find free IRQs?  

Nope. Etherboot doesn't use IRQs.

>I would prefer not to make this driver bigger and bigger.  I suspose, I could
> rip the PNP out of the driver and make it stand alone.  Any thoughts?

Depends on how many people you think will use your driver. The 515's an
ISA NIC that runs at 100 Mb (but will never achieve that throughput due
to the limits on the ISA bus). How many people do you think will not
have a PnP BIOS for this NIC?

[Etherboot-developers] Free IRQs, DMSs and ioaddrs

[<tl...@ro...>]

Hi

I have been able to get my 3c515 card recognized on a non-PBP bios.  However, at present I have hard coded the IRQ, DMA and ioaddr.  I have not reviewed much of the non-driver code but is there any functionality already included to find free IRQs?  

I would prefer not to make this driver bigger and bigger.  I suspose, I could rip the PNP out of the driver and make it stand alone.  Any thoughts?

Tim

Tim

Re: [Etherboot-developers] PXE

[Peter L. <P.L...@sy...>]

> It can be download from 
> ftp://download.intel.com//labs/manage/wfm/download/pxespec.pdf

Thanks.

When companies like Intel change well publicised URLs, I wish they'd
retain placeholders in ftp directories and politely redirect http. In my
days as a web admin, I regarded this kind of thing as basic courtesy to
visitors (it also reduced the "broken link" email traffic).

Re: [Etherboot-developers] PXE

[Christopher Li <ch...@gn...>]

I have one copy on my desk right now.

It can be download from 
ftp://download.intel.com//labs/manage/wfm/download/pxespec.pdf

And here is the page contain the download link.

http://www.intel.com/labs/manage/wfm/wfmspecs.htm

Chris

On Tue, 23 Apr 2002, Peter Lister wrote:

> > PXE, Please point me at the right docs for PXE. I can't for the life of me
> > find 'em
> 
> The PXE spec should be at ftp://download.intel.com/ial/wfm/, but
> wha'd'ya know, it seems to have disappeared. Hmm. I have a copy (500KB
> PDF) if you are interested.
> 
> http://www.ltsp.org/documentation/pxe.howto.html describes chaining
> Etherboot from a NIC's PXE firmware.
> 
> 
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

Re: [Etherboot-developers] PXE

[Peter L. <P.L...@sy...>]

> PXE, Please point me at the right docs for PXE. I can't for the life of me
> find 'em

The PXE spec should be at ftp://download.intel.com/ial/wfm/, but
wha'd'ya know, it seems to have disappeared. Hmm. I have a copy (500KB
PDF) if you are interested.

http://www.ltsp.org/documentation/pxe.howto.html describes chaining
Etherboot from a NIC's PXE firmware.

Re: [Etherboot-developers] PXE

[<Rob...@ra...>]

PXE, Please point me at the right docs for PXE. I can't for the life of me
find 'em

Robert Cheetham

RadiSys Corporation
5959 Corporate Drive
Houston
TX 77546
713-541-8267
------------------------------------------------------------------------------------------------

Change is inevitable - except from a coke machine
------------------------------------------------------------------------------------------------

"This electronic message contains information which may be confidential,
privileged or otherwise protected from disclosure.  The information is
intended to be used solely by the named recipient(s).  If you are not a
named recipient, any review, disclosure, copying, distribution or use
of this transmission or its contents is prohibited.  If you have received
this transmission in error, please notify me immediately."


                                                                                                                                            
                      ke...@us... (Ken                                                                                    
                      Yap)                                         To:       Etherboot developers list                                      
                      Sent by:                                      <eth...@li...>                            
                      eth...@li...        cc:                                                                      
                      ceforge.net                                  Subject:  Re: [Etherboot-developers] PXE                                 
                                                                                                                                            
                                                                                                                                            
                      04/23/02 10:00 AM                                                                                                     
                      Please respond to Etherboot                                                                                           
                      developers list                                                                                                       
                                                                                                                                            
                                                                                                                                            




>Could someone tell me what the state of the PXE code is when trying to
>use it with Linux?? When I try
>
>bin32/e1000-ecop.rom,   the code produced works fine :)
>
>when I try
>
>bin32/e1000-ecop.pxe,  the code produced doesn't have the 55 AA
>signature and the file seems very small. It also doesn't work.

Why would it have a 55 AA signature? It's not a PXE ROM image, it's an
Etherboot image meant to be loaded with PXE. See the doco.

>Incidentally I believe the MAX_BOOTP_RETRIES in etherboot.h should be
>reduced to say 5, the current value of 20 results in a timeout of about
>30,000,000 seconds or about 9.5 years. 5 gives about 5 minutes. The
>other MAX_RETRY values may also need to be reduced.

See Config for documentation of BACKOFF_LIMIT.

>I have updated makerom with a new compiler flag to produce ROMS in
>increments of 2K which is the size that modern BIOSes search in. This is
>only important if the amount of option ROM space is limited.

makerom has been rewritten in Perl (currently in CVS) so if you want to
see your changes considered, you'll have to work on that version.

>I have made a number of other small changes which I will document and feed
>back if anyone is interested.

Post away.

_______________________________________________
Etherboot-developers mailing list
Eth...@li...
https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] PXE

[Vasil V. <vas...@sy...>]

On Tue, 23 Apr 2002 Rob...@ra... wrote:

> Could someone tell me what the state of the PXE code is when trying to use
> it with Linux?? When I try

It should be working with Linux. Plenty of people managed to use it. I use it
every day including all the other ways of loading etherboot. BTW, I even
managed to resize my Windows (and only) partition of my laptop by running
etherboot from PXE and loading a RAM disk with parted.

Incidently there are problems with DOS, because when PXE is supposed to be
unloaded it is still hooked to some interrupts. The previous version was fine
with DOS but then it didn't free some of the memory (which was holding the
interrupts). The guy who wrote pxelinux had a solution for this by
implementing a floppy in RAM. I don't have time right now to investigate fully
but will try to come up with a work around for DOS.

> bin32/e1000-ecop.rom,   the code produced works fine :)
>
> when I try
>
> bin32/e1000-ecop.pxe,  the code produced doesn't have the 55 AA signature
> and the file seems very small. It also doesn't work.

More details please. What failed, any messages? If you are trying to run the
second image from a ROM, this probably won't work. This image is to placed on
the server and then loaded by PXE. That's why it doesn't have the signature --
not required by PXE.

PXE standard is overly complicated and "apparently designed on a different
planet" (quote from Becker's Intel eepro100 driver about Intel network chips).
What's more different implementations may have bugs of their own. However, it
seems to be in a lot of manufactured NIC ROMs and a lot of people are scared
of "burning" a ROM. So it is useful sometimes.

Vasil

Re: [Etherboot-developers] PXE

[<ke...@us...>]

>Could someone tell me what the state of the PXE code is when trying to
>use it with Linux?? When I try
>
>bin32/e1000-ecop.rom,   the code produced works fine :)
>
>when I try
>
>bin32/e1000-ecop.pxe,  the code produced doesn't have the 55 AA
>signature and the file seems very small. It also doesn't work.

Why would it have a 55 AA signature? It's not a PXE ROM image, it's an
Etherboot image meant to be loaded with PXE. See the doco.

>Incidentally I believe the MAX_BOOTP_RETRIES in etherboot.h should be
>reduced to say 5, the current value of 20 results in a timeout of about
>30,000,000 seconds or about 9.5 years. 5 gives about 5 minutes. The
>other MAX_RETRY values may also need to be reduced.

See Config for documentation of BACKOFF_LIMIT.

>I have updated makerom with a new compiler flag to produce ROMS in
>increments of 2K which is the size that modern BIOSes search in. This is
>only important if the amount of option ROM space is limited.

makerom has been rewritten in Perl (currently in CVS) so if you want to
see your changes considered, you'll have to work on that version.

>I have made a number of other small changes which I will document and feed
>back if anyone is interested.

Post away.

[Etherboot-developers] PXE

[<Rob...@ra...>]

Could someone tell me what the state of the PXE code is when trying to use
it with Linux?? When I try

bin32/e1000-ecop.rom,   the code produced works fine :)

when I try

bin32/e1000-ecop.pxe,  the code produced doesn't have the 55 AA signature
and the file seems very small. It also doesn't work.

Incidentally I believe the MAX_BOOTP_RETRIES in etherboot.h should be
reduced to say 5, the current value of 20 results in a timeout of about
30,000,000 seconds or about 9.5 years. 5 gives about 5 minutes. The other
MAX_RETRY values may also need to be reduced.

I have updated makerom with a new compiler flag to produce ROMS in
increments of 2K which is the size that modern BIOSes search in. This is
only important if the amount of option ROM space is limited.

I have made a number of other small changes which I will document and feed
back if anyone is interested.

Robert Cheetham

RadiSys Corporation
5959 Corporate Drive
Houston
TX 77546
713-541-8267
------------------------------------------------------------------------------------------------

Change is inevitable - except from a coke machine
------------------------------------------------------------------------------------------------

"This electronic message contains information which may be confidential,
privileged or otherwise protected from disclosure.  The information is
intended to be used solely by the named recipient(s).  If you are not a
named recipient, any review, disclosure, copying, distribution or use of
this transmission or its contents is prohibited.  If you have received this
transmission in error, please notify me immediately."

[Etherboot-developers] Status of 32515 for non PNP Bioses

[Timothy L. <tl...@ro...>]

Hi

I thought I would give an update in my work on the 3c515 for non PNP 
devices.  I am happy to report that I have managed to enable the card on 
a non PNP bios.  The Etherboot probed, and found the card, but reported 
the incorrect Node address.  I modified the dhcpd.conf file to the 
incorrect address, and the kernel was sucessfully transfered and booted. 
 At the dhcpclient stage, I had to modify the dhcpd.conf file back to 
the correct node address (as found by Becker's Linux module).  From 
there it finished the boot process and started the X server.  It may be 
interesting to note, that the node address reported was the serial 
number that the PNP code had found.

Needless to say, there is still a little work left to do, but it does 
not seem insurmountable anymore.  The ISAPNP code has been instramental 
in this, but I have never seen a more confusing piece of code.  I am at 
a loss to say how it works, and I am surprized that I was able to make 
heads or tails of it.

I guess I am a lot better off than I was just a couple of months ago, 
when I realized that the brand new card I bought off ebay, was 
unsupported by Etherboot. ;-)

Regards

Tim

Re: [Etherboot-developers] Sundance (D-Link DFE-550TX) driver?

[<ke...@us...>]

>Has anyone done any work on the Sundance (D-Link DFE-550TX) driver?  I 
>am still working on adding support for Non-PNP Bioses to the 3c515 
>driver, but since I have the DFE-550 I thought I might give that a whirl 
>as well.

Nope, it's all yours.

Please make a habit of this. :-)

[Etherboot-developers] Sundance (D-Link DFE-550TX) driver?

[Timothy L. <tl...@ro...>]

Hi

Has anyone done any work on the Sundance (D-Link DFE-550TX) driver?  I 
am still working on adding support for Non-PNP Bioses to the 3c515 
driver, but since I have the DFE-550 I thought I might give that a whirl 
as well.

Regards

Tim

[Etherboot-developers] Cleaned up 3c515 driver

[Timothy L. <tl...@ro...>]

Hi Ken

Here is the cleaned up 3c515.  I will have to spend a little time with 
cvs patch etc. before I do much more.

Tim

Re: [Etherboot-developers] Indent Style

[<ke...@us...>]

>Hi
>
>Is there an indent style used by most of the etherboot code?
>
>Tim

There is no official style but since a lot of the drivers are derived
from Linux, that style tends to be common. Personally I prefer this
block style:

	if ( ) {
		...
	} else {
		...
	}

as it uses up fewer lines so you get more context on the screen. But as
long as your style is not idiosyncratic and you are consistent, speaking
for myself, I don't care. A confusing indentation can be fixed with
indent, but a confusing algorithm is harder to fix.

[Etherboot-developers] Indent Style

[Timothy L. <tl...@ro...>]

Hi

Is there an indent style used by most of the etherboot code?

Tim

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

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >A.2  PnP Option ROM Header
> Offset    Size     Value    Description
> >-----------------------------------------------------
> >00h       BYTE     55h       Signature byte 1.
> >01h       BYTE     AAh       Signature byte 2.
> >02h       BYTE     Varies    Option ROM length in 512-byte blocks.
> >03h       4 BYTES  Varies    Initialization entry point.
> >07h       17 BYTES Varies    Reserved.
> >18h       WORD     Varies    Offset to PCI data structure.
> >1Ah       WORD     Varies    Offset to expansion header structure.
> >
> >So my question is, can we have something like:
> >
> >PnP option ROM Header size 64K
> >512 bytes later, PnP option ROM Header size 64K - 512 bytes
> >512 bytes later, PnP option ROM header size 64K - 1024 bytes.
> >etc.
> 
> Interesting. How about this variation:
> 
> PnP option ROM Header size 512 bytes, jump to start
> PnP option ROM Header size 512 bytes, jump to start
> ...
> PnP option ROM Header size 512+x bytes, jump to start
> start of code (x bytes)
> 
> Problem is the BIOS might be entitled to map in only as much of the ROM
> as the header declares.

I believe it is, the PCI spec says specifically that the ROM must first
be copied into RAM.  And it is legal for us to shorten our ROM image size
after the initialization vector is called.

We read from the ROM ourselves which solves that the too little
information problem.  Another little tidbit is that the PCI data
structure has at offset 15 an indicator byte.  Bit 7 of that byte is
set to 1 if this is the last image, and it is set to 0 if there are
more images.

Eric

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

[<ebi...@ln...>]

"Robb Main [Genedyne]" <gen...@ac...> writes:

>  <ebi...@ln...> writes:
> 
> > 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.
> >
> > 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.
> 
> Since the early days of the XT, standard BIOSes scan on 2K boundaries.  This
> is somewhat odd, considering the blocksize given at offset 0x2 is the number
> of 512 byte blocks.  The scan increment has persisted even in modern AT
> BIOSes - one more bit of cruft from the dark ages.  For this reason, I don't
> think you can expect "overlapping" ROMs or concatenated ROMs on a 512-byte
> boundary to operate as expected. At least not if your target is a "portable"
> solution.

Possibly.  

The target is something that works with Phoenix, AMI, and Award for PCI
roms.  So that we can do better for the common case, we can fallback
to what we have today for the other cases.
 
> I believe the "standard" algorithm for performing the scan is something like
> this:
> 
> pThisLocn = 0xC000
> do {
>     if ( *(pThisLocn) == 0xAA55) {
>         // 0x55, 0xAA signature (byte-swapped) matches
>         if (checksumROMat(pThisLocn)) {
>             invokeROMat(pThisLocn)
>             pThisLocn += (*(pThisLocn+2) * 512)
>             if (pThisLocn & 0x07FF) {
>                 // ROM does not end at 2K boundary, so round it up...
>                 pThisLocn += 0x07FF
>                 pThisLocn &= 0xF800
>             }
>         } else {
>             // ROM failed checksum, so assume it only _looks_ like a ROM)
>             pThisLocn += 0x0800    // 2K increment
>         }
>     } else {
>        pThisLocn += 0x0800    // 2K increment
>     }
> } while (pThisLocn >= 0xC000) // relies on 16-bit rollover in pointer for
> termination

But none of this factors in the changes made when they added the PCI
speec.

> 
> Now one thing you _could_ do is make a "super-ROM", that contains multiple
> ROM images, but only one "standard" ROM header (0x55, 0xAA, etc).  The init
> code of the super-ROM, would scan internally for "super-ROM" headers (which
> could be anything - I like "BOB'S YER UNCLE!", although it is a bit
> excessive and wasteful).  This would be consistently portable (x86 only, of
> course), except....

That it doesn't have the PCI ID of all of the PCI chips.

> Another bit of IBM BIOS cruft was that ROMs greater than 32KB may be
> ignored.
> This issue is even less consistent. Some modern BIOSes still adhere to this
> "standard", but others will accept ROMs up to 64KB.
> Even if the BIOS ignores the ROM, it may
> - scan the next 2K boundary (i.e, within the ROM); or
> - scan the next boundary (i.e., next byte after the ROM)
> Anyway - the super-ROM concept could still work, as long as only the first
> 32KB was considered part of the standard ROM.  The code could still be
> larger, but the init code would have to implement it's own checksum for the
> entire "super-ROM" contents (or checksum each individual "super-ROM" module
> prior to invocation.
> 
> I hope there is something helpful in all the blather above, and keep up the
> great work.

Thanks there is some, I hadn't picked up on the 2K increment before.  Basically
we need to do some expirmentation and see what BIOS's actually accept.

Eric

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

[<ke...@us...>]

>A.2  PnP Option ROM Header
Offset    Size     Value    Description
>-----------------------------------------------------
>00h       BYTE     55h       Signature byte 1.
>01h       BYTE     AAh       Signature byte 2.
>02h       BYTE     Varies    Option ROM length in 512-byte blocks.
>03h       4 BYTES  Varies    Initialization entry point.
>07h       17 BYTES Varies    Reserved.
>18h       WORD     Varies    Offset to PCI data structure.
>1Ah       WORD     Varies    Offset to expansion header structure.
>
>So my question is, can we have something like:
>
>PnP option ROM Header size 64K
>512 bytes later, PnP option ROM Header size 64K - 512 bytes
>512 bytes later, PnP option ROM header size 64K - 1024 bytes.
>etc.

Interesting. How about this variation:

PnP option ROM Header size 512 bytes, jump to start
PnP option ROM Header size 512 bytes, jump to start
...
PnP option ROM Header size 512+x bytes, jump to start
start of code (x bytes)

Problem is the BIOS might be entitled to map in only as much of the ROM
as the header declares.

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

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >What if you (we) could build a bootrom that knows about ALL
> >pci network chipsets.
> 
> You already can, in theory, just do what Michael Brown did with multi
> driver binaries.
> 
> >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.
> 
> Unfortunately it isn't, if you'd written a driver before you'd know
> different.  Each driver can have pretty complicated code and use large
> buffers. See tulip.c for an extreme example. To share the buffers would
> require some kind of dynamic memory allocation. And even then there's
> the memory squeeze, see below.

Although all of the buffers should be in the BSS and not matter,
binary size wise.
 
> >I use 29ee512 chips for the Linksys and 3Com cards, 
> >I'll bet we could fit support for a lot of chipsets into 64k.
> 
> The problem is not the ROM size, but the limited execution area with
> which Etherboot has to work (48kB from 0x94000). Hence the interest in a
> relocatable Etherboot binary which could copy itself to the top of
> memory, which should leave enough room at the bottom for the loaded code
> in all except very memory deficient machines. But that's a promising
> direction to work towards.

And the challenge with a relocateable binary is that we would need
to split etherboot into 2 sections.  The 16bit code section, which
must be under 1M, and the rest.  And we can probably place the
code that must be under 1M between 0xC0000 - 0xE0000, basically
just leave it there as our initialization finishes.

I have the self relocation working just fine with memtest86, reducing
it's memory footprint from 128KB to 56KB because it no longer has to
have 2 copies of itself.  I have a few more hurdles to over come
before I release patches against memtest86 but I have the self
relocating working solidly.

Eric

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

[<ke...@us...>]

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

You already can, in theory, just do what Michael Brown did with multi
driver binaries.

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

Unfortunately it isn't, if you'd written a driver before you'd know
different.  Each driver can have pretty complicated code and use large
buffers. See tulip.c for an extreme example. To share the buffers would
require some kind of dynamic memory allocation. And even then there's
the memory squeeze, see below.

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

The problem is not the ROM size, but the limited execution area with
which Etherboot has to work (48kB from 0x94000). Hence the interest in a
relocatable Etherboot binary which could copy itself to the top of
memory, which should leave enough room at the bottom for the loaded code
in all except very memory deficient machines. But that's a promising
direction to work towards.

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

[<ebi...@ln...>]

<ja...@Mc...> writes:

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

You caught the basic idea.  Especially when you notice Etherboot
only has 2 3com drivers, so all of the code is common.  The
open question is if it is technically feasible to have multiple
ROM images.

While writing this it occors to me that for a PCI expansion ROM
there is one other possibility.  If it isn't technically feasible
to have overlapping ROM images, it should be feasible to have multiple
images, with just enough code to remap the PCI rom and read out the
real ROM image.  Getting the BIOS to do all of the mapping and
selecting for us is probably a better way to go, but if a small enough
mini loader can be written I am certain we can make it work.

I'm hoping I can get someone else to volunteer for some of this.  But
if not I might be able to find a little bit of time to check this out.

Eric

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

[Robb M. [Genedyne] <gen...@ac...>]

 <ebi...@ln...> writes:

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

Since the early days of the XT, standard BIOSes scan on 2K boundaries.  This
is somewhat odd, considering the blocksize given at offset 0x2 is the number
of 512 byte blocks.  The scan increment has persisted even in modern AT
BIOSes - one more bit of cruft from the dark ages.  For this reason, I don't
think you can expect "overlapping" ROMs or concatenated ROMs on a 512-byte
boundary to operate as expected. At least not if your target is a "portable"
solution.

I believe the "standard" algorithm for performing the scan is something like
this:

pThisLocn = 0xC000
do {
    if ( *(pThisLocn) == 0xAA55) {
        // 0x55, 0xAA signature (byte-swapped) matches
        if (checksumROMat(pThisLocn)) {
            invokeROMat(pThisLocn)
            pThisLocn += (*(pThisLocn+2) * 512)
            if (pThisLocn & 0x07FF) {
                // ROM does not end at 2K boundary, so round it up...
                pThisLocn += 0x07FF
                pThisLocn &= 0xF800
            }
        } else {
            // ROM failed checksum, so assume it only _looks_ like a ROM)
            pThisLocn += 0x0800    // 2K increment
        }
    } else {
       pThisLocn += 0x0800    // 2K increment
    }
} while (pThisLocn >= 0xC000) // relies on 16-bit rollover in pointer for
termination

Now one thing you _could_ do is make a "super-ROM", that contains multiple
ROM images, but only one "standard" ROM header (0x55, 0xAA, etc).  The init
code of the super-ROM, would scan internally for "super-ROM" headers (which
could be anything - I like "BOB'S YER UNCLE!", although it is a bit
excessive and wasteful).  This would be consistently portable (x86 only, of
course), except....
Another bit of IBM BIOS cruft was that ROMs greater than 32KB may be
ignored.
This issue is even less consistent. Some modern BIOSes still adhere to this
"standard", but others will accept ROMs up to 64KB.
Even if the BIOS ignores the ROM, it may
- scan the next 2K boundary (i.e, within the ROM); or
- scan the next boundary (i.e., next byte after the ROM)
Anyway - the super-ROM concept could still work, as long as only the first
32KB was considered part of the standard ROM.  The code could still be
larger, but the init code would have to implement it's own checksum for the
entire "super-ROM" contents (or checksum each individual "super-ROM" module
prior to invocation.

I hope there is something helpful in all the blather above, and keep up the
great work.

Cheers,
Robb Main.