[PATCH 3/7] bsps/mips: Remove Mongoose-V README

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Mar 12 10:25:21 UTC 2018


---
 c/src/lib/libcpu/mips/mongoosev/README | 56 ----------------------------------
 1 file changed, 56 deletions(-)
 delete mode 100644 c/src/lib/libcpu/mips/mongoosev/README

diff --git a/c/src/lib/libcpu/mips/mongoosev/README b/c/src/lib/libcpu/mips/mongoosev/README
deleted file mode 100644
index 61d0fc6cf4..0000000000
--- a/c/src/lib/libcpu/mips/mongoosev/README
+++ /dev/null
@@ -1,56 +0,0 @@
-The Synova Mongoose-V is a radiation hardened derivative of the
-LSI 33K with on-CPU peripherals.
-
-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.
-
-
-
-
-
-- 
2.12.3



More information about the devel mailing list