Subversion Repositories openrisc_2011-10-31

#
#  $Id: README,v 1.2 2001-09-27 12:00:20 chris Exp $
#

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.