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