diff --git a/ChangeLog b/ChangeLog
index 25fbdd30ed655aaf36505af969f1344f8d4c58e6..0d00c3f80032f5ca0abb1318ece3e74103c5159d 100644
--- a/ChangeLog
+++ b/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/Documentation/NuttX.html b/Documentation/NuttX.html
index 52c139bae28ba53400f8a1d80f8a8e2e377f2ea9..9c8e006afbd5da30912b7328a2519daa3cae9f66 100644
--- a/Documentation/NuttX.html
+++ b/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 <spudmonkey@racsa.co.cr>
* 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 <spudmonkey@racsa.co.cr>
buildroot-0.1.3 2008-xx-xx <spudmonkey@racsa.co.cr>
+ * Add support for H8/300 toolchain
</pre></ul>
<table width ="100%">
diff --git a/TODO b/TODO
index 397b43319e4fb1a648f929116ebc2541f0519e24..f1ebc0ac0c279fb277712b4262b860ed35ebfee0 100644
--- a/TODO
+++ b/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/configs/us7032evb1/README.txt b/configs/us7032evb1/README.txt
index 5c9c04a3b2174c9707a9a857f68deaf3a1753323..141a191781d5f38a2b4f737458444397db206606 100644
--- a/configs/us7032evb1/README.txt
+++ b/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