Re: FW: HOT Plug and Expansion ROMs

[Rich Van Gaasbeck <richv@hpingll.cup.hp.com>]

Greg Hill writes...

<much deleted>


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

There are a number of assumptions that x86 option rom vendors could
make that might (would?) be broken if executed at run time:

  - that they are in a 16bit real mode environment
  - that they have direct access to other hardware on the system
    without having to worry about interfering with other drivers, etc
  - that it is appropriate to grab the keyboard and screen and wait
    some seconds for a key to be pressed
  - that it is appropriate to run setup utilities or diagnostics using
    direct keyboard, screen and adapter card accesses and with a different
    look and feel than the run time OS
  - that is should go looking around the system for other identical
    adapters and configure them
  - that it should put the card in a non-power-on state that the
    driver will expect, e.g. that it should initialize the card
  - that it should probe external devices

Questions: Are there any assumptions that PCI OpenFirmware
implementations make that would be broken if run after the OS is
running?  For instance, is the runtime environment identical to the
boottime environment?  Do they have the same access to hardware,
memory allocation services, etc?  Can OpenFirmware implementations have
a configuration or diagnostic dialog with the user that wouldn't be
appropriate at runtime?  

If yes to any of these, is there a mechanism to distinguish
OpenFirmware implementations that have these characteristics from
those that don't?

Rich Van Gaasbeck
Hewlett Packard

> 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 
> 
$Ä´