Re: PCI and Expansion ROM

[Gilbert Yeung <gilbert@lanworks.com>]

Tom Warren 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?).
>

You are right. We have multiple images. Quite a few NIC vendors has 
different PCI Device ID for each variation of the same ethernet 
controller. There might be a Device ID for 100BaseTX, a Device ID for 
10BaseT/Coax, a Device ID for 100BaseT4 .... We can't release 10 
different BootROMs for essentially the same adapter. It will cause havoc 
with our customers, OEM and distributors. What we did is squeeze a number 
of BootROMs into 1 physical ROM and pray that the BIOS will call the 
correct one. 


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

What we are trying to do is update the BootROM content. Some of our 
offering uses FlashROM and we have a configuration utility embedded 
inside the BootROM. When the user changes the setting, we save the 
setting into the Physical ROM using Int 15/Fun 87. We found problems 
writing to our FlashROM using Int15/Fun 87. Don't have much problem 
reading from it. 


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


thanks

--------------------------------------------------------------------------

Gilbert Yeung
Lanworks Technologies Inc
Voice: 905-238-5528 ext 135
Fax:    905-238-9407
-------------------------------------------------------------------------

,