Re: FW: HOT Plug and Expansion ROMs

["Gregory R. Hill" <gregh@FirmWorks.COM>]

At 10:37 AM 4/7/97 -0600, Monish Shah wrote:
>On Apr 4,  3:41pm, Tony Goodfellow wrote:
>> Subject: FW: HOT Plug and Expansion ROMs
>>
>> The "HOT PLUG' proposal excludes the possibility of using Expansion ROMS
>> for Adapter initialization.  This seems to be a retrograde step because:
>>
>> a) There are many cases where generations of an adapter might be register
>> compatible to the HOST driver yet require different initialization
>> procedures.  (Expansion ROM initialization is specific to the Hardware the
>> ROM resides on.)
>
>Counting on the expansion ROM to do your initialization has another
>problem.  May be the expansion ROM won't be run at all.  In PC compatible
>systems, this can happen if you run out of space for BIOS.  The BIOS code
>must be copied to memory below 1M, so there is a limit to how many BIOSes
>can be executed.
>
>So, it is best to have your device driver do full initialization both
>because of hot plug and because of BIOS space limitations.
>
>I realize that Openboot firmware (which you described as F-code) is a
>solution to both problems.  However, I suspect that having drivers do full
>initialization is the path of least resistance for PC compatible systems.

You are probably right in your last statement.  But PCI is not restricted to 
BIOS-based systems.  There are PCI-based systems out there using Open 
Firmware/FCode and the elimination of FCode from the cards used in such 
systems *is* a retrograde step.  IMHO, Tony is absolutely correct in his 
presentation of the facts.  FirmWorks supports Tony's suggestion that FCode 
ROM images not be forbidden.  If the BIOS world wants to take "the path of 
least resistance", that's up to them.  Please do not handcuff those of us 
who are using a different approach.

There are non-PCI-based Open Firmware systems that already support hot plug, 
and they do so by (1) recognizing the presence of a new card, (2) "probing" 
the card by evaluating its FCode image (which can initialize the device as 
required), and (3) attaching the appropriate driver as a function of the 
information obtained from the FCode image.  From the perspective of the 
device, it goes through the same FCode probing process whether it is hot 
plugged or not.


>> b) It does not seem to be in the spirit of "Hot Plugging" to require that a
>> user replaces an "old" generation Adapter with the same "old" generation or
>> figure out that some different driver has to be dynamically loaded.
>
>It seems to me that replacing a "slightly" different device is the same as
>replacing with a completely different device.  I.e., the old driver has to
>be terminated and a new driver has to be started.  So, if the driver does
>full initialization, as I suggest, then what you describe above is not a
>problem.

If the FCode image does the initialization (which is very common in the Open 
Firmware/FCode world) and you execute the FCode on a power-cycle and not on 
a hot-plug, then the FCode-compatible OS driver has to behave differently in 
the two situations, and to do work and have more knowledge of the hardware 
than it needs to have now.  The right solution for hot plug in the Open 
Firmware world is to have an FCode image on the board that is evaluated just 
as it would be on a power cycle/system reset.

Greg

Greg Hill                               FirmWorks
Director of Technical Communications    Suite 210, 480 San Antonio Road
gregh@firmworks.com                     Mountain View, CA 94040-1218
415-917-6985 (voice)                    ftp://ftp.firmworks.com/pub
415-917-6990 (fax)                      http://www.firmworks.com 
<)