Update SH-1 status

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@1225 42af7a65-404d-4744-a932-0658087f49c3

4 files changed, 150 insertions, 7 deletions

diff --git a/nuttx/ChangeLog b/nuttx/ChangeLog
index 25fbdd30e..0d00c3f80 100644
--- a/nuttx/ChangeLog
+++ b/nuttx/ChangeLog
@@ -529,10 +529,17 @@
 	* Added port for the STMicro STR71x processor and configuration for the Olimex STR-P711
 	  board (STR71x testing is stalled because I have been unable to get OpenOCD to
 	  communicate with my JTAG wiggler on Linux).
-	* Fix race condition workaround delay in LPC214X SPI logic.  It the cause of the very
-	  bad MMC/SD performance.
+	* Fix race condition workaround delay in LPC214X SPI logic.  This was also the cause of the
+	  very bad MMC/SD performance.
 	* Began port of the Hitachi SH-1 using the SH-1/US7032EVB1 board
 	* Re-built all configurations that use SDCC and Zilog toolchains to make sure they still
 	  build (they didn't, but they do now).
 	* Fixed several erroneous "list empty" checks in the CAN driver.
-	* Hitachi SH-1 passes (reduced) examples/ostest (examples/nsh still fails)
+	* Hitachi SH-1 passes (reduced) examples/ostest; the examples/nsh test still fails.
+	  There are remaining instabilities that make the port un-usable.  The nature of these is
+	  not understood; the behavior is that certain SH-1 instructions stop working as advertised.
+	  This could be a silicon problem, some pipeline issue that is not handled properly by the
+	  gcc 3.4.5 toolchain (which has very limit SH-1 support to begin with), or perhaps with the
+	  CMON debugger.  At any rate, I have exhausted all of the energy that I am willing to put
+	  into this cool old processor for the time being.
+
diff --git a/nuttx/Documentation/NuttX.html b/nuttx/Documentation/NuttX.html
index 52c139bae..9c8e006af 100644
--- a/nuttx/Documentation/NuttX.html
+++ b/nuttx/Documentation/NuttX.html
@@ -717,7 +717,14 @@
     </p>
     <p>
      <b>STATUS:</b>
-      This port is in progress and should be available in the next release of NuttX.
+      This port is availble as of release 0.3.18 of NuttX.  The port is basically complete
+      and many examples run correctly.  However, there are remaining instabilities that
+      make the port un-usable.  The nature of these is not understood; the behavior is
+      that certain SH-1 instructions stop working as advertised.  This could be a silicon
+      problem, some pipeline issue that is not handled properly by the gcc 3.4.5 toolchain
+      (which has very limit SH-1 support to begin with), or perhaps with the CMON debugger.
+      At any rate, I have exhausted all of the energy that I am willing to put into this cool
+      old processor for the time being.
     </p>
    </td>
 </tr>
@@ -1165,18 +1172,25 @@ nuttx-0.3.18 2008-xx-xx Gregory Nutt &lt;spudmonkey@racsa.co.cr&gt;
 	* Added port for the STMicro STR71x processor and configuration for the Olimex STR-P711
 	  board (STR71x testing is stalled because I have been unable to get OpenOCD to
 	  communicate with my JTAG wiggler on Linux).
-	* Fix race condition workaround delay in LPC214X SPI logic.  It the cause of the very
-	  bad MMC/SD performance.
+	* Fix race condition workaround delay in LPC214X SPI logic.  This was also the cause of the
+	  very bad MMC/SD performance.
 	* Began port of the Hitachi SH-1 using the SH-1/US7032EVB1 board
 	* Re-built all configurations that use SDCC and Zilog toolchains to make sure they still
 	  build (they didn't, but they do now).
 	* Fixed several erroneous "list empty" checks in the CAN driver.
-	* Hitachi SH-1 passes (reduced) examples/ostest (examples/nsh still fails)
+	* Hitachi SH-1 passes (reduced) examples/ostest; the examples/nsh test still fails.
+	  There are remaining instabilities that make the port un-usable.  The nature of these is
+	  not understood; the behavior is that certain SH-1 instructions stop working as advertised.
+	  This could be a silicon problem, some pipeline issue that is not handled properly by the
+	  gcc 3.4.5 toolchain (which has very limit SH-1 support to begin with), or perhaps with the
+	  CMON debugger.  At any rate, I have exhausted all of the energy that I am willing to put
+	  into this cool old processor for the time being.
 
 pascal-0.1.3 2008-xx-xx Gregory Nutt &lt;spudmonkey@racsa.co.cr&gt;
 
 buildroot-0.1.3 2008-xx-xx &lt;spudmonkey@racsa.co.cr&gt;
 
+	* Add support for H8/300 toolchain
 </pre></ul>
 
 <table width ="100%">
diff --git a/nuttx/TODO b/nuttx/TODO
index 397b43319..f1ebc0ac0 100644
--- a/nuttx/TODO
+++ b/nuttx/TODO
@@ -22,6 +22,7 @@ NuttX TODO List (Last updated July 31, 2008)
   (6)  ARM/LPC214x (arch/arm/src/lpc214x/)
   (3)  ARM/STR71x (arch/arm/src/str71x/)
   (4)  pjrc-8052 / MCS51 (arch/pjrc-8051/)
+  (1)  SH-1 (arch/sh)
   (7)  z80/z8 (arch/z80/)
   (8)  z16 (arch/z16/)
 
@@ -467,6 +468,30 @@ o pjrc-8052 / MCS51 (arch/pjrc-8051/)
   Status:      Open
   Priority:    Low -- only because there as so many other issues with 8051
 
+
+o SH-1 (arch/sh)
+  ^^^^^^^^^^^^^^
+
+  Description:  There are instabilities that make the SH-1 port un-usable.  The
+                nature of these is not understood; the behavior is that certain SH-1
+                instructions stop working as advertised.  I have seen the following
+                examples:
+
+                  412b jmp @r1 - Set a return address in PR, i.e., it behaved like
+                       410b jsr @r1.  Normally 412b works correctly, but in the failure
+                       condition, it reliably set the PR.
+                  69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+.  This behavior
+                       does not correspond to any known SH-1 instruction
+
+                This could be a silicon problem, some pipeline issue that is not
+                handled properly by the gcc 3.4.5 toolchain (which has very limit
+                SH-1 support to begin with), or perhaps with the CMON debugger.  At
+                any rate, I have exhausted all of the energy that I am willing to put
+                into this cool old processor for the time being.
+  Status:       Open
+  Priority:     Low -- because the SH-1, SH7032, is very old and only of historical
+                interest.
+
 o z80/z8 (arch/z80)
  ^^^^^^^^^^^^^^^^^^
 
diff --git a/nuttx/configs/us7032evb1/README.txt b/nuttx/configs/us7032evb1/README.txt
index 5c9c04a3b..141a19178 100644
--- a/nuttx/configs/us7032evb1/README.txt
+++ b/nuttx/configs/us7032evb1/README.txt
@@ -1,3 +1,16 @@
+Status
+^^^^^^
+
+*** UNSTABLE ***
+The port is basically complete and many examples run correctly.  However, there
+are remaining instabilities that make the port un-usable.  The nature of these
+is not understood; the behavior is that certain SH-1 instructions stop working
+as advertised.  This could be a silicon problem, some pipeline issue that is not
+handled properly by the gcc 3.4.5 toolchain (which has very limit SH-1 support
+to begin with), or perhaps with the CMON debugger.  At any rate, I have exhausted
+all of the energy that I am willing to put into this cool old processor for the
+time being.
+
 Toolchain
 ^^^^^^^^^
 
@@ -39,3 +52,87 @@ shterm
   The shterm subdirectory contains a small terminal emulation
   program that supports these special interactions for file transfers.
 
+Configurations
+^^^^^^^^^^^^^^
+
+Each SH-1 configuration is maintained in a sudirectory and
+can be selected as follow:
+
+	cd tools
+	./configure.sh us7032evb1/<subdir>
+	cd -
+	. ./setenv.sh
+
+Where <subdir> is one of the following:
+
+ostest
+^^^^^^as advertised.  This could be a silicon problem, some pipeline issue that is not handled properly by the gcc 3.4.5 tool
+
+This configuration directory, performs a simple OS test using
+examples/ostest.
+
+nsh
+^^^
+
+Configures the NuttShell (nsh) located at examples/nsh.  The
+Configuration enables only the serial NSH interfaces.
+
+NOTE:  At present, the NSH example does not run.  See the "Status"
+discussion above for a full explanation.
+
+Configuration Options
+^^^^^^^^^^^^^^^^^^^^^
+
+In additional to the common configuration options listed in the
+file configs/README.txt, there are other configuration options
+specific to the SH-1
+
+Architecture selection
+
+  CONFIG_ARCH - identifies the arch subdirectory and, hence, the
+    processor architecture.  This should be sh (for arch/sh)
+  CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory.
+    This should be sh1 (for arch/sh/src/sh1 and arch/sh/include/sh1)
+  CONFIG_ARCH_SH1 andCONFIG_ARCH_SH7032 - for use in C code.  These
+    identify the particular chip or SoC that the architecture is
+    implemented in.
+  CONFIG_ARCH_BOARD - identifies the configs subdirectory and, hence,
+    the board that supports the particular chip or SoC.  This
+    should be us7032evb1 for (configs/us7032evb1).
+  CONFIG_ARCH_BOARD_US7032EVB1 - for use in C code
+  CONFIG_ENDIAN_BIG - the SH-1 usually runs big-endian
+  CONFIG_ARCH_NOINTC - define if the architecture does not
+    support an interrupt controller or otherwise cannot support
+    APIs like up_enable_irq() and up_disable_irq().  Should be
+    defined.
+  CONFIG_ARCH_IRQPRIO
+    Define if the architecture suports prioritizaton of interrupts
+    and the up_prioritize_irq() API.  Should be defined.
+  CONFIG_BOARD_LOOPSPERMSEC - for delay loops
+  CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to SH1_LCEVB1
+  CONFIG_DRAM_SIZE - Describes the internal DRAM.
+  CONFIG_DRAM_START - The start address of internal DRAM
+  CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
+    stack. If defined, this symbol is the size of the interrupt
+    stack in bytes.  If not defined, the user task stacks will be
+    used during interrupt handling.
+  CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions
+
+  CONFIG_SH1_DMAC0, CONFIG_SH1_DMAC1, CONFIG_SH1_DMAC2, CONFIG_SH1_DMAC3,
+  CONFIG_SH1_ITU1, CONFIG_SH1_ITU2, CONFIG_SH1_ITU3, CONFIG_SH1_ITU4,
+  CONFIG_SH1_SCI0, CONFIG_SH1_SCI1, CONFIG_SH1_PCU, CONFIG_SH1_AD,
+  CONFIG_SH1_WDT, CONFIG_SH1_CMI - Each unused chip block should b
+    disabled to save space
+
+SH1 specific device driver settings
+
+  CONFIG_SCIn_SERIAL_CONSOLE - selects the SCIn for the
+    console and ttys0 (default is the UART0).
+  CONFIG_SCIn_RXBUFSIZE - Characters are buffered as received.
+    This specific the size of the receive buffer
+  CONFIG_SCIn_TXBUFSIZE - Characters are buffered before
+    being sent.  This specific the size of the transmit buffer
+  CONFIG_SCIn_BAUD - The configure BAUD of the UART.  Must be
+  CONFIG_SCIn_BITS - The number of bits.  Must be either 7 or 8.
+  CONFIG_SCIn_PARTIY - 0=no parity, 1=odd parity, 2=even parity, 3=mark 1, 4=space 0
+  CONFIG_SCIn_2STOP - Two stop bits