| Age | Commit message (Collapse) | Author |
|---|
|
M8120, since cl0 and cl1 share the same interrupt, and cl1 would warn,
using cl0 as the console, and an infinite loop would occur.
Spotted by Christian Groessler, thanks!
|
|
From NetBSD
NetBSD PR 27678 for details
ok mcbride@
|
|
|
|
no functional change.
|
|
|
|
in allocsys().
|
|
characters; this will prevent us from falling into timeout behaviour when
it is in fact not necessary.
|
|
|
|
treatement of interrupt vectors variables, a simple read will do.
While there, speed up the interrupt handlers a bit:
- remove old debug code or only compile it if option DEBUG.
- use short circuits for setipl() if we know interrupts are disabled at
this point: there is no need playing with the psr in these cases.
|
|
may disturb the dma as seen in ipw(4). Emtpy mbufs are at the beginning of the
mbuf chain and are as example a "side-effect" of a previous m_adj() call.
OK miod@ mickey@ jason@ markus@
|
|
|
|
move the mapiodev()/unmapiodev() code back to mvme88k.
|
|
|
|
luna88k it disappears completely, while mvme88k keeps 3 global variables,
one of them scheduled to disappear very soon.
|
|
ok miod@
|
|
do not provide it on luna88k. Makes trap() slightly faster on non-MVME188
kernels.
|
|
- merge locore_c_routines.c into machdep.c
- split machdep.c into really machdep.c content, and board-specific routines
(memory sizing, early initialization, etc).
No functionnal change.
|
|
|
|
compiling for one flavour only.
This makes code slightly smaller on all m88k-based platforms (my roughly
1KB), and saves more than meets the eye on luna88k, which is m88100-based.
|
|
|
|
|
|
|
|
architecture is still fluffy (;
|
|
- 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.
|
