ISA: Industry Standard Architecture
UART: Universal Asynchronous Receiver/Transmitter
The meaning of this property is as defined in Open Firmware core document [1], as modified by the Generic Names Recommended Practice [7]. The value for nodes described by this specification shall be "serial".
The meaning of this property is as defined in the Open Firmware core document [1]. The value for nodes described by this specification shall be "serial".
The meaning of this property is as defined in Open Firmware, as modified by the Generic Names Recommended Practice [7]. As described in those documents, the entries are a list of device names with which this device is compatible, starting with the name of the device itself and progressing through successively less precise and possibly less functional compatible devices.
For this device, the compatible property shall include "pnpPNP,501."
Additional entries may be supplied, at their appropriate position in the list, to describe devices with which this device is compatible.
The meaning of this property is as defined in the Open Firmware core document [1]. It describes the device's register set. The values which shall be assigned to this property are explained in the ISA/EISA/ISA-PnP binding[3] and the I/O Device Reference[5]
The meaning of this property is as defined in the Interrupt Mapping Recommended Practice [6]. The values assigned to this property are explained in the ISA/EISA/ISA-PnP binding[3] and the I/O Device Reference[5].
Typically, the clock frequency is nominally 1,843,200 Hz. Some devices generate the baud rate input clock by dividing a higher-frequency clock source that is not an exact multiple of 1,843,200 Hz, resulting in a small but acceptable error in the nominal clock frequency. In such cases, the "clock-frequency" shall report the actual nominal frequency. For example, if the baud rate input clock is generated by dividing a 24 MHz clock by 13, the value of the "clock-frequency" property shall be 1846153.
open is a Standard Method for the Serial Device. When the Serial Device is opened, several device-arguments can be passed as defined below:
driver-name@unit-address:device-arguments
device-arguments are defined to be of the form, e.g. 9600,8,n,1, and sets the UART parameters (baudrate, #data bits, parity, #stop bits, and handshake) accordingly.
The fields are (in order, left to right):
<baud rate>, <data bits>, <parity>, <stop bits>, <handshake>
Fields with empty values are not changed. Values for fields are whatever the hardware will support:
baud rates: various, including 110, 300, 1200, 2400, 4800, 9600, 19200, 38400
character bits: 5,6,7,8
parity:
----------- char means ----------- n none e even o odd m mark s space -----------stop bits:
------------------- char means ------------------- 1 1 stop bit . 1.5 stop bits 2 2 stop bits -------------------handshake:
------------------------------------- char means ------------------------------------- - none h hardware (rts/cts) \ Not supported s software (xon/xoff) \ Not supported -------------------------------------The default mode is 9600,8,n,1,-
---------------------------- bitmask Modem control state ---------------------------- 0 RTS off, DTR off 1 RTS off, DTR on 2 RTS on, DTR off 3 RTS on, DTR on ----------------------------The response for other values of bitmask are implementation dependent.
Changing the bits associated with these lines shall have no effect on other bits not associated with this function.
For devices which are selected as Open Firmware's "console input device" or "console output device" device, the device shall be initialized appropriately for the device to which it is attached.
Refer to [5] for more information on the state of this device when the client is started.
For devices selected as Open Firmware's "console input device" or "console output device" device, the state should be unmodified from the initial state on client start-up.
Note: If the device is in a different state when the client calls Open Firmware, unpredictable behavior may result if Open Firmware accepts input or generates output. Clients changing the device state should either restore the original state before calling Open Firmware or should avoid using Open Firmware features requiring user interaction. Changing the device state is likely to render Open Firmware unusable for debugging purposes.