Re: Option ROM / OS Driver Questions

["David O'Shea" <daveo@corollary.com>]

At 03:02 PM 8/20/96 -0600, Mike Doerfler wrote:
>
>question 1 :
>
>I have a PCI technical question that is relevant to Expansion ROM
>developers and OS PCI card driver writers.  If there is a system that
>contains more PCI slots then there is room in memory to execute every
>cards initialization option ROM.  Is it OK to bend the Plug and Play
>Spec.  and only initialize a set number of cards ?

It is reality that this is what happens if the expansion ROM's are large
on the add-in boards on a system with many slots.

>                                                ....And if so, would it
>be reasonable for OS driver writers to always assume that a card/device
>has not been initialized before the driver is called ?  This would put
>the responsibility of card/device initialization/testing on the OS driver
>itself and not the option ROM.  The driver would contain all code
>necessary to bring the card/device up (running).  Is this a reasonable
>approach to the too many cards, large ROMs, with limited memory issue ?

Well written device drivers make no assumption about the device state
when their initialization routines are run.  Such drivers fully configure
every aspect of the device as if the expansion ROM had not run.  Unfortunately
not all device drivers are so well written.

>question 2 :
>
>Is it possible to execute option ROMs from conventional memory ?
>Conventional memory being memory in address range 0-A0000h.

Yes it is possible to actually run the initialization code from such
an area, however very few systems do this.   One problem is that two 
properties are defined for the shadow RAM into which option ROM code
is shadowed.   One property which must exist during INIT time, which is that
the shadow RAM is in a read/write state.   This allows the INIT code
to write information tables and other values that it gathers (such as
its device location) into the shadowed RAM area.   When the INIT is
over, the shadow RAM is then write protected by the system BIOS.
The later event (write protection after INIT) is in fact a property
guaranteed for run time.   Although very few option ROM BIOS take 
advantage of the fact that there own code address space is write
protected, it is a possible (and guaranteed) use.   For instance a
ROM which was trying to clear an error condition by "dumping data on
the ground" might do so by transfering the data into the option ROM
space, since it knows that it is write protected.

Obvisouly, normal RAM in 0-A0000h has the property that it is read/write
all the time.   This meets the INIT time requirements, but does not meet
the runtime requirements for the shadow RAM of PCI option ROMS.   If
someone did it anyway, most ROMs would still work since very few depend
on the write protect feature, still an occansional expansion ROM would
break because of this.  Also, this chews up the 0-A0000h region.  Quite
a few applications would not appreciate the system BIOS subtracting more
space than the space already lost to the extended BIOS region from the
0-A0000h region.  

You could do it, and you would trade off not being able to run some INIT
code at all with not being able to correctly run all INIT code safely.
In addition you would loose the used space from the region.  

Of course this type of control is only available to writers of their own
BIOS for their own systems.

-David O'Shea
Z
(