Re: PCI and Expansion ROM

[rwalter@auspex.com (Richard Walter)]

Gilbert Yeung wrote:

> 3) some BIOS will NOT call an expansion ROM when the size of the BootROM 
> is around 40K. A couple of systems actually hang. We started with a 64K 
> ROMSize and gradually decreases the size until we get called. We check 
> and there is enough free high memory on the system (we are the only one 
> using high memory). We have to split our ROM into different pieces to 
> ensure we will get called.

First of all, a BIOS that hangs with a large ROM image definitely has problems.

However, your sentiment that because some BIOSes won't load a 64K ROM image,
that they are somehow broken seems like sour grapes to me.  In the PCI 2.1
spec, section 6.3.3.1.1, pg. 203, it talks about what steps the system BIOS
should take when handling expansion ROMs.  In step 2, it says, "... copy it
from ROM into the compatibility area of RAM (typically 0C0000h to 0E0000h) ..."
That means that there is only 128K of memory space available TOTAL for all
expansion ROMs in the system, so requesting half of that for your device
seems greedy.  Later, the spec also states that if a VGA device with an
expansion ROM exists, that that ROM *MUST* (emphasis mine) be copied to
0C0000h, further limiting available space for all other ROMs.  If the BIOS
cannot find any memory space large enough for your ROM, then it's only course
of action is to not run you, correct?

As for high memory, I don't think that you really want to use high memory
(I'm assuming that by high memory, you're referring to the 64K-16 bytes above
1 Meg that can be accessed in real mode with a segment of FFFFh) during ROM
time.  After all, since the ROM is executing before any OS stuff is loaded,
when the OS does come it, it will take over high memory and trash anything
that you've got there, right?

However, there is some room for interpretation of what exactly "compatibility
area of RAM" where the ROMs get copied to really means.  According to the spec,
it is "typically 0C0000h to 0E0000h", but is it really only that on x86 PC's?

In my mind, your scenario is analogous to a device requesting 512K of memory
space below 1 Meg in it's BARs and then being upset when the BIOS cannot honor
that request, and so leaves the device turned off.

But, this issue #3 also clears up my confusion about why in your issue #2
you state the need to access the real physical ROM and not having Int15/Fun87
working.  My personal opinion (and I'm warning you that I'm a hardware guy...)
is that breaking a ROM up into small segments and then having one portion of
your ROM directly load other parts seems to be on the fringe of the spirit of
PCI.  A much better solution, in my mind, would be to simply try to make a
smaller ROM (which, I admit may not always be possible.)

> 4) we have seen an AMD SCSI Expansion ROM which shrink itself to a NON- 
> 2K boundary (runtime size). This throws off the BIOS alignment and all 
> Expansion ROMs after that are not called. 

Where in the PCI spec do you see a 2K boundary limitation?  The size byte
in the ROM header that the INIT code modifies to indicate run-time size is
in units of 512 bytes, so it seems to me that a ROM could shrink itself down
to the closest 512 byte limit and still meet spec.

Granted, that if a BIOS then refuses to load other ROMs that there is a BIOS
error, but don't gripe about a non-2K boundary.  (Gripe about a non-512 byte
boundary instead :) ).

> 5) on some Compaq PCI machines, the Expansion ROM will be bypassed if we 
> force the NIC interrupt to be a specific value (rather than let the BIOS 
> decide). We found that when we are doing interrupt sharing testing. 

How do you "force" the interrupt to a specific value?  I'm confused as to how
you could have code accomplish this before Expansion ROMs are executed.

-Richard Walter
rwalter@auspex.com
Note: I speak for myself, not for Auspex.


dLTL