in preparation for future mvmeppc and mvme88k ports.
This needs a bit if tidying up to make it trully shareable, which will
happen as the new mvme ports are added.
for the i82596 PORT access interface, from the documentation
for that chip. These help clarify writes to the SYSBUS
part of the SCP, and PORT usage by i82596-aware drivers.
and attach it as `timekeeper0 at mainbus0'.
Use the MI mk48txx nvram/rtc access functions instead of home-grown
versions.
It should now be very easy to add a character device for the benefit
of userland access to NVRAM.
and attach it at mainbus since it depends both PCCChip2 and VMEChip2
(or the VMEChip2 interrupter) starting first.
We can finally enable, detect and log DRAM ECC errors.
(The PROM disabled ECC checks by default)
hardware-assisted soft interrupts on all boards.
(Note: VMEChip2-less 162/172 not yet tested)
This greatly simplifies the `rei' path and allows
interrupt nesting to be tracked somewhat more easily.
As a result we now have a working CLKF_INTR() macro
and can detect uvm_fault() being called from an interrupt
(although there may still be a very short race detecting
the latter; need to investigate further).
This is a completely rewritten scsipi_xfer execution engine, and the
associated changes to HBA drivers. Overview of changes & features:
- All xfers are queued in the mid-layer, rather than doing so in an
ad-hoc fashion in individual adapter drivers.
- Adapter/channel resource management in the mid-layer, avoids even trying
to start running an xfer if the adapter/channel doesn't have the resources.
- Better communication between the mid-layer and the adapters.
- Asynchronous event notification mechanism from adapter to mid-layer and
peripherals.
- Better peripheral queue management: freeze/thaw, sorted requeueing during
recovery, etc.
- Clean separation of peripherals, adapters, and adapter channels (no more
scsipi_link).
- Kernel thread for each scsipi_channel makes error recovery much easier
(no more dealing with interrupt context when recovering from an error).
- Mid-layer support for tagged queueing: commands can have the tag type
set explicitly, tag IDs are allocated in the mid-layer (thus eliminating
the need to use buggy tag ID allocation schemes in many adapter drivers).
- support for QUEUE FULL and CHECK CONDITION status in mid-layer; the command
will be requeued, or a REQUEST SENSE will be sent as appropriate.
Just before the merge syssrc has been tagged with thorpej_scsipi_beforemerge
This adds support for EtherExpress/16 cards with 16k of RAM, and in the
process adds general support for PIO mode on these cards. This entails
changing the way the i82586 driver handles bus barriers, since it doesn't
allow for strange cases like this.
This has been tested on the i386 port with the 'ix' driver in both
16KB (which was the source of the problem) and 32KB modes, as well
as with the 'ef' driver. I've tested it (briefly) with 'ei' on arm26
as well. In theory, drivers other than 'ix' should follow precisely the
same code paths as before.
. use a structure for the tag instead of an integer constant,
. add bus_space_{peek,poke}_N() (and G/C `badaddr()'),
. fix a few drivers which have dependencies on the implementation.
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.
treated as just another available VMEbus slave image as far as
bus_dma(9) is concerned.
To preserve faster onboard memory, mvmebus_dmamem_alloc() will
allocate first from the offboard VMEbus RAM slave image if present,
and assuming its address modifier matches the caller's constraints.
This can be overidden by specifying the BUS_DMA_ONBOARD_RAM flag.
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...
scw