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*.
backend.
The VME2chip can use this to translate a VMEbus irq to a cpu irq.
The VMEchip (on mvme147) can't deal with the VMEbus irq and cpu irq
being different so we just panic in that case for now.
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.
deal with dynamic address modifier generation based on the CPU's
function code pins.
Also implement VMEbus slave mode for mvme147. (Not yet 100% working.)
vme_dmamem*.
This is still a work in progress, but seems to DTRT on mvme167 so far.
TODO:
. Get VMEbus slave mode going on mvme147. This should be easy.
. Fix up the A16 slave mappings.
. Bounce buffer support. (Messy, but pretty much a `must have'.)
. Figure out how to deal with `location monitor' interrupts
within the framework. (Useful for Busnet, among other things.)
. It would be nice to make use of the VMEchip2's DMA facilities...
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.
scw