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

4.104.114.84.95
Last change on this file since cba119c9 was 0ea3293, checked in by Joel Sherrill <joel.sherrill@…>, on Mar 1, 2002 at 4:21:52 PM

2002-02-27 Greg Menke <gregory.menke@…>

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