Move Mongoose-V specific devices into BSP.

Putting the duart in libcpu was very optimistic and presumptuous.
It has never been used again on another SoC and is BSP specific.

1 files changed, 52 insertions, 2 deletions

diff --git a/c/src/lib/libbsp/mips/genmongoosev/README b/c/src/lib/libbsp/mips/genmongoosev/README
index 97db696554..d8b9bd5b99 100644
--- a/c/src/lib/libbsp/mips/genmongoosev/README
+++ b/c/src/lib/libbsp/mips/genmongoosev/README
@@ -1,6 +1,56 @@
 BSP supporting the on-CPU capabilities of the Synova Mongoose-V.
-This BSP assumes that basic HW initialization is performed by
-PMON.
+The Synova Mongoose-V is a radiation hardened derivative of the
+LSI 33K with on-CPU peripherals.
+
+This BSP assumes that basic HW initialization is performed by PMON.
+
+Status
+======
+Per-task floating point enable/disable is supported for both immediate
+and deferred FPU context swaps.
+
+Interrupt Levels are adapted reasonably well to the MIPS interrupt
+model. Bit 0 of the int level is a global enable/disable, corresponding
+to bit 0 of the processor's SR register.  Bits 1 thru 6 are configured
+as masks for the Int0 thru Int5 interrupts.  The 2 software interrupt
+bits are always enabled by default.  Each task maintains its own
+Interrupt Level setting, reconfiguring the SR register's interrupt bits
+whenever scheduled in.  The software ints, though not addressable via
+the various Interrupt Level functions, are maintained on a per-task
+basis, so if software manipulates them directly, things should behave as
+expected.  At the time of these udpates, the Interrupt Level was only 8
+bits, and completely supporting the global enable, software ints and the
+hardware ints would require 9 bits.  When more than 8 bits are
+available, there is no reason the software interrupts could not be added
+to the Interrupt Level.
+
+While supporting the Int0 thru Int5 bits in this way doesn't seem
+wonderfully useful, it does increase the level of compliance with the
+RTEMS spec.
+
+Interrupt Level 0 corresponds to interrupts globally enabled, software
+ints enabled and Int0 thru Int5 enabled.  If values other than 0 are
+supplied, they should be formulated to impose the desired bitmask.
+Interrupt priority is not a strong concept on this bsp, it is provided
+only by the order in which interrupts are checked.  
+
+If during the vectoring of an interrupt, others arrive, they will all be
+processed in accordance with their ordering in SR & the peripheral
+register.  For example, if while we're vectoring Int4, Int3 and Int5 are
+asserted, Int3 will be serviced before Int5.  The peripheral interrupts
+are individually vectored as a consequence of Int5 being asserted,
+however Int5 is not itself vectored.  Within the set of peripheral
+interrupts, bit 0 is vectored first, 31 is last.
+
+Interrupts are not nested for MIPS1 or MIPS3 processors, but are
+processed serially as possible.  On an unloaded 50 task RTEMS program,
+runnning on a 12mhz MIPS1 processor, worst-case latencies of 100us were
+observed, the average being down at 60us or below.
+
+
+These features are principally a consequence of fixes and tweaks to the
+MIPS1 and MIPS3 processor support, and should be equally effective on
+both levels of MIPS processors for any of their bsp's.
 
 Address Map
 ===========