1 | # |
---|
2 | # $Id$ |
---|
3 | # |
---|
4 | |
---|
5 | BSP supporting the on-CPU capabilities of the Synova Mongoose-V. |
---|
6 | This BSP assumes that basic HW initialization is performed by |
---|
7 | PMON. |
---|
8 | |
---|
9 | Address Map |
---|
10 | =========== |
---|
11 | This is the generic address map of the Mongoose-V prototyping board |
---|
12 | this BSP was tested on. |
---|
13 | |
---|
14 | 0x8000_0000 - 0x8FFF_FFFF - RAM (KSEG0 cached) |
---|
15 | 0xA000_0000 - 0xAFFF_FFFF - RAM (KSEG1, same memory uncached) |
---|
16 | 0xBFC0_0000 - 0xBFFF_FFFF - EEPROM |
---|
17 | 0xFFFE_xxxx - on-CPU peripherals |
---|
18 | |
---|
19 | This is the hardware address map of the board used as it was |
---|
20 | actually populated. |
---|
21 | |
---|
22 | 0x8000_0000 - 0x83FF_FFFF - 32 MB RAM (KSEG0 cached) |
---|
23 | 0xA000_0000 - 0xA3FF_FFFF - 32 MB RAM (KSEG1, same memory uncached) |
---|
24 | 0xBFC0_0000 - 0xBFDF_FFFF - 2 MB EEPROM |
---|
25 | 0xFFFE_xxxx - on-CPU peripherals |
---|
26 | |
---|
27 | This is the organization of the EEPROM when fully populated. Since |
---|
28 | the board used to develop this BSP only had the first bank of EEPROM |
---|
29 | populated, only the first program image area was used. |
---|
30 | |
---|
31 | 0xBFC0_0000 - 0xBFC3_FFFF - PMON |
---|
32 | 0xBFC4_0000 - 0xBFC4_FFFF - reserved for boot loader |
---|
33 | 0xBFC5_0000 - 0xBFDF_FFFF - reserved for program 1 image |
---|
34 | 0xBFE0_0000 - 0xBFFF_FFFF - reserved for program 2 image |
---|
35 | |
---|
36 | The Mongoose-V on this board is at 12 Mhz. |
---|
37 | |
---|
38 | Downloading |
---|
39 | =========== |
---|
40 | |
---|
41 | On the breadboard, a locally hacked PMON waits for a space to be pressed |
---|
42 | while the board is reset/powered up. If found, the PMON console is |
---|
43 | entered, else PMON jumps to the EEPROM address above, presuming a user |
---|
44 | program is located there. |
---|
45 | |
---|
46 | The default output of an RTEMS link is an image linked to run from |
---|
47 | 0x80020000. It is suitable for copying to S3 records or can be burned |
---|
48 | to ROMs in whatever manner the user desires. If you want to locate the |
---|
49 | image into ROM at some other address, use mips-rtems-objcopy to shift |
---|
50 | the LMA. |
---|
51 | |
---|
52 | Operation |
---|
53 | ========= |
---|
54 | |
---|
55 | A small relocator is supplied in the bsp startup code which copies the |
---|
56 | image down to RAM for execution before doing any other initialization. |
---|
57 | This locator code is location independent, and will do nothing if the |
---|
58 | image is already located at its run location. The LMA and VMA are both |
---|
59 | controlled via the bsp's link script. The above behavior is produced by |
---|
60 | using the default script. If this is not desirable, something like the |
---|
61 | following may be added to the user's RTEMS link statement to override |
---|
62 | the default linkcmds with a user-supplied version; |
---|
63 | |
---|
64 | -qnolinkcmds -Wl,-T -Wl,mips-rtems-linkcmds-eprom |
---|
65 | |
---|
66 | this causes the file ./mips-rtems-linkcmds-eprom to override the default |
---|
67 | linkcmds. |
---|
68 | |
---|
69 | Before relocating the RTEMS image, the bsp startup routine attempts to |
---|
70 | configure the processor into a rational state. During this process, |
---|
71 | status characters are emitted at 19200N81 on UART port 0. |
---|
72 | |
---|
73 | The default link script simply places the image at 0x8002000 with |
---|
74 | LMA=VMA, which is conviently located in RAM on our board. You should |
---|
75 | probably consider creating your own linkcmds, putting things where you |
---|
76 | want and supply it as above. |
---|
77 | |
---|
78 | The Mongoose V has a somewhat restricted cache configuration model; you |
---|
79 | can only flush it if the code which does so executes within noncached |
---|
80 | memory, in our case, code in kseg1. If you do so from elsewhere the |
---|
81 | code will appear to lock up, this is caused by the cache clearing |
---|
82 | routine making the instruction fetch always return 0, or nop- leaving |
---|
83 | the processor in an endless loop. The default start.S code detects if |
---|
84 | its booting from outside kseg1, it which case it disables the cache |
---|
85 | flush code. This means you cannot flush the cache with the bsp's |
---|
86 | functions if you boot your program from outside kseg1. A more subtle |
---|
87 | issue is the bsp keeps a pointer to the location in kseg1 where the |
---|
88 | bsp's cache flush code resides. This is advantageous because you can |
---|
89 | relocate the system anywhere and still control the cache, but might |
---|
90 | cause trouble if the boot image becomes inaccessible. If this is |
---|
91 | possible, you should probably consider rolling your own cache control & |
---|
92 | disabling the bsp's. |
---|
93 | |
---|
94 | As stated above, if you boot from outside kseg1, the bsp disables the |
---|
95 | cache flush routines. This is not desirable in the long run because the |
---|
96 | Mongoose V remote debugger stub assumes it can flush caches when exiting |
---|
97 | an exception so it might not be able to update code/data properly, |
---|
98 | though it should still nominally function. However, if you're not using |
---|
99 | the remote debugger & don't care about flushing caches, then everything |
---|
100 | should run just fine. |
---|
101 | |
---|
102 | Our approach has to been locate ROM in kseg1, link the code for VMA in |
---|
103 | RAM and relocate the LMA up into kseg1 ROM. Since the start.S code is |
---|
104 | position-independent, it will relocate the entire app down to the VMA |
---|
105 | region before starting things up with everything in its proper place. |
---|
106 | The cache clear code runs before relocation, so executes from ROM & |
---|
107 | things work. |
---|
108 | |
---|
109 | You can prevent including the default start.S by adding; |
---|
110 | |
---|
111 | -qnostartfile |
---|
112 | |
---|
113 | to the link command line in addition to the "nolinkcmds" options above. |
---|
114 | Be sure to supply your replacement start.o. |
---|
115 | |
---|
116 | |
---|
117 | |
---|
118 | Questions |
---|
119 | ========= |
---|
120 | |
---|
121 | Why can I send characters slowly to a Mongoose V, but get framing errors |
---|
122 | when sending them fast? |
---|
123 | |
---|
124 | - The MongooseV chip seems to <require> that all incoming data have 2 |
---|
125 | stop bits. When typing on a serial terminal, this is not an issue |
---|
126 | because the idle state of an RS232 line looks just like a stop bit- |
---|
127 | but when streaming in data, such pacing is required. The manual does |
---|
128 | not indicate anything along these lines, instead, we suspect a |
---|
129 | somewhat faulty UART design. |
---|
130 | |
---|
131 | |
---|
132 | Debugging |
---|
133 | ========= |
---|
134 | |
---|
135 | After getting Joel's initial port of the gdb stub to the Mongoose bsp, I |
---|
136 | worked up & tested this stub on our R3000 board. It seems to work OK. |
---|
137 | Our MIPS has 2 serial ports, the first being dedicated to the console, I |
---|
138 | chose to arrange the 2nd one for the remote gdb protocol. While this |
---|
139 | solution is somewhat specific to our board & bsp, I think the technique |
---|
140 | is quite generalizable. |
---|
141 | |
---|
142 | The following is a code snippet to be included in the user program; |
---|
143 | |
---|
144 | /***********************************************/ |
---|
145 | |
---|
146 | extern int mg5rdbgOpenGDBuart(int); |
---|
147 | extern void mg5rdbgCloseGDBuart(void); |
---|
148 | |
---|
149 | |
---|
150 | void setupgdb(void) |
---|
151 | { |
---|
152 | printf("Configuring remote GDB stub...\n"); |
---|
153 | |
---|
154 | /* initialize remote gdb support */ |
---|
155 | if( mg5rdbgOpenGDBuart(-1) != RTEMS_SUCCESSFUL ) |
---|
156 | { |
---|
157 | printf("Remote GDB stub is disabled.\n\n"); |
---|
158 | } |
---|
159 | } |
---|
160 | |
---|
161 | /***********************************************/ |
---|
162 | |
---|
163 | It allows the program to decide if it wants gdb to be ready to pick up |
---|
164 | exceptions or not. The 2 extern functions are located in the MongooseV |
---|
165 | bsp inside gdb-support.c. They configure & initialize the 2nd serial |
---|
166 | port & invoke the vector initialization routine located in cpu_asm. |
---|
167 | Note, we call directly down into the MongooseV UART driver- its quite |
---|
168 | unfriendly to TERMIO. I chose this approach because I wanted to |
---|
169 | minimize dependence on the I/O subsystems because they might be in a |
---|
170 | state just short of collapsing if the program had done something bad to |
---|
171 | cause the exception. |
---|
172 | |
---|
173 | If user code leaves the 2nd port alone, then things will work out OK. |
---|
174 | |
---|
175 | Greg Menke |
---|
176 | 2/27/2002 |
---|
177 | |
---|
178 | ============================================================================ |
---|
179 | |
---|