CPU support taken from a combination of NetBSD/amiga and NetBSD/x68k.
At this time, MVME-172 works but MVME-177 is untested. Since the '177
is otherwise identical to the MVME-167, this should *just work*.
Currently, the major onboard devices are supported (disk, network,
rs232 and VMEbus). However, work is still need to support the remaining
devices (eg. IndustryPack sites).
These boards are available with a dazzling array of build options. At
this time, the following options are *required*:
o Real floating point hardware (the 68LC040 model isn't tested),
o The VMEchip2 must be present,
o If offboard VMEbus RAM is not present, at least 8MB of onboard
RAM is required.
o Even if offboard VMEbus RAM *is* present, at least 4MB of onboard
RAM is required. (Boards with 1 or 2MB onboard RAM *can* be
supported with offboard RAM, but not without some funky values in
the VMEbus Master mapping registers.)
There is no support for boards other than those in the -LX 200/300 series.
These changes add support for:
o The MI VMEbus framework on both MVME147 and MVME167.
o Enhancements to the existing MD bus_space(9) implementation.
o Most of the bus_dma(9) API.
so that the right entries get added to dev_name2blk[]. Needed for / on RAID.
(Whoops! I missed checking these in when adding the RAID_AUTOCONFIG stuff.)
(currently only CD-ROM drives on i386). The sys/dev/scsipi system provides 2
busses to which devices can attach (scsibus and atapibus). This needed to
change some include files and structure names in the low level scsi drivers.
- split softc size and match/attach out from cfdriver into
a new struct cfattach.
- new "attach" directive for files.*. May specify the name of
the cfattach structure, so that devices may be easily attached
to parents with different autoconfiguration semantics.
scw