source: rtems/c/src/lib/libbsp/mips/genmongoosev/README @ 8536b67

Last change on this file since 8536b67 was 8536b67, checked in by Joel Sherrill <joel.sherrill@…>, on Oct 8, 2014 at 8:06:52 PM

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.

  • Property mode set to 100644
File size: 9.3 KB
1BSP supporting the on-CPU capabilities of the Synova Mongoose-V.
2The Synova Mongoose-V is a radiation hardened derivative of the
3LSI 33K with on-CPU peripherals.
5This BSP assumes that basic HW initialization is performed by PMON.
9Per-task floating point enable/disable is supported for both immediate
10and deferred FPU context swaps.
12Interrupt Levels are adapted reasonably well to the MIPS interrupt
13model. Bit 0 of the int level is a global enable/disable, corresponding
14to bit 0 of the processor's SR register.  Bits 1 thru 6 are configured
15as masks for the Int0 thru Int5 interrupts.  The 2 software interrupt
16bits are always enabled by default.  Each task maintains its own
17Interrupt Level setting, reconfiguring the SR register's interrupt bits
18whenever scheduled in.  The software ints, though not addressable via
19the various Interrupt Level functions, are maintained on a per-task
20basis, so if software manipulates them directly, things should behave as
21expected.  At the time of these udpates, the Interrupt Level was only 8
22bits, and completely supporting the global enable, software ints and the
23hardware ints would require 9 bits.  When more than 8 bits are
24available, there is no reason the software interrupts could not be added
25to the Interrupt Level.
27While supporting the Int0 thru Int5 bits in this way doesn't seem
28wonderfully useful, it does increase the level of compliance with the
29RTEMS spec.
31Interrupt Level 0 corresponds to interrupts globally enabled, software
32ints enabled and Int0 thru Int5 enabled.  If values other than 0 are
33supplied, they should be formulated to impose the desired bitmask.
34Interrupt priority is not a strong concept on this bsp, it is provided
35only by the order in which interrupts are checked. 
37If during the vectoring of an interrupt, others arrive, they will all be
38processed in accordance with their ordering in SR & the peripheral
39register.  For example, if while we're vectoring Int4, Int3 and Int5 are
40asserted, Int3 will be serviced before Int5.  The peripheral interrupts
41are individually vectored as a consequence of Int5 being asserted,
42however Int5 is not itself vectored.  Within the set of peripheral
43interrupts, bit 0 is vectored first, 31 is last.
45Interrupts are not nested for MIPS1 or MIPS3 processors, but are
46processed serially as possible.  On an unloaded 50 task RTEMS program,
47runnning on a 12mhz MIPS1 processor, worst-case latencies of 100us were
48observed, the average being down at 60us or below.
51These features are principally a consequence of fixes and tweaks to the
52MIPS1 and MIPS3 processor support, and should be equally effective on
53both levels of MIPS processors for any of their bsp's.
55Address Map
57This is the generic address map of the Mongoose-V prototyping board
58this BSP was tested on.
600x8000_0000 - 0x8FFF_FFFF   - RAM (KSEG0 cached)
610xA000_0000 - 0xAFFF_FFFF   - RAM (KSEG1, same memory uncached)
620xBFC0_0000 - 0xBFFF_FFFF   - EEPROM
630xFFFE_xxxx                 - on-CPU peripherals
65This is the hardware address map of the board used as it was
66actually populated.
680x8000_0000 - 0x83FF_FFFF   - 32 MB RAM (KSEG0 cached)
690xA000_0000 - 0xA3FF_FFFF   - 32 MB RAM (KSEG1, same memory uncached)
700xBFC0_0000 - 0xBFDF_FFFF   - 2 MB EEPROM
710xFFFE_xxxx                 - on-CPU peripherals
73This is the organization of the EEPROM when fully populated.  Since
74the board used to develop this BSP only had the first bank of EEPROM
75populated, only the first program image area was used.
770xBFC0_0000 - 0xBFC3_FFFF   - PMON
780xBFC4_0000 - 0xBFC4_FFFF   - reserved for boot loader
790xBFC5_0000 - 0xBFDF_FFFF   - reserved for program 1 image
800xBFE0_0000 - 0xBFFF_FFFF   - reserved for program 2 image
82The Mongoose-V on this board is at 12 Mhz.
87On the breadboard, a locally hacked PMON waits for a space to be pressed
88while the board is reset/powered up.  If found, the PMON console is
89entered, else PMON jumps to the EEPROM address above, presuming a user
90program is located there.
92The default output of an RTEMS link is an image linked to run from
930x80020000.  It is suitable for copying to S3 records or can be burned
94to ROMs in whatever manner the user desires.  If you want to locate the
95image into ROM at some other address, use mips-rtems-objcopy to shift
96the LMA.
101A small relocator is supplied in the bsp startup code which copies the
102image down to RAM for execution before doing any other initialization.
103This locator code is location independent, and will do nothing if the
104image is already located at its run location.  The LMA and VMA are both
105controlled via the bsp's link script.  The above behavior is produced by
106using the default script.  If this is not desirable, something like the
107following may be added to the user's RTEMS link statement to override
108the default linkcmds with a user-supplied version;
110-qnolinkcmds -Wl,-T -Wl,mips-rtems-linkcmds-eprom
112this causes the file ./mips-rtems-linkcmds-eprom to override the default
115Before relocating the RTEMS image, the bsp startup routine attempts to
116configure the processor into a rational state.  During this process,
117status characters are emitted at 19200N81 on UART port 0.
119The default link script simply places the image at 0x8002000 with
120LMA=VMA, which is conviently located in RAM on our board.  You should
121probably consider creating your own linkcmds, putting things where you
122want and supply it as above. 
124The Mongoose V has a somewhat restricted cache configuration model; you
125can only flush it if the code which does so executes within noncached
126memory, in our case, code in kseg1.  If you do so from elsewhere the
127code will appear to lock up, this is caused by the cache clearing
128routine making the instruction fetch always return 0, or nop- leaving
129the processor in an endless loop.  The default start.S code detects if
130its booting from outside kseg1, it which case it disables the cache
131flush code.  This means you cannot flush the cache with the bsp's
132functions if you boot your program from outside kseg1.  A more subtle
133issue is the bsp keeps a pointer to the location in kseg1 where the
134bsp's cache flush code resides.  This is advantageous because you can
135relocate the system anywhere and still control the cache, but might
136cause trouble if the boot image becomes inaccessible.  If this is
137possible, you should probably consider rolling your own cache control &
138disabling the bsp's.
140As stated above, if you boot from outside kseg1, the bsp disables the
141cache flush routines.  This is not desirable in the long run because the
142Mongoose V remote debugger stub assumes it can flush caches when exiting
143an exception so it might not be able to update code/data properly,
144though it should still nominally function.  However, if you're not using
145the remote debugger & don't care about flushing caches, then everything
146should run just fine.
148Our approach has to been locate ROM in kseg1, link the code for VMA in
149RAM and relocate the LMA up into kseg1 ROM.  Since the start.S code is
150position-independent, it will relocate the entire app down to the VMA
151region before starting things up with everything in its proper place.
152The cache clear code runs before relocation, so executes from ROM &
153things work.
155You can prevent including the default start.S by adding;
159to the link command line in addition to the "nolinkcmds" options above.
160Be sure to supply your replacement start.o.
167Why can I send characters slowly to a Mongoose V, but get framing errors
168when sending them fast?
170- The MongooseV chip seems to <require> that all incoming data have 2
171  stop bits.  When typing on a serial terminal, this is not an issue
172  because the idle state of an RS232 line looks just like a stop bit-
173  but when streaming in data, such pacing is required.  The manual does
174  not indicate anything along these lines, instead, we suspect a
175  somewhat faulty UART design.
181After getting Joel's initial port of the gdb stub to the Mongoose bsp, I
182worked up & tested this stub on our R3000 board.  It seems to work OK.
183Our MIPS has 2 serial ports, the first being dedicated to the console, I
184chose to arrange the 2nd one for the remote gdb protocol.  While this
185solution is somewhat specific to our board & bsp, I think the technique
186is quite generalizable.
188The following is a code snippet to be included in the user program;
192extern int mg5rdbgOpenGDBuart(int);
193extern void mg5rdbgCloseGDBuart(void);
196void setupgdb(void)
198   printf("Configuring remote GDB stub...\n");
200   /* initialize remote gdb support */
201   if( mg5rdbgOpenGDBuart(-1) != RTEMS_SUCCESSFUL )
202   {
203      printf("Remote GDB stub is disabled.\n\n");
204   }
209It allows the program to decide if it wants gdb to be ready to pick up
210exceptions or not.  The 2 extern functions are located in the MongooseV
211bsp inside gdb-support.c.  They configure & initialize the 2nd serial
212port & invoke the vector initialization routine located in cpu_asm.
213Note, we call directly down into the MongooseV UART driver- its quite
214unfriendly to TERMIO.  I chose this approach because I wanted to
215minimize dependence on the I/O subsystems because they might be in a
216state just short of collapsing if the program had done something bad to
217cause the exception.
219If user code leaves the 2nd port alone, then things will work out OK.
221Greg Menke
Note: See TracBrowser for help on using the repository browser.