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