Re: FW: HOT Plug and Expansion ROMs

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

On 4/01/97, Rich Van Gaasbeck posted a note asking several questions
relative to this subject.  I asked Mitch Bradley, Chairman of the IEEE 1275
(Open Firmware) Working Group to answer those questions.  Although Mitch
replied to me promptly, I have been tardy in posting his reply.  My
apologies for the delay.

Greg

Rich's questions are preceded by >

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

It turns out that Open Firmware FCode driver model already
avoids every one of these problems.

>  - that they are in a 16bit real mode environment

The FCode execution environment is a well-specified byte-coded virtual
machine that is processor independent, endian-independent, and knows
nothing at all about any sort of processor mode.  As proof of this,
our FCode drivers operate unchanged on SPARC (both 32-bit and 64-bit
variants), x86, PowerPC (in any combination of little/big endian vs.
real/virtual mode), Alpha, PA-RISC, ARM, ..., and on a wide range
of system-level architectures.

>  - that they have direct access to other hardware on the system
>    without having to worry about interfering with other drivers, etc

FCode drivers specifically do not have access to other hardware.  The
only environmental assumptions they are allowed to make are:
a) They can request generic services from the FCode virtual machine,
   such as the allocation of memory (but they cannot make assumptions
   about where that memory will be located; the semantics are similar
   to C's malloc().)
b) They can request bus-specific services from their "parent device",
   which is a driver for the particular bus to which they are attached.
   Such services include mapping of bus-relative physical addresses
   (i.e. board registers) to obtain a virtual handle through which the
   register may be accessed (the FCode virtual machine provides suitable
   access primitives), and allocation and synchronization of DMA memory
   suitable for the bus in question.

>  - that it is appropriate to grab the keyboard and screen and wait
>    some seconds for a key to be pressed

This is specifically not allowed.  Even if somebody wanted to do it,
it would not work because the FCode system startup model does not
enable the console services until *after* all the devices have been
probed.

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

Again not allowed.  An FCode driver is permitted to create driver interface
methods to support such operations, but is not permitted to automatically
invoke them during initialization

>  - that is should go looking around the system for other identical
>    adapters and configure them

FCode drivers don't do this; each plug-in card is considered independent
from every other device, and each is initialized separately without
consideration of the possible presence of other identical devices.

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

The FCode initialization that occurs automatically when the card is probed
is supposed to put the card in a "quiescent" state, without making assumptions
about what mode any particular run-time driver might expect.  Initialization
into an active state only occurs if the driver's "open" method is explicitly
invoked later by an outside agent.

>  - that it should probe external devices

Plug-in bus bridges are supposed to probe their attached plug-in cards,
but things like SCSI host adapters, whose attached devices can potentially
take a long time to probe, are not supposed to probe their children
automatically.

>Questions: Are there any assumptions that PCI OpenFirmware
>implementations make that would be broken if run after the OS is running?

No.

> For instance, is the runtime environment identical to the boottime
> environment?

Yes

> Do they have the same access to hardware, memory allocation services, etc?

Yes.  A first-order design goal of Open Firmware was platform independence
and extensibility.  In order to achieve that goal, it was absolutely
necessary to limit the things that an FCode device driver could do to
things that are absolutely necessary and implicit in the design of the
parent bus.  For example, an FCode driver for a PCI device is permitted
to ask the parent bus driver to perform configuration accesses to its
own configuration registers, but is not permitted to assume that, for
example, the system even has an ISA bus.

In a runtime environment, the FCode virtual machine implementation would
provide the generic memory allocation services as usual, and would provide
the "parent bus" services appropriate for the plug-in bus.

> Can OpenFirmware implementations have
> a configuration or diagnostic dialog with the user that wouldn't be
> appropriate at runtime?  

The code that is automatically executed when the FCode driver is automatically
probed absolutely cannot do so, because in the power-up environment, the
console device is not enabled until after all the FCode drivers have been
probed (because the specific console input and output devices are chosen
after all devices have been probed and thus the full complement of available
devices is known).

Cheers,

Mitch Bradley

<@/