sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update SH-1 status

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@1225 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
patacongo 2008-11-13 20:16:42 +00:00
parent 27f2657f12
commit 9160574c88
4 changed files with 150 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
ChangeLog
View File

@ -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.

22
Documentation/NuttX.html
View File

@ -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%">

25
TODO
View File

@ -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)
^^^^^^^^^^^^^^^^^^

97
configs/us7032evb1/README.txt
View File

@ -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