2008-12-04 Jukka Pietarinen <jukka.pietarinen@mrf.fi>

	* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
	cpu_supplement/cpu_supplement.texi: Add Lattice Mico32 support.
	* cpu_supplement/lm32.t: New file.

5 files changed, 205 insertions, 4 deletions

diff --git a/doc/ChangeLog b/doc/ChangeLog
index 44cff03f85..8352484ff0 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,9 @@
+2008-12-04	Jukka Pietarinen <jukka.pietarinen@mrf.fi>
+
+	* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
+	cpu_supplement/cpu_supplement.texi: Add Lattice Mico32 support.
+	* cpu_supplement/lm32.t: New file.
+
 2008-12-01	Joel Sherrill <joel.sherrill@oarcorp.com>
 
 	* ada_user/Makefile.am: Fix typo.
diff --git a/doc/cpu_supplement/.cvsignore b/doc/cpu_supplement/.cvsignore
index 9e74f55449..119eeab730 100644
--- a/doc/cpu_supplement/.cvsignore
+++ b/doc/cpu_supplement/.cvsignore
@@ -24,6 +24,7 @@ cpu_supplement.vr
 general.texi
 i386.texi
 index.html
+lm32.texi
 m68k.texi
 Makefile
 Makefile.in
diff --git a/doc/cpu_supplement/Makefile.am b/doc/cpu_supplement/Makefile.am
index d45b4eab14..1de6ce65f0 100644
--- a/doc/cpu_supplement/Makefile.am
+++ b/doc/cpu_supplement/Makefile.am
@@ -21,8 +21,8 @@ TEXI2WWW_ARGS=\
 -header rtems_header.html \
 -footer rtems_footer.html \
 -icons ../images
-GENERATED_FILES = general.texi arm.texi bfin.texi i386.texi m68k.texi mips.texi \
-    powerpc.texi sh.texi sparc.texi tic4x.texi
+GENERATED_FILES = general.texi arm.texi bfin.texi i386.texi lm32.texi \
+    m68k.texi mips.texi powerpc.texi sh.texi sparc.texi tic4x.texi
 
 COMMON_FILES += $(top_srcdir)/common/cpright.texi
 
@@ -55,6 +55,11 @@ i386.texi: i386.t
 	    -u "Top" \
 	    -n "" < $< > $@
 
+lm32.texi: lm32.t
+	$(BMENU2) -p "" \
+	    -u "Top" \
+	    -n "" < $< > $@
+
 m68k.texi: m68k.t
 	$(BMENU2) -p "" \
 	    -u "Top" \
diff --git a/doc/cpu_supplement/cpu_supplement.texi b/doc/cpu_supplement/cpu_supplement.texi
index a609f6f0fc..fc18653ca7 100644
--- a/doc/cpu_supplement/cpu_supplement.texi
+++ b/doc/cpu_supplement/cpu_supplement.texi
@@ -8,7 +8,7 @@
 @c %**end of header
 
 @c
-@c  COPYRIGHT (c) 1988-2002.
+@c  COPYRIGHT (c) 1988-2008.
 @c  On-Line Applications Research Corporation (OAR).
 @c  All rights reserved.
 @c
@@ -16,7 +16,7 @@
 @c
 
 @c
-@c   Master file for the SPARC Applications Supplement
+@c   Master file for the CPU Supplement
 @c
 
 @include version.texi
@@ -63,6 +63,7 @@
 @include arm.texi
 @include bfin.texi
 @include i386.texi
+@include lm32.texi
 @include m68k.texi
 @include mips.texi
 @include powerpc.texi
@@ -81,6 +82,7 @@ This is the online version of the RTEMS CPU Architecture Supplement.
 * ARM Specific Information::
 * Blackfin Specific Information::
 * Intel/AMD x86 Specific Information::
+* Lattice Mico32 Specific Information::
 * M68xxx and Coldfire Specific Information::
 * MIPS Specific Information::
 * PowerPC Specific Information::
diff --git a/doc/cpu_supplement/lm32.t b/doc/cpu_supplement/lm32.t
new file mode 100644
index 0000000000..6befa7a9df
--- /dev/null
+++ b/doc/cpu_supplement/lm32.t
@@ -0,0 +1,187 @@
+@c
+@c  COPYRIGHT (c) 1988-2002.
+@c  On-Line Applications Research Corporation (OAR).
+@c  All rights reserved.
+@c
+@c  $Id$
+@c
+@c  Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008,
+@c  Micro-Research Finland Oy
+@c
+
+@ifinfo
+@end ifinfo
+@chapter Lattice Mico32 Specific Information
+
+This chaper discusses the Lattice Mico32 architecture dependencies in
+this port of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC
+architecture "soft" microprocessor, available for free with an open IP
+core licensing agreement. Although mainly targeted for Lattice FPGA
+devices the microprocessor can be implemented on other vendors' FPGAs,
+too.
+
+@subheading Architecture Documents
+
+For information on the Lattice Mico32 architecture, refer to the
+following documents available from Lattice Semiconductor
+@file{http://www.latticesemi.com/}.
+
+@itemize @bullet
+@item @cite{"LatticeMico32 Processor Reference Manual"}
+@file{http://www.latticesemi.com/dynamic/view_document.cfm?document_id=20890}
+@end itemize
+
+@c
+@c
+@c
+@section CPU Model Dependent Features
+
+The Lattice Mico32 architecture allows for different configurations of
+the processor. This port is based on the assumption that the following options are implemented:
+
+@itemize @bullet
+@item hardware multiplier
+@item hardware divider
+@item hardware barrel shifter
+@item sign extension instructions
+@item instruction cache
+@item data cache
+@item debug
+@end itemize
+
+@c
+@c
+@c
+@section Register Architecture
+
+This section gives a brief introduction to the register architecture
+of the Lattice Mico32 processor.
+
+The Lattice Mico32 is a RISC archictecture processor with a
+32-register file of 32-bit registers.
+
+@multitable {Register Name} {general pupose / global pointer}
+@headitem Register Name @tab Function
+@item r0     @tab holds value zero
+@item r1-r25 @tab general purpose
+@item r26/gp @tab general pupose / global pointer
+@item r27/fp @tab general pupose / frame pointer
+@item r28/sp @tab stack pointer
+@item r29/ra @tab return address
+@item r30/ea @tab exception address
+@item r31/ba @tab breakpoint address
+@end multitable
+
+Note that on processor startup all register values are undefined
+including r0, thus r0 has to be initialized to zero.
+
+@c
+@c
+@c
+@section Calling Conventions
+
+@subsection Calling Mechanism
+
+A call instruction places the return address to register r29 and a
+return from subroutine (ret) is actually a branch to r29/ra.
+
+@subsection Register Usage
+
+A subroutine may freely use registers r1 to r10 which are @b{not}
+preserved across subroutine invocations.
+
+@subsection Parameter Passing
+
+When calling a C function the first eight arguments are stored in
+registers r1 to r8. Registers r1 and r2 hold the return value.
+
+@c
+@c
+@c
+@section Memory Model
+
+The Lattice Mico32 processor supports a flat memory model with a 4
+Gbyte address space with 32-bit addresses.
+
+The following data types are supported:
+
+@multitable {unsigned half-word} {Bits} {unsigned int / unsigned long}
+@headitem Type           @tab Bits @tab C Compiler Type
+@item unsigned byte      @tab 8    @tab unsigned char
+@item signed byte        @tab 8    @tab char
+@item unsigned half-word @tab 16   @tab unsigned short
+@item signed half-word   @tab 16   @tab short
+@item unsigned word      @tab 32   @tab unsigned int / unsigned long
+@item signed word        @tab 32   @tab int / long
+@end multitable
+
+Data accesses need to be aligned, with unaligned accesses result are
+undefined.
+
+@c
+@c
+@c
+@section Interrupt Processing
+
+The Lattice Mico32 has 32 interrupt lines which are however served by
+only one exception vector. When an interrupt occurs following happens:
+
+@itemize @bullet
+@item address of next instruction placed in r30/ea
+@item IE field of IE CSR saved to EIE field and IE field cleared preventing further exceptions from occuring.
+@item branch to interrupt exception address EBA CSR + 0xC0
+@end itemize
+
+The interrupt exception handler determines from the state of the
+interrupt pending registers (IP CSR) and interrupt enable register (IE
+CSR) which interrupt to serve and jumps to the interrupt routine
+pointed to by the corresponding interrupt vector.
+
+For now there is no dedicated interrupt stack so every task in
+the system MUST have enough stack space to accommodate the worst
+case stack usage of that particular task and the interrupt
+service routines COMBINED.
+
+Nested interrupts are not supported.
+
+@c
+@c
+@c
+@section Default Fatal Error Processing
+
+Upon detection of a fatal error by either the application or RTEMS during
+initialization the @code{rtems_fatal_error_occurred} directive supplied
+by the Fatal Error Manager is invoked.  The Fatal Error Manager will
+invoke the user-supplied fatal error handlers.  If no user-supplied
+handlers are configured or all of them return without taking action to
+shutdown the processor or reset, a default fatal error handler is invoked.
+
+Most of the action performed as part of processing the fatal error are
+described in detail in the Fatal Error Manager chapter in the User's
+Guide.  However, the if no user provided extension or BSP specific fatal
+error handler takes action, the final default action is to invoke a
+CPU architecture specific function.  Typically this function disables
+interrupts and halts the processor.
+
+In each of the architecture specific chapters, this describes the precise
+operations of the default CPU specific fatal error handler.
+
+@c
+@c
+@c
+
+@section Board Support Packages
+
+An RTEMS Board Support Package (BSP) must be designed to support a
+particular processor model and target board combination.
+
+In each of the architecture specific chapters, this section will present
+a discussion of architecture specific BSP issues.   For more information
+on developing a BSP, refer to BSP and Device Driver Development Guide
+and the chapter titled Board Support Packages in the RTEMS
+Applications User's Guide.
+
+@subsection System Reset
+
+An RTEMS based application is initiated or re-initiated when the processor
+is reset.