Some toolchains are built with header files extracted from a C-library
distribution (such as newlib). These header files must *not* be used
with NuttX because NuttX provides its own, built-in C-Library. For
toolchains that do include built-in header files from a foreign C-
Library, NuttX must be compiled without using the standard header files
that are distributed with your toolchain. This prevents including
conflicting, incompatible header files (such as stdio.h).
Header Files Provided by Your Toolchain.
Certain header files, such as setjmp.h, stdarg.h, and math.h, may still
be needed from your toolchain and your compiler may not, however, be able
to find these if you compile NuttX without using standard header file.
If that is the case, one solution is to copy those header file from
your toolchain into the NuttX include directory.
Duplicated Header Files.
There are also a few header files that can be found in the nuttx/include
directory which are duplicated by the header files from your toolchain.
stdint.h and stdbool.h are examples. If you prefer to use the stdint.h
and stdbool.h header files from your toolchain, those could be copied
into the nuttx/include/ directory. Using most other header files from
your toolchain would probably cause errors.
math.h
Even though you should not use a foreign C-Library, you may still need
to use other, external libraries with NuttX. In particular, you may
need to use the math library, libm.a. The math libary header file,
math.h, is a special case. If you do nothing, the standard math.h
header file that is provided with your toolchain will be used.
If you have a custom, architecture specific math.h header file, then
that header file should be placed at arch/<cpu>/include/math.h. There
is a stub math.h header file located at include/nuttx/math.h. This stub
header file can be used to "redirect" the inclusion to an architecture-
specific math.h header file. If you add an architecture specific math.h
header file then you should also define CONFIG_ARCH_MATH_H=y in your
NuttX Configuration file. If CONFIG_ARCH_MATH_H is selected, then the
top-level Makefile will copy the stub math.h header file from
include/nuttx/matn.h to include/math.h where it will become the system
math.h header file. The stub math.h header file does nothing other
than to include that archicture-specific math.h header file as the
system math.h header file.
stdarg.h
In most cases, the correct version of stdarg.h is the version provided with your toolchain. However, sometimes there are issues with with using your toolchains stdarg.h. For example, it may attempt to draw in header files that do not exist in NuttX or perhaps the header files that is uses are not compatible with the NuttX header files. In those cases, you can use an architecture-specific stdarg.h header file by defining CONFIG_ARCH_STDARG_H=y.
See the discussion above for the math.h header. This setting works exactly
the same for the stdarg.h header file.
CONFIGURING NUTTX
^^^^^^^^^^^^^^^^^
Instantiating "Canned" Configurations
-------------------------------------
"Canned" NuttX configuration files are retained in:
configs/<board-name>/<config-dir>
Where <board-name> is the name of your development board and <config-dir>.
Configuring NuttX requires only copying three files from the <config-dir>
to the directly where you installed NuttX (TOPDIR):
Copy configs/<board-name>/<config-dir>/Make.def to ${TOPDIR}/Make.defs
Make.defs describes the rules needed by you tool chain to compile
and link code. You may need to modify this file to match the
specific needs of your toolchain.
Copy configs/<board-name>/<config-dir>/setenv.sh to ${TOPDIR}/setenv.sh
setenv.sh is an optional convenience file that I use to set
the PATH variable to the toolchain binaries. You may chose to
use setenv.sh or not. If you use it, then it may need to be
modified to include the path to your toolchain binaries.
Copy configs/<board-name>/<config-dir>/defconfig to ${TOPDIR}/.config
The defconfig file holds the actual build configuration. This
file is included by all other make files to determine what is
included in the build and what is not. This file is also used
to generate a C configuration header at include/nuttx/config.h.
General information about configuring NuttX can be found in:
${TOPDIR}/configs/README.txt
${TOPDIR}/configs/<board-name>/README.txt
There is a configuration script in the tools/ directory that makes this
easier. It is used as follows:
cd ${TOPDIR}/tools
./configure.sh <board-name>/<config-dir>
NuttX Configuration Tool
------------------------
An automated tool is under development to support re-configuration
of NuttX. This tool, however, is not yet quite ready for general
usage.
This automated tool is based on the kconfig-frontends application
available at http://ymorin.is-a-geek.org/projects/kconfig-frontends
(A snapshot of this tool is also available at ../misc/tools). This
application provides a tool called 'mconf' that is used by the NuttX
top-level Makefile. The following make target is provided:
make menuconfig
This make target will bring up NuttX configuration menus. The
'menuconfig' target depends on two things:
1. The Kconfig configuration data files that appear in almost all
NuttX directories. These data files are the part that is still
under development (patches are welcome!). The Kconfig files
contain configuration information for the configuration settings
relevant to the directory in which the Kconfig file resides.
NOTE: For a description of the syntax of this configuration file,
see ../misc/tools/kconfig-language.txt.
2. The 'mconf' tool. 'mconf' is part of the kconfig-frontends
package. You can download that package from the website
http://ymorin.is-a-geek.org/projects/kconfig-frontends or you
can use the snapshot in ../misc/tools.
Building may be as simple as 'configure; make; make install'
but there may be some build complexities, especially if you
are building under Cygwin. See the more detailed build
instructions at ../misc/tools/README.txt
The 'make install' step will, by default, install the 'mconf'
tool at /usr/local/bin/mconf. Where ever you choose to
install 'mconf', make certain that your PATH variable includes
a path to that installation directory.
TOOLCHAINS
^^^^^^^^^^
Cross-Development Toolchains
----------------------------
In order to build NuttX for your board, you will have to obtain a cross-
compiler to generate code for your target CPU. For each board,
configuration, there is a README.txt file (at configs/<board-name>/README.txt).
That README file contains suggestions and information about appropriate
tools and development environments for use with your board.
In any case, the script, setenv.sh that was deposited in the top-
level directory when NuttX was configured should be edited to set
the path to where you installed the toolchain. The use of setenv.sh
is optional but can save a lot of confusion in the future.
NuttX Buildroot Toolchain
-------------------------
For many configurations, a DIY set of tools is available for NuttX. These
tools can be downloaded from the NuttX SourceForge file repository. After
unpacking the buildroot tarball, you can find instructions for building
the tools in the buildroot/configs/README.txt file.
Check the README.txt file in the configuration director for your board
to see if you can use the buildroot toolchain with your board (this
README.txt file is located in configs/<board-name>/README.txt).
This toolchain is available for both the Linux and Cygwin development
environments.
Advantages: (1) NuttX header files are built into the tool chain,
and (2) related support tools like NXFLAT tools and the ROMFS
genromfs tools can be built into your toolchain.
Disadvantages: This tool chain is not was well supported as some other
toolchains. GNU tools are not my priority and so the buildroot tools
often get behind. For example, the is still no EABI support in the
NuttX buildroot toolchain for ARM.
SHELLS
^^^^^^
The NuttX build relies on some shell scripts. Some are inline in the
Makefiles and many are exectuble scripts in the tools/. directory. The
scripts were all developed using bash and many contain bash shell
dependencies.
Most of the scripts begin with #!/bin/bash to specifically select the
bash shell. Some still have #!/bin/sh but I haven't heard any complaints
so these must not have bash dependencies.
There are two shell issues that I have heard of:
1. Linux where /bin/sh refers to an incompatible shell (like ksh or csh).
In this case, bash is probably avaiable and the #!/bin/bash at the
beginning of the file should do the job. If any scripts with #!/bin/sh
fail, try changing that ti #!/bin/bash and let me know about the change.
2. FreeBSD with the Bourne Shell and no bash shell.
The other, reverse case has also been reported on FreeBSD setups that
have the Bourne shell, but not bash. In this base, #!/bin/bash fails
but #!/bin/sh works okay. My recommendation in this case is to create
a symbolic link at /bin/bash that refers to the Bourne shell.
There may still be issues, however, with certain the bash-centric scripts
that will require modifications.
BUILDING NUTTX
^^^^^^^^^^^^^^
Building
--------
NuttX builds in-place in the source tree. You do not need to create
any special build directories. Assuming that your Make.defs is setup
properly for your tool chain and that setenv.sh contains the path to where
your cross-development tools are installed, the following steps are all that
are required to build NuttX:
cd ${TOPDIR}
. ./setenv.sh
make
At least one configuration (eagle100) requires additional command line
arguments on the make command. Read ${TOPDIR}/configs/<board-name>/README.txt
to see if that applies to your target.
Re-building
-----------
Re-building is normally simple -- just type make again.
But there are some things that can "get you" when you use the Cygwin
development environment with Windows native tools. The native Windows
tools do not understand Cygwin's symbolic links, so the NuttX make system
does something weird: It copies the configuration directories instead of
linking to them (it could, perhaps, use the NTFS 'mklink' command, but it
doesn't).
A consequence of this is that you can easily get confused when you edit
a file in one of the linked (i.e., copied) directories, re-build NuttX,
and then not see your changes when you run the program. That is because
build is still using the version of the file in the copied directory, not
your modified file! To work around this annoying behavior, do the
following when you re-build:
make clean_context all
This 'make' command will remove of the copied directories, re-copy them,
