Age | Commit message (Collapse) | Author |
|
- do not leak memory when polling;
- bring LUN support back - Motorola documentation says LUNs are not
supported, but it's a SysV/m88k limitation, not a hardware one.
- honour request timeout while polling (instead of using a fixed value)
- do not program the scsi command length if the hardware knows it from
the scsi command group (as advised in the manual)
- various minor fixes, especially better error recovery.
tested by nick@ and I; ok deraadt@.
|
|
reliable), and add a large block of comments to explain the timer
mess^Wsituation on MVME188.
|
|
drift the clock of the hardclock() processing time.
|
|
|
|
|
|
the code assumes 1MHz timers.
|
|
|
|
|
|
but it could cause the output to stop completely.
While there, fix cnputc() prototype and clean up cngetc().
|
|
less stack pointer manipulation; the kernel needs to be compiled by an
up-to-date compiler now, or a tree will fall on your house.
|
|
- simpler structures (no more redundant or easily computable information).
- split scheme configuration (for 4:1 and 8:1 designs) is only compiled in
if necessary (read: only on a mvme88k kernel configured for MVME188 support),
which speeds up CMMU operations on the Luna88k.
- will not enable bus snopping on a monoprocessor system.
Tested on Luna88k-2, MVME187 and various MVME188 by aoyama@ and I.
|
|
|
|
rather than an ugly 0x108.
|
|
using as part of the general pmap machinery (though they might come back
at some point to speed up I/O mappings), and we don't use the 88110 BATC
yet.
|
|
- a really working and simpler ddb "machine translate" helper.
- get rid of the remains of the BATC code, which would not work as is on
4:1 and 8:1 boards.
|
|
|
|
- change the split CMMU strategy from splitting on user/supervisor, then
A14/A14*, to A12/A12*, then A14/A14*. I believe this arrangment, being
more symmetrical, uses the extra CMMUs better.
- correctly handle 88204 - they will split on A14 and A16 instead of A12
and A14.
- fix the addressing logic, when we need to know if a specific CMMU manages
a certain address, or not. Code is even smaller now!
- since the strategy choice makes user/supervisor distinction obsolete,
remove the associated logic in m8820x_cmmu_set().
We now run multiuser on a 2P128 (4:1 88200) HYPERmodule. All 4:1 configurations
should work; 8:1 configurations (1P128 with 88200, and 1P512) could not been
tested due to lack of such hardware.
|
|
|
|
MVME188 configurations. Thus, we are looking at valid values when electing
the faulting CMMU.
|
|
handling code checks the error status of the correct CMMUs and really
reports an error code.
This gets us closer to getting these modules to work, at the expense of
sanity and some code readability.
|
|
- add the board's suffix to the machine description if there is one;
- recognize BUG version < 5 on MVME188, which don't provide a CNFG block.
in this case we'll assume 20MHz for now, until we can parse the ENV data block
correctly...
|
|
|
|
- move MAX_CPUS constant to <machine/cpu.h>
- do not include <machine/board.h> unless needed. In fact, remove this file
entirely on mvme88k, and include <machine/mvme*.h> on a
compiling-for-this-board basis
- keep MAX_CMMUS constant private to the m8820x code
|
|
|
|
|
|
warn about them on console. More informative than ``regular'' spurious interrupt
warnings.
|
|
CMMU we accessed the WHOAMI register, rather than cause a CMMU fault and
check which CMMU reported the fault.
|
|
|
|
|
|
|
|
188 system has!
|
|
gives us more counters in the process.
Also clean up intrhand structures and usage, especially move them to SLISTs.
|
|
fetch the VMEbus interrupt vector in time.
|
|
|
|
and mvme88k is the retrieval of the CMMU fault registers.
Tested on mvme88k by myself and luna88k by aoyama@
|
|
below the kernel text is reserved for the PROM, instead of using fixed
(but different) values between luna88k and mvme88k.
Tested on mvme88k by myself, on luna88k by aoyama@
|
|
<m88k/cpu.h>, and simplify the return values while there.
|
|
|
|
to the BUG instead of spinning if our reset fails.
|
|
the console transition from BUG to the chip could lead us to invoke
ttymodem() on a bogus tty.
|
|
reactive.
|
|
|
|
|
|
|
|
|
|
second scsi bus if a SCSI daughterboard is present, and is supposed to know
about this and send scsi commands to the appropriate bus.
Unfortunately probing the second bus does not report any device at the
moment (though you can boot off it), but I can't see the issue at the moment.
Thanks to tdeval@ for lending a few boards equipped with daughterboards
for testing.
|
|
|
|
|
|
do not keep setting the A.A. bit in further queue control operations, as
advised by the manual.
|
|
|