The device files for A24 and A16 access are all representations of the special PCI Slave image of the Universe, wich is controlled by the single SLSI register. This slave image is mapped into a 64MByte area, whose 4 16MByte parts correspond to the 4 device files.
Start offset | End offset | Access Mode | Minor | Comment |
0x00000000
| 0x00feffff
| A24 D32 User | 2 | |
0x00ff0000
| 0x00ffffff
| A16 D32 User | 2 | |
0x01000000
| 0x01feffff
| A24 D16 User | 2 | |
0x01ff0000
| 0x01ffffff
| A16 D16 User | 2 | |
0x02000000
| 0x02feffff
| A24 D32 Super | 3 | |
0x02ff0000
| 0x02ffffff
| A16 D32 Super | 3 | |
0x03000000
| 0x03feffff
| A24 D16 Super | 3 | |
0x03ff0000
| 0x03ffffff
| A16 D16 Super | 3 | |
The entire slave image is mapped to the bus address 0x10000000,
from which it is remapped via ioremap()
to the variable
Slsi_kernel_addr
.
The mmap()
call for the A24 devices then allows the
mapping of one of the 16MB sections
(the one associated with the minor device number)
into an applications address space.
All accesses on this image (if memory-mapped) are done without posted write enabled, as this overcomes Universe Erratum Number 8, Posted write problems. Since the memmory-mapped acess is usually needed for random-access, the performance penalty is not too great (i hope).
The handling of the A24/A16 device is just the same as that of the A32
capable devices,
only that not all adressing modes and data width are available.
The ioctl()
-calls needed are described in section
A32 images.