# # $Id$ # BSP NAME: ods68302 BOARD: proprietary (see below for relevant information) BUS: none CPU FAMILY: MC68000 COPROCESSORS: 68302 communications co-processor MODE: not applicable DEBUG MONITOR: gdb PERIPHERALS =========== TIMERS: two 68302 timers, one 68302 watchdog timer RESOLUTION: ? SERIAL PORTS: three 68302 SCCs REAL-TIME CLOCK: DMA: built-in 68302, not used VIDEO: none SCSI: none NETWORKING: none DRIVER INFORMATION ================== CLOCK DRIVER: 68302 (TIMER1) IOSUPP DRIVER: 68302 SCC2 SHMSUPP: none TIMER DRIVER: 68302 TIMER2 STDIO ===== PORT: SCC3 for ROM build, SCC1 for DEGUB build ELECTRICAL: EIA-232 BAUD: 9600 BITS PER CHARACTER: 8 PARITY: None STOP BITS: 1 DEBUG MONITOR ============= PORT: SCC3 ELECTRICAL: EIA-232 BAUD: 57600 BITS PER CHARACTER: 8 PARITY: None STOP BITS: 1 NOTES ===== This BSP is based on the gen68302. The main differences are C code for boot parameters, the gdb monitor, and variant support. The boot code which changes is written in C and the parameters used to control the configuration of the chip select registers and parallel ports are held in variant specific header files. These file also control the other hardware specific definitions such the processor freqency. The gdb monitor currently uses two serial ports. One for the debugger and one for stdio. This is costly in terms of the 68302 processor. The build configuration contains the memory map. The bsp code does not contain any memory map parameters. That is the ods68302.cfg contains the link addresses. To build a version to download via gdb use the command line parameters to make or "RTEMS_DEBUGGER=yes". This will change the memory map to place the code, and data above the RAM used by the gdb stub. TODO ==== 1) Lower the set size of the gdb monitor. This can be made to be about 10K or RAM. The code is about 14K. 2) Add the production memory test code. This will be C and asm code. The asm will be a faster version of the C.