edt_data(4) — FILE FORMATS
NAME
/stand/edt_data − Equipped Device Table (EDT) Data File
DESCRIPTION
The Equipped Device Table data file describes board and device specific data used for configuring a kernel. Associated with some boards is an Extended EDT (XEDT) which describes subdevices of those boards and may be of zero length. The XEDT can be read by the program via a sysm88k(2) call XGETEDT on the special file associated with the board. Note that not all drivers may support this option.
COMMENTS
An EDT data file may contain comments. A comment begins with the character ’#’ and extends to the end of the line.
GENERAL DIRECTIVE INFORMATION
An EDT data file is composed of a collection of EDT data file directives. The template for the directives is:
directive name [options] [cpus(s)]
{
body
}
directive is the name of the directive. name specifies the name to be associated with the directive. options specifies strings which are directive specific. cpu(s) specifies which CPUs this directive should be limited to. If no cpu(s) are specified, the directive is associated with all CPUs that the kernel may support. Valid cpu(s) are "mvme181", "mvme187", "m8120", "mvme188", and "mvme197". It is possible for some directives to not have a body, in which case the open and close braces are dropped. If the directive does have a body, it is embedded in the open and close braces and consists of whitespace separated keyword and value pairs, one per line. When a number is called for it may be expressed in decimal, octal, or hexadecimal. Hexadecimal numbers must be preceded with the string "0x". Octal numbers must be preceded with a leading zero.
THE MEMORY-REGION DIRECTIVE
Specific areas of memory accessible to the CPU may be identified and described using the memory-region directive. The template for the memory-region directive is:
memory-region name [ignore] [cpu(s)]
{
idnumber
memory-addressnumber
memory-lengthnumber
ownerstring
groupstring
access-modesnumber
attributesstring [ string ... ]
initial-datapath-name
}
If the ignore string is present, the directive is ignored (never included into a kernel). The required id keyword specifies the unique number associated with the memory region. The required memory-address keyword specifies the starting address of the memory region. It must begin on an address that is a multiple of the system page size. The system page size is currently 4K bytes. The required memory-length keyword is used to specify the length of the memory region. It must be a multiple of the system page size. A memory region may not overlap any part of the short I/O address space unless the memory-address keyword specifies the beginning of the short I/O address space and the memory-length keyword specifies a length that completely covers the total short I/O address space. In other words, there can be one, and only one, memory region that handles the short I/O address space, and it must handle all of it. The optional owner keyword specifies the owner assigned to the device node created for this memory region. If the owner is not specified it defaults to "sys". The optional group keyword specifies the group assigned to the device node created for this memory region. If the group is not specified it defaults to "sys". The optional access-modes keyword specifies the file access modes for the device node created for this memory region. If the access modes are not specified, then they default to 0440. The optional initial-data keyword specifies the path-name of the file whose contents are used to initialize the memory region. The initialized data is loaded with the kernel so it is important to not specify the clear attribute for the memory region when initialized data is desired. The optional attributes keyword is used to associate information describing the memory region. Each attribute consists of an arbitrary string of characters. Embedded whitespace characters may be used in an attribute string but then the string must be embedded in double quote characters. Some of the attribute strings are automatically recognized by the kernel for use in initializing or handling the memory region. Any other attributes are entirely up to the implementor. By default each memory region is assumed to be byte addressible. If a region is not byte addressible the appropriate access attribute should be used. The automatically recognized attributes are:
| Attribute | Description |
| probe | Locate the actual end of the region by probing one page at a time. |
| nocache | Accesses to the memory region are not cached (cache-inhibited). |
| clear | The memory region will be filled with zeros before its first use. |
| byte | The memory region is byte addressible. |
| short | The memory region is short (16 bit) addressible. |
| long | The memory region is long (32 bit) addressible. |
| d64-read | The memory region is capable of VME64 read transfers. |
| d64-write | The memory region is capable of VME64 write transfers. |
| any | The memory region may be accessed using any addressible unit (8, 16, or 32 bits). |
| lock | The pages associated with the memory region will never be released. |
| paged | The memory region may be used by the kernel. Any memory marked paged should also be marked clear. |
| blkmode-read | The memory region is capable of VME block mode read transfers. |
| blkmode-write | The memory region is capable of VME block mode write transfers. |
THE VECTOR-GROUP DIRECTIVE
The vector-group directive specifies a group of interrupt vectors that should be assigned a name and be reserved from all but explicit use and the starting location of the group. The template for the vector-group directive is:
vector-group name [ignore] [cpu(s)]
{
vector-assignmentstarting-location
number-of-vectorsnumber
}
If the ignore string is present, the directive is ignored (never included into a kernel). The required number-of-vectors keyword specifies the number of interrupt vectors in the group. The required vector-assignment keyword specifies the starting location of the group. The starting-location must be expressed as an:
absolute vector displacement
An absolute vector displacement is defined as the interrupt vector number multiplied by 4.
anywhere specification
The string "any" specifies the group of vectors to be automatically assigned the first acceptable location.
modulo displacement specification
A modulo alignment directive specifies that the group of vectors may be automatically assigned a location provided that the vector number of the starting vector of the group has a remainder of zero when it is divided by the specified number. The form of this directive is "mod(specified-number)".
THE DRIVER DIRECTIVE
The driver directive specifies that a device driver is required to deal with a specific piece of hardware. The template for the driver directive is:
driver name [ignore] [probe] [software] [local] [cpu(s)]
{
idnumber
io-addressnumber
io-lengthnumber
memory-addressnumber
memory-lengthnumber
interrupt-levelnumber
vector-assignmentstarting-location
number-of-vectorsnumber
aux-infonumber number number number
}
The probe string specifies that this device should be probed for when the system boots. If this string is missing, the device and its driver are considered "required" in order to build a kernel, subject to the cpu limiters. software drivers may not have the probe string specified. The ignore string, when used with a "required" driver (one that does not have the probe string specified), specifies that it should not be included in the kernel. Drivers with both probe and ignore are handled differently. If all of the drivers for a specific type of device are marked ignore, none of the devices or the driver for the devices will be included in the kernel. However, if only some of the devices are ignored, they may still be included into the kernel for padding purposes. This insures that the information emitted into the kernel for the driver’s use isn’t modified by the removal of a device. The software string specifies that the driver is a software driver (i.e. no hardware is associated with it). A software driver is treated as a non-probed driver. The local string specifies that the interrupt associated with the driver is generated local to the cpu card (not via the VMEbus). The required id keyword specifies a unique number that identifies each device that a driver may utilize. This is the only required keyword for a software driver; all other keywords are invalid. The optional io-address keyword specifies the starting address of the short I/O area used by the device if needed. The optional io-length keyword specifies the length of the device’s short I/O area. If the io-address keyword is present, this keyword is required. The optional memory-address keyword specifies the starting address of an auxiliary memory area used by this device if needed. The optional memory-length keyword specifies the length of the device’s auxiliary memory area. If the memory-address keyword is present, this keyword is required. The required interrupt-level keyword specifies the interrupt level that this device should interrupt with. The required vector-assignment and required number-of-vectors keywords function the same as in their vector-group context; however, an additional vector-assignment technique is possible. This is the indexed reference to a vector group. An indexed reference is specified by the vector group name, followed by the index number embedded in open and close square brackets. The optional aux-info keyword is used to specify driver-specific values that the driver may use in whatever way it sees fit. If present, all four numbers a required.
THE CPU-IGNORE-INTERRUPT-LEVEL DIRECTIVE
This optional directive is used to ignore certain interrupt levels. This is useful when VMEbus devices are co-resident with UNIX devices and UNIX must not handle the interrupts associated with those devices. The template for the ignore-cpu-interrupt-level directive is:
ignore-cpu-interrupt-levelnone or levels
The keyword none, which is also the default if this directive isn’t used, specifies that all interrupt level should be allowed. Otherwise the levels specify which interrupt levels to ignore, each level being specified by its level number (e.g. interrupt level 5 as the digit 5).
DRIVER WRITER INFORMATION
Each of the keywords in the body of the driver directive causes the cunix program to automatically generate variables which may be accessed by a driver. These variables then allow the driver to know how many devices of its type are configured into the kernel, their locations, and characteristics. Each variable begins with the driver’s master.d file prefix, which is denoted by the string <prefix> below. The generated arrays have the device information stored in id keyword order.
| Variable | Data type | Use |
| <prefix>_cnt | unsigned int | Specifies the number of devices configured into the kernel. |
| <prefix>_addr | array of caddr_t | Specifies the starting short I/O addresses of each device. Derived from the io-address keyword. |
| <prefix>_iolen | array of unsigned int | Specifies the size (in bytes) of the device’s short I/O space. Derived from the io-length keyword. |
| <prefix>_maddr | array of unsigned int | Specifies the starting address of the auxiliary memory area of each device. Derived from the memory-address keyword. |
| <prefix>_memlen | array of unsigned int | Specifies the size (in bytes) of the auxiliary memory area of each device. Derived from the memory-length keyword. |
| <prefix>_nvec | unsigned int | Specifies the number of vectors per device. Derived from the number-of-vectors keyword. |
| <prefix>_vec | array of unsigned int | Specifies each device’s interrupt vector displacement (the interrupt vector number multiplied by four). Derived from the vector-assignment keyword. |
| <prefix>_ilev | array of unsigned int | Specifies the interrupt priority level of each device. Derived from the interrupt-level keyword. |
| <prefix>_aux | array of unsigned int | Specifies the auxiliary information for each device. Each device’s information is a group of 4 elements. Derived from the aux-info keyword. |
FILES
/usr/include/sys/edt.h