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 | 80020000, but has had its LMA shifted up to BFC40000. It is suitable |
---|
48 | for copying to S3 records or can be burned to ROMs in whatever manner |
---|
49 | the user desires. |
---|
50 | |
---|
51 | Operation |
---|
52 | ========= |
---|
53 | |
---|
54 | A small relocator is supplied in the bsp startup code which copies the |
---|
55 | image down to RAM for execution before doing any other initialization. |
---|
56 | This locator code is location independent, and will do nothing if the |
---|
57 | image is already located at its run location. The LMA and VMA are both |
---|
58 | controlled via the bsp's link script. The above behavior is produced by |
---|
59 | using the default script. If this is not desirable, something like the |
---|
60 | following may be added to the user's RTEMS link statement to override |
---|
61 | the default linkcmds with a user-supplied version; |
---|
62 | |
---|
63 | -qnolinkcmds -Wl,-T -Wl,mips-rtems-linkcmds-eprom |
---|
64 | |
---|
65 | this causes the file ./mips-rtems-linkcmds-eprom to override the default |
---|
66 | linkcmds. |
---|
67 | |
---|
68 | Before relocating the RTEMS image, the bsp startup routine attempts to |
---|
69 | configure the processor into a rational state. During this process, |
---|
70 | status characters are emitted at 19200N81 baud on UART port 0. |
---|
71 | |
---|
72 | |
---|
73 | Questions |
---|
74 | ========= |
---|
75 | |
---|
76 | Why can I send characters slowly to a Mongoose V, but get framing errors |
---|
77 | when sending them fast? |
---|
78 | |
---|
79 | - The MongooseV chip seems to <require> that all incoming data have 2 |
---|
80 | stop bits. When typing on a serial terminal, this is not an issue |
---|
81 | because the idle state of an RS232 line looks just like a stop bit- |
---|
82 | but when streaming in data, such pacing is required. The manual does |
---|
83 | not indicate anything along these lines, instead, we suspect a |
---|
84 | somewhat faulty UART design. |
---|
85 | |
---|
86 | |
---|
87 | Status |
---|
88 | ====== |
---|
89 | |
---|