nuttx/boards/z80/ez80/ez80f910200kitg/README.txt
Alin Jerpelea a06033df64 Merged in alinjerpelea/nuttx (pull request #971)
codestyle fixes

* misoc: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* or1k: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* renesas: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* risc-v: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* sim: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* x86: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* xtensa: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* z16: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

* z80: codestyle fixes

     After the board restructuration is time for codestyle cleanup

    Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>

Approved-by: Gregory Nutt <gnutt@nuttx.org>
2019-08-09 13:22:39 +00:00

138 lines
5.1 KiB
Plaintext

README.txt
^^^^^^^^^^
ZDS-II Compiler Versions
^^^^^^^^^^^^^^^^^^^^^^^^
Different configurations have been build for this board using ZDS-11
Versions 4.11.0, 4.11.1, and 5.1.1 You have to check the files */Make.defs
to see how the build is configured: Check the definitions of
ZDSVERSION (if present) and ZDSINSTALLDIR.
NOTE: Different versions of the ZDS-II compiler may also require
different versions of .linkcmd and .zdsproj files as well.
Version 4.11.0
The 5.1.1 version of the ZDS-II tools are currently configured for
all ez80 boards. However, it is the older version 4.11.0 that this code
has been verified against.
Although it compiles without error, the 4.11.0 compiler generates
bad code on one of the files, mm/mm_initialize.c. Below is a simple work-
around.
--- mm/mm_initialize.c.SAVE 2008-02-13 08:06:46.833857700 -0600
+++ mm/mm_initialize.c 2008-02-13 08:07:26.367608900 -0600
@@ -94,8 +94,11 @@
{
int i;
+#if 0 /* DO NOT CHECK IN */
CHECK_ALLOCNODE_SIZE;
CHECK_FREENODE_SIZE;
+#endif
/* Set up global variables */
UPDATE: I don't know if 4.11.1 has this same problem (I bet not since
I submitted the bug to ZiLOG), but I have permanently worked around the
above problem for all ZiLOG compilers.
Version 5.1.1
On June 22, 2011 I verified that these configurations build successfully
with the 5.1.1 ZDS-II version. On November 12, 2012, all of the configurations
were converted to use 5.1.1, but have not been verified on a running target.
The above kludge for 4.11.0 is not required with 5.1.1.
Paths were also updated that are specific to a 32-bit toolchain running on
a 64 bit windows platform. Change to a different toolchain, you will need
to modify the versioning in Make.defs; if you want to build on a different
platform, you will need to change the path in the ZDS binaries in that files
and also in your PATH environment variable.
Version 5.2.1
On January 31, 2016, I tried ZDS-II version 5.2.1. I believe that I have
all of the changes in place to support that version. At compile time,
however, I encountered compiler internal errors. I did not pursue that
build any further.
Version 5.3.0
I verified compilation using 5.30 on June 2, 2019. To use this version,
I had to make spurious modification to the implementation of gmtimer() to
work around an internal compiler error. I have still not verified that
are no errors in the compiled code.
Other Versions
If you use any version of ZDS-II other than 5.1.1, 5.2.1, or 5.3.0 or
if you install ZDS-II at any location other than the default location,
you will have to modify three files: (1) arch/arm/z80/src/ez80/Kconfig,
(2) boards/z80/ez80/ez80f910200kitg/scripts/Make.defs and, perhaps, (3)
arch/z80/src/ez80/Toolchain.defs.
Configuration Subdirectories
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- src/ and include/
These directories contain common logic for all ez80f910200kitg
configurations.
Variations on the basic ez80f910200kitg configuration are maintained
in subdirectories. To configure any specific configuration, do the
following steps:
tools/configure.sh ez80f910200kitg:<sub-directory>
make
Where <sub-directory> is the specific board configuration that you
wish to build. The following board-specific configurations are
available:
- ostest
This builds the examples/ostest application for execution from FLASH.
See examples/README.txt for information about ostest.
NOTES:
1. This configuration uses the mconf-based configuration tool. To
change this configuration using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
2. By default, this configuration assumes that you are using the
Cygwin environment on Windows. An option is to use the native
CMD.exe window build as described in the top-level README.txt
file. To set up that configuration:
-CONFIG_WINDOWS_CYGWIN=y
+CONFIG_WINDOWS_NATIVE=y
And after configuring, make sure that CONFIG_APPS_DIR uses
the back slash character. For example:
CONFIG_APPS_DIR="..\apps"
NOTES:
a. If you need to change the toolchain path used in Make.defs, you
will need to use the short 8.3 filenames to avoid spaces. On my
PC, C:\PROGRA~1\ is is C:\Program Files\ and C:\PROGRA~2\ is
C:\Program Files (x86)\
b. At present, the native Windows build fails at the final link stages.
The failure is due to problems in arch/z80/src/nuttx.linkcmd that
is autogenerated by arch/z80/src/Makefile.zdsii. The basic problem
is the spurious spaces and and carrirage returns are generated at
the end of the lines after a line continuation (\ ^M). If these
trailing bad characters are manually eliminated, then the build
will succeed on the next try.
Check out any README.txt files in these <sub-directory>s.