[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PCI and Expansion ROM



Gilbert,

I wrote our (VLSI's) PCI BIOS. Please see my comments, below:

>At 02:07 PM 8/9/96 -0400, Gilbert Yeung wrote:
>1) some BIOS do not check the Device ID in the BootROM PCI Data 
>Structure. This causes a BIG problem for us and we see it as a violation 
>of the PCI Spec. The Spec says


I agree that the PCI BIOS should check this field in the expansion ROM, but
I don't see how the BIOS's _not_ checking it would cause a problem for your
code (unless you build ROMs with multiple device images?).

>2) on some of the BootROMs, we have to access the real physical ROM in 
>extended memory during the INIT function. We use Int 15 Fun 87 and found 
>it to be unreliable on some BIOS. If we do not run Int15 during the INIT 
>function, everything would be fine. If there are any BIOS vendors in this 
>mailing list, please make sure Int15/Fun87 is fully support during INIT 
>time. 

INT 15h Func 87h is often unreliable, as you stated, but using
protected-mode from an expansion ROM is really frowned upon. Why not include
your entire image length during INIT, and then shrink your size when done?
(the only BIOS I'm aware of that wouldn't allow this is the Award 4.50G,
which mistakenly write-protects the shadow RAM _before_ calling the INIT
offset, instead of after). INT 15h Func 87h messes with the LDT,GDT,KBC and
CMOS, and it (usually) returns via the BIOS shutdown path (store a byte in
CMOS, reset the system, and read the CMOS byte to see how the user want's to
return). You'd have to be very careful to save/restore _every_ register in
the CPU to protect against hangs.

Also, on some PCI chips I've seen, the ROM address decoder is shared w/other
BARs (as per the spec, page 198), and re-enabling the ROM to poke around in
it causes the chip's memory controller to go haywire. If you need to access
data that's been placed in your ROM, then you're better off ensuring that
it's copied to RAM, where you can get at it easily.

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

This may be due to the granularity of the shadow RAM regions. On our (VLSI)
chipsets, it's usually 16KB (rarely 8KB), so a 40KB ROM would require 48KB
of shadow RAM (wasting 8KB). If the BIOS can't find enough contiguous space
for your expansion ROM, it can't shadow it & can't call it. If the BIOS did
allocate 48K of RAM for a 40K ROM, but attempted to use the last 8KB for the
next expansion ROM, it might inadvertently overwrite 8KB of your ROM,
causing the system to hang (I did this is an early version of my PCI BIOS).
The PCI SIG has a test (PCIEXP) that should detect this & other PCI BIOS bugs.

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

Again, it's up to the PCI BIOS to keep track of how much shadow RAM is
actually used, regardless of what the expansion ROM says it's using. If the
PCI BIOS can't handle expansion ROMs that shrink, then it's broken. The
alignment of PCI expansion ROMs in memory (shadow RAM) is determined by the
core-logic chipset's shadow RAM granularity, unless the PCI BIOS is advanced
enough to merge adjacent ROM code. PCIEXP checks for compliance with
shrinking PCI ROMs, too.

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

I can't speak for Compaq, but if an expansion ROM is rewriting the INTLINE
register, it would have to reroute the IRQ via PCI BIOS Func 0Fh, after
parsing the table returned via Func 0Eh. Usually, IRQ routing is a black art
best left to the system/PCI BIOS. I don't know how Compaq could determine
that you had changed the interrupt, but I wouldn't blame them for
'bypass'ing your code. System integrity is compromised whenever expansion
ROMs change BARs, interrupts, or muck with other devices (I've seen VGA ROMs
that change Intel's Triton core-logic configuration during INIT, SCSI ROMs
that rewrite their I/O BAR because the only decode certain addresses, etc).

>There are more issues that I can't remember. If there are any BIOS 
>vendors in this mailing list and you have more questions, please respond. 
>Regardless, PCI is still much better than Plug and Play  :>). 
>

If you have a free NIC & ROM, I'd like to try it with our BIOS (we provide
it with our chipsets on evaluation platforms to OEMs).

>thanks
>
>--------------------------------------------------------------------------
>
>Gilbert Yeung
>Lanworks Technologies Inc
>Voice: 905-238-5528 ext 135
>Fax:    905-238-9407
>-------------------------------------------------------------------------
>
----------------- The gene pool could use a little chlorine -------------------

Tom Warren - Staff Software Engineer  VLSI Technology, Inc.  8375 S. River Pkwy
tom.warren@tempe.vlsi.com             M/S 265                Tempe, AZ  85284
76167.1572@compuserve.com             FON (602) 752-6396     FAX (602) 752-6000



\L