mirror of
https://github.com/apache/nuttx.git
synced 2026-05-20 04:16:35 +08:00
docs/components/tools: Give tools their own doc pages
All of the tools listed on the original documentation are now given their own individual doc pages. This makes it much easier to cross-reference them from other documentation locations (as many are used in CI/for specific architectures) and it also makes it easier for users to digest the information. Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
This commit is contained in:
Matteo Golin
simbit18
@@ -0,0 +1,75 @@
|
||||
================
|
||||
``abi_check.py``
|
||||
================
|
||||
|
||||
``abi_check.py`` is a Python tool for checking binary compatibility based on
|
||||
DWARF debug information.
|
||||
|
||||
It supports three related workflows:
|
||||
|
||||
1. Given one or more static libraries (``.a``) and an ELF file, collect the
|
||||
undefined (external) symbols referenced by the libraries, locate those
|
||||
functions in the ELF file, and write their function signatures to a JSON
|
||||
file.
|
||||
2. Generate two JSON files from two different ELF files (for example, an old
|
||||
build and a new build), and compare the signatures of functions with the
|
||||
same name (return type, parameters, and for structs also size, member
|
||||
offsets, member types, etc.).
|
||||
3. Given a single ELF file, detect structs with the same name but different
|
||||
members.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Python 3
|
||||
- ``pyelftools`` (used to read ELF/DWARF)
|
||||
- ``ar`` (used to extract object files from ``.a`` archives)
|
||||
- ``pahole`` (only for ``--struct_check``)
|
||||
|
||||
.. note::
|
||||
|
||||
Although the help text mentions ``.so``, the current implementation uses
|
||||
``ar x`` on each ``--lib`` input, so it expects ``.a`` archives.
|
||||
|
||||
Help message::
|
||||
|
||||
$ python3 tools/abi_check.py -h
|
||||
usage: abi_check.py [-h] [-a LIB [LIB ...]] [-e ELF] [-c] [-d] [-j JSON] [-s]
|
||||
[-i INPUT_JSON INPUT_JSON]
|
||||
|
||||
This tool is used to check the binary compatibility of static libraries and has the following features:
|
||||
1. The input consists of multiple static libraries and an ELF file. The tool searches
|
||||
for external APIs used by the static libraries, then locates these API function signatures
|
||||
in the ELF file, and outputs the results as a JSON file.
|
||||
2. Using the first feature, with the static libraries unchanged,
|
||||
the tool can take a new ELF file and an old ELF file as input, output two JSON files,
|
||||
and compare the function signatures of functions with the same name in the two JSON files.
|
||||
The comparison includes return values, parameters, and if they are structures,
|
||||
it also compares the structure size, member offsets, member types, etc.
|
||||
3.When the input is a single ELF file, the tool can check if structures with the same name have different members.
|
||||
|
||||
options:
|
||||
-h, --help show this help message and exit
|
||||
-a LIB [LIB ...], --lib LIB [LIB ...]
|
||||
Path to liba.so or lib.a
|
||||
-e ELF, --elf ELF Path to elf file
|
||||
-c, --check If the static library contains debug information,
|
||||
try to find the function in the static library,
|
||||
and output the result to lib_<json> file
|
||||
-d, --dump Dump result
|
||||
-j JSON, --json JSON Save result to json file
|
||||
-s, --struct_check Dump struct different
|
||||
-i INPUT_JSON INPUT_JSON, --input_json INPUT_JSON INPUT_JSON
|
||||
Diff two json files
|
||||
|
||||
Examples::
|
||||
|
||||
# 1) Extract signatures for external APIs referenced by one or more archives
|
||||
$ python3 tools/abi_check.py -a libfoo.a libbar.a -e nuttx -j out.json
|
||||
|
||||
# 2) Compare signatures across two ELF files
|
||||
$ python3 tools/abi_check.py -a libfoo.a libbar.a -e nuttx_old -j old.json
|
||||
$ python3 tools/abi_check.py -a libfoo.a libbar.a -e nuttx_new -j new.json
|
||||
$ python3 tools/abi_check.py -i old.json new.json
|
||||
|
||||
# 3) Find struct definition mismatches within a single ELF
|
||||
$ python3 tools/abi_check.py -e nuttx -s
|
||||
@@ -0,0 +1,137 @@
|
||||
=================
|
||||
``bdf-convert.c``
|
||||
=================
|
||||
|
||||
This C file is used to build the bdf-converter program. The bdf-converter
|
||||
program can be used to convert fonts in Bitmap Distribution Format (BDF)
|
||||
into fonts that can be used in the NX graphics system.
|
||||
|
||||
Below are general instructions for creating and installing a new font
|
||||
in the NX graphic system:
|
||||
|
||||
1. Locate a font in BDF format,
|
||||
2. Use the bdf-converter program to convert the BDF font to the NuttX
|
||||
font format. This will result in a C header file containing
|
||||
definitions. That header file should be installed at, for example,
|
||||
libnx/nxfonts/nxfonts_myfont.h.
|
||||
|
||||
Create a new NuttX configuration variable. For example, suppose
|
||||
you define the following variable: CONFIG_NXFONT_MYFONT. Then
|
||||
you would need to:
|
||||
|
||||
3. Define CONFIG_NXFONT_MYFONT=y in your NuttX configuration file.
|
||||
|
||||
A font ID number has to be assigned for each new font. The font ID
|
||||
is defined in the file include/nuttx/nx/nxfonts.h. Those definitions
|
||||
have to be extended to support your new font. Look at how the font ID
|
||||
enabled by CONFIG_NXFONT_SANS23X27 is defined and add an ID for your
|
||||
new font in a similar fashion:
|
||||
|
||||
4. include/nuttx/nx/nxfonts.h. Add your new font as a possible system
|
||||
default font::
|
||||
|
||||
#if defined(CONFIG_NXFONT_SANS23X27)
|
||||
# define NXFONT_DEFAULT FONTID_SANS23X27
|
||||
#elif defined(CONFIG_NXFONT_MYFONT)
|
||||
# define NXFONT_DEFAULT FONTID_MYFONT
|
||||
#endif
|
||||
|
||||
Then define the actual font ID. Make sure that the font ID value
|
||||
is unique::
|
||||
|
||||
enum nx_fontid_e
|
||||
{
|
||||
FONTID_DEFAULT = 0 /* The default font */
|
||||
#ifdef CONFIG_NXFONT_SANS23X27
|
||||
, FONTID_SANS23X27 = 1 /* The 23x27 sans serif font */
|
||||
#endif
|
||||
#ifdef CONFIG_NXFONT_MYFONT
|
||||
, FONTID_MYFONT = 2 /* My shiny, new font */
|
||||
#endif
|
||||
...
|
||||
|
||||
Now add the font to the NX build system. There are several files that
|
||||
you have to modify to do this. Look how the build system uses the
|
||||
font CONFIG_NXFONT_SANS23X27 for examples:
|
||||
|
||||
5. nuttx/graphics/Makefile. This file needs logic to auto-generate
|
||||
a C source file from the header file that you generated with the
|
||||
the bdf-converter program. Notice NXFONTS_FONTID=2; this must be
|
||||
set to the same font ID value that you defined in the
|
||||
include/nuttx/nx/nxfonts.h file::
|
||||
|
||||
genfontsources:
|
||||
ifeq ($(CONFIG_NXFONT_SANS23X27),y)
|
||||
@$(MAKE) -C nxfonts -f Makefile.sources NXFONTS_FONTID=1 EXTRAFLAGS=$(EXTRAFLAGS)
|
||||
endif
|
||||
ifeq ($(CONFIG_NXFONT_MYFONT),y)
|
||||
@$(MAKE) -C nxfonts -f Makefile.sources NXFONTS_FONTID=2 EXTRAFLAGS=$(EXTRAFLAGS)
|
||||
endif
|
||||
|
||||
6. nuttx/libnx/nxfonts/Make.defs. Set the make variable NXFSET_CSRCS.
|
||||
NXFSET_CSRCS determines the name of the font C file to build when
|
||||
NXFONTS_FONTID=2::
|
||||
|
||||
ifeq ($(CONFIG_NXFONT_SANS23X27),y)
|
||||
NXFSET_CSRCS += nxfonts_bitmaps_sans23x27.c
|
||||
endif
|
||||
ifeq ($(CONFIG_NXFONT_MYFONT),y)
|
||||
NXFSET_CSRCS += nxfonts_bitmaps_myfont.c
|
||||
endif
|
||||
|
||||
7. nuttx/libnx/nxfonts/Makefile.sources. This is the Makefile used
|
||||
in step 5 that will actually generate the font C file. So, given
|
||||
your NXFONTS_FONTID=2, it needs to determine a prefix to use for
|
||||
auto-generated variable and function names and (again) the name of
|
||||
the auto-generated file to create (this must be the same name that
|
||||
was used in nuttx/libnx/nxfonts/Make.defs)::
|
||||
|
||||
ifeq ($(NXFONTS_FONTID),1)
|
||||
NXFONTS_PREFIX := g_sans23x27_
|
||||
GEN_CSRC = nxfonts_bitmaps_sans23x27.c
|
||||
endif
|
||||
ifeq ($(NXFONTS_FONTID),2)
|
||||
NXFONTS_PREFIX := g_myfont_
|
||||
GEN_CSRC = nxfonts_bitmaps_myfont.c
|
||||
endif
|
||||
|
||||
8. graphics/libnx/nxfonts_bitmaps.c. This is the file that contains
|
||||
the generic font structures. It is used as a "template" file by
|
||||
nuttx/libnx/nxfonts/Makefile.sources to create your customized
|
||||
font data set::
|
||||
|
||||
#if NXFONTS_FONTID == 1
|
||||
# include "nxfonts_sans23x27.h"
|
||||
#elif NXFONTS_FONTID == 2
|
||||
# include "nxfonts_myfont.h"
|
||||
#else
|
||||
# error "No font ID specified"
|
||||
#endif
|
||||
|
||||
Where nxfonts_myfont.h is the NuttX font file that we generated in
|
||||
step 2 using the bdf-converter tool.
|
||||
|
||||
9. libnx/nxfonts/nxfonts_getfont.c. Finally, we need to extend the
|
||||
logic that does the run-time font lookups so that can find our new
|
||||
font. The lookup function is NXHANDLE nxf_getfonthandle(enum nx_fontid_e fontid).
|
||||
The new font information needs to be added to data structures used by
|
||||
that function::
|
||||
|
||||
#ifdef CONFIG_NXFONT_SANS23X27
|
||||
extern const struct nx_fontpackage_s g_sans23x27_package;
|
||||
#endif
|
||||
#ifdef CONFIG_NXFONT_MYFONT
|
||||
extern const struct nx_fontpackage_s g_myfont_package;
|
||||
#endif
|
||||
|
||||
static FAR const struct nx_fontpackage_s *g_fontpackages[] =
|
||||
{
|
||||
#ifdef CONFIG_NXFONT_SANS23X27
|
||||
&g_sans23x27_package,
|
||||
#endif
|
||||
#ifdef CONFIG_NXFONT_MYFONT
|
||||
&g_myfont_package,
|
||||
#endif
|
||||
NULL
|
||||
};
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
===================
|
||||
``checkkconfig.py``
|
||||
===================
|
||||
|
||||
``checkkconfig.py`` is a Python script that simulates the effects of modifying a CONFIG item.
|
||||
It can be used to check whether my config changes are what I expected.
|
||||
|
||||
Help message::
|
||||
|
||||
$ tools/checkkconfig.py -h
|
||||
usage: checkkconfig.py [-h] -f FILE (-s CONFIG VALUE | -d DIFF)
|
||||
|
||||
optional arguments:
|
||||
-h, --help show this help message and exit
|
||||
-f FILE, --file FILE Path to the input defconfig file
|
||||
-s CONFIG_XXX VALUE, --single CONFIG VALUE
|
||||
Analyze single change: CONFIG_NAME y/m/n
|
||||
-d DIFF, --diff DIFF Analyze changes from diff file
|
||||
|
||||
example: ./tools/checkkconfig.py -f defconfig -s ELF n
|
||||
|
||||
outputs:
|
||||
Change report for ELF=n
|
||||
Config Option Old New
|
||||
----------------------------------------------------------------------
|
||||
BINFMT_LOADABLE y n
|
||||
ELF y n
|
||||
ELF_STACKSIZE 8192 <unset>
|
||||
LIBC_ARCH_ELF y n
|
||||
LIBC_MODLIB y n
|
||||
MODLIB_ALIGN_LOG2 2 <unset>
|
||||
MODLIB_BUFFERINCR 32 <unset>
|
||||
MODLIB_BUFFERSIZE 32 <unset>
|
||||
MODLIB_MAXDEPEND 2 <unset>
|
||||
MODLIB_RELOCATION_BUFFERCOUNT 256 <unset>
|
||||
MODLIB_SYMBOL_CACHECOUNT 256 <unset>
|
||||
|
||||
As we can see, we can clearly know that
|
||||
if I turn off ELF in defconfig at this time,
|
||||
it will bring about the following configuration linkage changes
|
||||
|
||||
It can also parse diff files, which can be used to check the changes of multiple
|
||||
configs.
|
||||
@@ -0,0 +1,29 @@
|
||||
=================
|
||||
``checkpatch.sh``
|
||||
=================
|
||||
|
||||
``checkpatch.sh`` is a bash script that makes use of ``nxstyle`` and
|
||||
``codespell`` tools to format patches and ensure that files conform to NuttX
|
||||
coding standard. It is used in NuttX's GitHub CI.
|
||||
|
||||
Help message:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/checkpatch.sh -h
|
||||
USAGE: tools/checkpatch.sh [options] [list|-]
|
||||
|
||||
Options:
|
||||
-h
|
||||
-c spell check with codespell (install with: pip install codespell)
|
||||
-u encoding check with cvt2utf (install with: pip install cvt2utf)
|
||||
-r range check only (coupled with -p or -g)
|
||||
-p <patch file names> (default)
|
||||
-m Check commit message (coupled with -g)
|
||||
-g <commit list>
|
||||
-f <file list>
|
||||
-x format supported files (only .py, requires: pip install black)
|
||||
- read standard input mainly used by git pre-commit hook as below:
|
||||
git diff --cached | ./tools/checkpatch.sh -
|
||||
Where a <commit list> is any syntax supported by git for specifying git revision, see GITREVISIONS(7)
|
||||
Where a <patch file names> is a space separated list of patch file names or wildcard. or *.patch
|
||||
@@ -0,0 +1,6 @@
|
||||
===============
|
||||
``cmpconfig.c``
|
||||
===============
|
||||
|
||||
This C file can be used to build a utility for comparing two NuttX configuration
|
||||
files.
|
||||
@@ -0,0 +1,29 @@
|
||||
======================================================================================
|
||||
``configure.sh``, ``configure.bat``, ``configure.c``, ``cfgparser.c``, ``cfgparser.h``
|
||||
======================================================================================
|
||||
|
||||
``configure.sh`` is a bash script that is used to configure NuttX for a given
|
||||
target board in a environment that supports POSIX paths (Linux, Cygwin, macOS,
|
||||
or similar). See :doc:`/components/boards` or
|
||||
Documentation/NuttXPortingGuide.html for a description of how to configure NuttX
|
||||
with this script.
|
||||
|
||||
configure.c, cfgparser.c, and cfgparser.h can be used to build a work-alike
|
||||
program as a replacement for configure.sh. This work-alike program would be
|
||||
used in environments that do not support Bash scripting (such as the Windows
|
||||
native environment).
|
||||
|
||||
configure.bat is a small Windows batch file that can be used as a replacement
|
||||
for configure.sh in a Windows native environment. configure.bat is actually
|
||||
just a thin layer that executes configure.exe if it is available. If
|
||||
configure.exe is not available, then configure.bat will attempt to build it
|
||||
first.
|
||||
|
||||
In order to build configure.exe from configure.c in the Windows native
|
||||
environment, two assumptions are made:
|
||||
|
||||
1) You have installed the MinGW GCC toolchain. This toolchain can be
|
||||
downloaded from http://www.mingw.org/. It is recommended that you not
|
||||
install the optional MSYS components as there may be conflicts.
|
||||
2) That path to the bin/ directory containing mingw-gcc.exe must be
|
||||
included in the PATH variable.
|
||||
@@ -0,0 +1,9 @@
|
||||
======================
|
||||
``convert-comments.c``
|
||||
======================
|
||||
|
||||
Convert C++-style comments to C89 C-style comments. Usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ convert-comments <source-file> <out-file>
|
||||
@@ -0,0 +1,11 @@
|
||||
=============================
|
||||
``define.sh``, ``define.bat``
|
||||
=============================
|
||||
|
||||
Different compilers have different conventions for specifying pre-
|
||||
processor definitions on the compiler command line. This bash
|
||||
script allows the build system to create command line definitions
|
||||
without concern for the particular compiler in use.
|
||||
|
||||
The define.bat script is a counterpart for use in the native Windows
|
||||
build.
|
||||
@@ -0,0 +1,11 @@
|
||||
===========
|
||||
``detab.c``
|
||||
===========
|
||||
|
||||
Convert tabs to spaces in a file. Usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ detab [-4] <source-file> <out-file>
|
||||
|
||||
Default ``<source-file>`` tab size is 8 spaces; ``-4`` selects 4 space tab size.
|
||||
@@ -0,0 +1,6 @@
|
||||
===============
|
||||
``discover.py``
|
||||
===============
|
||||
|
||||
Example script for discovering devices in the local network. It is the counter
|
||||
part to :doc:`/applications/netutils/discover/index`.
|
||||
@@ -0,0 +1,13 @@
|
||||
===================
|
||||
``flash_writer.py``
|
||||
===================
|
||||
|
||||
This flash writer is using the xmodem for firmware transfer on
|
||||
boards based on cxd56 chip (Ex. Spresense). This tool depends on
|
||||
the xmodem package (https://pypi.org/project/xmodem/).
|
||||
|
||||
For flashing the ``.spk`` image to the board please use:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/flash_writer.py -s -c /dev/ttyUSB0 -d -b 115200 -n nuttx.spk
|
||||
@@ -0,0 +1,18 @@
|
||||
===============
|
||||
``gencromfs.c``
|
||||
===============
|
||||
|
||||
This is a C program that is used to generate CROMFS file system images.
|
||||
Usage is simple:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ gencromfs <dir-path> <out-file>
|
||||
|
||||
Where:
|
||||
|
||||
* ``<dir-path>`` is the path to the directory will be at the root of the new
|
||||
CROMFS file system image.
|
||||
|
||||
* ``<out-file>`` the name of the generated, output C file. This file must be
|
||||
compiled in order to generate the binary CROMFS file system image.
|
||||
@@ -0,0 +1,114 @@
|
||||
===================
|
||||
``ide_exporter.py``
|
||||
===================
|
||||
|
||||
This Python script will help to create NuttX project in the IAR and
|
||||
uVision IDEs. These are few simple the steps to export the IDE
|
||||
workspaces.
|
||||
|
||||
1) Start the NuttX build from the Cygwin command line before trying to
|
||||
create your project by running::
|
||||
|
||||
make V=1 |& tee build_log
|
||||
|
||||
This is necessary to certain auto-generated files and directories that
|
||||
will be needed. This will provide the build log to construct the IDE
|
||||
project also.
|
||||
|
||||
2) Export the IDE project base on that make log. The script usage:
|
||||
|
||||
usage: ide_exporter.py [-h] [-v] [-o OUT_DIR] [-d] build_log {iar,uvision_armcc,uvision_gcc} template_dir
|
||||
|
||||
positional arguments::
|
||||
|
||||
build_log Log file from make V=1
|
||||
{iar,uvision_armcc,uvision_gcc}
|
||||
The target IDE: iar, uvision_gcc, (uvision_armcc is experimental)
|
||||
template_dir Directory that contains IDEs template projects
|
||||
|
||||
optional arguments::
|
||||
|
||||
-h, --help show this help message and exit
|
||||
-v, --version show program's version number and exit
|
||||
-o OUT_DIR, --output OUT_DIR
|
||||
Output directory
|
||||
-d, --dump Dump project structure tree
|
||||
|
||||
Example::
|
||||
|
||||
cd nuttx
|
||||
make V=1 |& tee build_log
|
||||
|
||||
./tools/ide_exporter.py makelog_f2nsh_c iar ./boards/<arch>/<chip>/<board>/ide/template/iar -o ./boards/<arch>/<chip>/<board>/ide/nsh/iar
|
||||
|
||||
or::
|
||||
|
||||
./tools/ide_exporter.py makelog_f2nsh_c uvision_gcc ./boards/<arch>/<chip>/<board>/ide/template/uvision_gcc/ -o ./boards/<arch>/<chip>/<board>/ide/nsh/uvision
|
||||
|
||||
3) Limitations:
|
||||
|
||||
- IAR supports C only. Iar C++ does not compatible with g++ so disable
|
||||
C++ if you want to use IAR.
|
||||
- uvision_armcc : nuttx asm (inline and .asm) can't be compiled with
|
||||
armcc so do not use this option.
|
||||
- uvision_gcc : uvision project that uses gcc. Need to specify path to
|
||||
gnu toolchain.
|
||||
In uVison menu, select::
|
||||
|
||||
Project/Manage/Project Items.../FolderExtension/Use GCC compiler/ PreFix, Folder
|
||||
|
||||
4) Template projects' constrains:
|
||||
|
||||
- mcu, core, link script shall be configured in template project
|
||||
- Templates' name are fixed:
|
||||
|
||||
- template_nuttx.eww : IAR nuttx workspace template
|
||||
- template_nuttx_lib.ewp : IAR nuttx library project template
|
||||
- template_nuttx_main.ewp : IAR nuttx main project template
|
||||
- template_nuttx.uvmpw : uVision workspace
|
||||
- template_nuttx_lib.uvproj : uVision library project
|
||||
- template_nuttx_main.uvproj : uVision main project
|
||||
- iar:
|
||||
|
||||
- Library option shall be set to 'None' so that IAR could use nuttx
|
||||
libc
|
||||
- __ASSEMBLY__ symbol shall be defined in assembler
|
||||
|
||||
- uVision_gcc:
|
||||
|
||||
- There should be one fake .S file in projects that has been defined
|
||||
__ASSEMBLY__ in assembler.
|
||||
- In Option/CC tab : disable warning
|
||||
- In Option/CC tab : select Compile thump code (or Misc control =
|
||||
-mthumb)
|
||||
- template_nuttx_lib.uvproj shall add 'Post build action' to copy .a
|
||||
file to .\lib
|
||||
- template_nuttx_main.uvproj Linker:
|
||||
|
||||
- Select 'Do not use Standard System Startup Files' and 'Do not
|
||||
use Standard System Libraries'
|
||||
- Do not select 'Use Math libraries'
|
||||
- Misc control = --entry=__start
|
||||
|
||||
5) How to create template for other configurations:
|
||||
|
||||
1) uVision with gcc toolchain:
|
||||
|
||||
- Copy 3 uVision project files
|
||||
- Select the MCU for main and lib project
|
||||
- Correct the path to ld script if needed
|
||||
|
||||
2) iar:
|
||||
|
||||
- Check if the arch supports IAR (only armv7-m is support IAR
|
||||
now)
|
||||
- Select the MCU for main and lib project
|
||||
- Add new ld script file for IAR
|
||||
|
||||
.. note::
|
||||
|
||||
Due to bit rot, the template files for the stm3220g-eval and for the
|
||||
stm32f429-disco have been removed from the NuttX repository. For reference,
|
||||
they can be found in the Obsoleted repository at
|
||||
Obsoleted/stm32f429i_disco/ltcd/template and at
|
||||
Obsoleted/stm3220g-eval/template.
|
||||
@@ -0,0 +1,14 @@
|
||||
===========================================
|
||||
``incdir.sh``, ``incdir.bat``, ``incdir.c``
|
||||
===========================================
|
||||
|
||||
Different compilers have different conventions for specifying lists
|
||||
of include file paths on the compiler command line. This incdir.sh
|
||||
bash script allows the build system to create include file paths without
|
||||
concern for the particular compiler in use.
|
||||
|
||||
The incdir.bat script is a counterpart for use in the native Windows
|
||||
build. However, there is currently only one compiler supported in
|
||||
that context: MinGW-GCC.
|
||||
|
||||
incdir.c is a higher performance version of incdir.sh, converted to C.
|
||||
@@ -0,0 +1,68 @@
|
||||
=============
|
||||
``indent.sh``
|
||||
=============
|
||||
|
||||
This script can be used to indent .c and .h files in a manner similar
|
||||
to the NuttX coding style. It doesn't do a really good job, however
|
||||
(see below and the comments at the top of the indent.sh file).
|
||||
|
||||
USAGE::
|
||||
|
||||
tools/indent.sh [-d] [-p] -o <out-file> <in-file>
|
||||
tools/indent.sh [-d] [-p] <in-file-list>
|
||||
tools/indent.sh [-d] -h
|
||||
|
||||
Where::
|
||||
|
||||
-<in-file>
|
||||
A single, unformatted input file
|
||||
-<in-file-list>
|
||||
A list of unformatted input files that will be reformatted in place.
|
||||
-o <out-file>
|
||||
Write the single, reformatted <in-file> to <out-file>. <in-file>
|
||||
will not be modified.
|
||||
-d
|
||||
Enable script debug
|
||||
-p
|
||||
Comments are pre-formatted. Do not reformat.
|
||||
-h
|
||||
Show this help message and exit
|
||||
|
||||
The conversions make by the indent.sh script differs from the NuttX coding
|
||||
style in that:
|
||||
|
||||
1. The coding standard requires that the trailing ``*/`` of a multi-line
|
||||
comment be on a separate line. By default, indent.sh will put the
|
||||
final ``*/`` on the same line as the last comment text. If your C file
|
||||
already has properly formatted comments then using the ``-p`` option will
|
||||
eliminate that bad behavior
|
||||
|
||||
2. If your source file has highly formatted comments containing things
|
||||
such as tables or lists, then use the -p option to preserve those
|
||||
pre-formatted comments.
|
||||
|
||||
3. I usually align things vertically (like '=' in assignments),
|
||||
|
||||
4. indent.sh puts a bogus blank line at the top of the file,
|
||||
|
||||
5. I don't like the way it handles nested conditional compilation
|
||||
intermixed with code. I prefer the preprocessor conditional tests
|
||||
be all right justified in that case.
|
||||
|
||||
6. I also indent brackets differently on structures than does this script.
|
||||
|
||||
7. I normally use no spaces in casts. indent.sh adds spaces in casts like
|
||||
``(FAR void *)&foo`` becomes ``(FAR void *) & foo``.
|
||||
|
||||
8. When used with header files, the initial idempotence conditional test
|
||||
causes all preprocessor directives to be indented in the file. So for
|
||||
header files, you will need to substitute "^# " with "#" in the
|
||||
converted header file.
|
||||
|
||||
You will manually need to check for the issues listed above after
|
||||
performing the conversions. nxstyle.c provides a good test that will
|
||||
catch most of the indent.sh screw-ups. Together, they do a pretty good
|
||||
job of formatting.
|
||||
|
||||
See also nxstyle.c and uncrustify.cfg
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,9 @@
|
||||
===================
|
||||
``initialconfig.c``
|
||||
===================
|
||||
|
||||
This is a C file that can be used to create an initial configuration. This
|
||||
permits creating a new configuration from scratch, without relying on any
|
||||
existing board configuration in place. This utility will create a barebones
|
||||
``.config`` file sufficient only for instantiating the symbolic links necessary
|
||||
to do a real configuration.
|
||||
@@ -0,0 +1,30 @@
|
||||
===============
|
||||
``kconfig.bat``
|
||||
===============
|
||||
|
||||
Recent versions of NuttX support building NuttX from a native Windows
|
||||
CMD.exe shell. But kconfig-frontends is a Linux tool and is not yet
|
||||
available in the pure CMD.exe environment. At this point, there are
|
||||
only a few options for the Windows user (see the top-level README.txt
|
||||
file).
|
||||
|
||||
You can, with some effort, run the Cygwin kconfig-mconf tool directly
|
||||
in the CMD.exe shell. In this case, you do not have to modify the
|
||||
.config file, but there are other complexities: You need to
|
||||
temporarily set the Cygwin directories in the PATH variable and
|
||||
then run kconfig-mconf outside of the Make system.
|
||||
|
||||
kconfig.bat is a Windows batch file at tools/kconfig.bat that automates
|
||||
these steps. It is used from the top-level NuttX directory like::
|
||||
|
||||
tools/kconfig menuconfig
|
||||
|
||||
NOTE: There is currently an issue with accessing DOS environment
|
||||
variables from the Cygwin kconfig-mconf running in the CMD.exe shell.
|
||||
The following change to the top-level Kconfig file seems to work around
|
||||
these problems::
|
||||
|
||||
config APPSDIR
|
||||
string
|
||||
- option env="APPSDIR"
|
||||
+ default "../apps"
|
||||
@@ -0,0 +1,37 @@
|
||||
==================
|
||||
``kconfig2html.c``
|
||||
==================
|
||||
|
||||
This is a C file that can be used to build a utility for converting the
|
||||
NuttX configuration in the Kconfig files to an HTML document. This
|
||||
auto-generated documentation will, eventually, replace the manually
|
||||
updated configuration documentation that is falling woefully behind:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/kconfig2html.exe -h
|
||||
USAGE: tools/kconfig2html [-d] [-a <apps directory>] {-o <out file>] [<Kconfig root>]
|
||||
tools/kconfig2html [-h]
|
||||
|
||||
Where::
|
||||
|
||||
-a : Select relative path to the apps/ directory. This path is relative
|
||||
to the <Kconfig directory>. Default: ../apps
|
||||
-o : Send output to <out file>. Default: Output goes to stdout
|
||||
-d : Enable debug output
|
||||
-h : Prints this message and exits
|
||||
<Kconfig root> is the directory containing the root Kconfig file.
|
||||
Default <Kconfig directory>: .
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
In order to use this tool, some configuration must be in-place with
|
||||
all necessary symbolic links. You can establish the configured symbolic
|
||||
links with::
|
||||
|
||||
make context
|
||||
|
||||
or more quickly with::
|
||||
|
||||
make .dirlinks
|
||||
@@ -0,0 +1,8 @@
|
||||
=========================================================================
|
||||
``Libraries.mk``, ``FlatLibs.mk``, ``ProtectedLibs.mk``, ``KernelLib.mk``
|
||||
=========================================================================
|
||||
|
||||
Libraries.mk has the build rules for all NuttX libraries.
|
||||
|
||||
FlatLibs.mk, ProtectedLibs.mk, and KernelLib.mk: These control the
|
||||
selection of libraries to be built, depending on the selected build mode.
|
||||
@@ -0,0 +1,42 @@
|
||||
.. _build_system_linking:
|
||||
|
||||
============================================================
|
||||
``link.[sh|bat]``, ``copydir.[sh|bat]``, ``unlink.[sh|bat]``
|
||||
============================================================
|
||||
|
||||
Different file systems have different capabilities for symbolic links.
|
||||
Some Windows file systems have no native support for symbolic links.
|
||||
Cygwin running under Windows has special links built in that work with
|
||||
all cygwin tools. However, they do not work when Windows native tools
|
||||
are used with cygwin. In that case something different must be done.
|
||||
|
||||
If you are building under Linux or under cygwin with a cygwin tool
|
||||
chain, then your Make.defs file may have definitions like the
|
||||
following::
|
||||
|
||||
DIRLINK = $(TOPDIR)/tools/link.sh
|
||||
DIRUNLINK = (TOPDIR)/tools/unlink.sh
|
||||
|
||||
The first definition is not always present because link.sh is the
|
||||
default. link.sh is a bash script that performs a normal, Linux-style
|
||||
symbolic link; unlink.sh is a do-it-all unlinking script.
|
||||
|
||||
But if you are building under cygwin using a Windows native toolchain
|
||||
within a POSIX framework (such as Cygwin), then you will need something
|
||||
like the following in you Make.defs file::
|
||||
|
||||
DIRLINK = $(TOPDIR)/tools/copydir.sh
|
||||
DIRUNLINK = (TOPDIR)/tools/unlink.sh
|
||||
|
||||
copydir.sh will copy the whole directory instead of linking it.
|
||||
|
||||
Finally, if you are running in a pure native Windows environment with
|
||||
a CMD.exe shell, then you will need something like this::
|
||||
|
||||
DIRLINK = $(TOPDIR)/tools/copydir.bat
|
||||
DIRUNLINK = (TOPDIR)/tools/unlink.bat
|
||||
|
||||
Note that this will copy directories. link.bat might also be used in
|
||||
this case. link.bat will attempt to create a symbolic link using the
|
||||
NTFS mklink.exe command instead of copying files. That logic, however,
|
||||
has not been verified as of this writing.
|
||||
@@ -0,0 +1,11 @@
|
||||
============
|
||||
``lowhex.c``
|
||||
============
|
||||
|
||||
Convert hexadecimal representation in a file from upper-case to lower-case.
|
||||
|
||||
Usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ lowhex <source-file> <out-file>
|
||||
@@ -0,0 +1,17 @@
|
||||
.. _makefile_host:
|
||||
|
||||
=================
|
||||
``Makefile.host``
|
||||
=================
|
||||
|
||||
This is the makefile that is used to make the mkconfig program from
|
||||
the mkconfig.c C file, the cmpconfig program from cmpconfig.c C file,
|
||||
the mkversion program from the mkconfig.c C file, or the mksyscall
|
||||
program from the mksyscall.c file.
|
||||
|
||||
Usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ cd tools/
|
||||
$ make -f Makefile.host <program>
|
||||
@@ -0,0 +1,10 @@
|
||||
=======================
|
||||
``Makefile.[unix|win]``
|
||||
=======================
|
||||
|
||||
Unix.mk is the Makefile used when building NuttX in Unix-like systems.
|
||||
It is selected from the top-level Makefile.
|
||||
|
||||
Win.mk is the Makefile used when building natively under Windows.
|
||||
It is selected from the top-level Makefile.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
================================================
|
||||
``mkconfig.c``, ``cfgdefine.c``, ``cfgdefine.h``
|
||||
================================================
|
||||
|
||||
These are C files that are used to build mkconfig program. The mkconfig
|
||||
program is used during the initial NuttX build.
|
||||
|
||||
When you configure NuttX, you will copy a configuration file called .config
|
||||
in the top level NuttX directory (See :doc:`/components/boards` or
|
||||
Documentation/NuttXPortingGuide.html). The first time you make NuttX,
|
||||
the top-level makefile will build the mkconfig executable from mkconfig.c
|
||||
(using Makefile.host). The top-level Makefile will then execute the mkconfig
|
||||
program to convert the .config file in the top level directory into
|
||||
include/nuttx/config.h. config.h is a another version of the NuttX
|
||||
configuration that can be included by C files.
|
||||
@@ -0,0 +1,27 @@
|
||||
===================
|
||||
``mkconfigvars.sh``
|
||||
===================
|
||||
|
||||
The HTML documentation expects to have a copy of the auto-generated
|
||||
configuration variable documentation Documentation/NuttXConfigVariables.html.
|
||||
The script mkconfigvars.sh is a simple script that can be used to
|
||||
re-generated that file as needed.
|
||||
|
||||
Help:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/mkconfigvars.sh -h
|
||||
tools/mkconfigvars.sh is a tool for generation of configuration variable documentation
|
||||
|
||||
USAGE: tools/mkconfigvars.sh [-d|h] [-v <major.minor.patch>]
|
||||
|
||||
Where::
|
||||
|
||||
-v <major.minor.patch>
|
||||
The NuttX version number expressed as a major, minor and patch number separated
|
||||
by a period
|
||||
-d
|
||||
Enable script debug
|
||||
-h
|
||||
show this help message and exit
|
||||
@@ -0,0 +1,6 @@
|
||||
==============
|
||||
``mkctags.sh``
|
||||
==============
|
||||
|
||||
A script for creating ctags from Ken Pettit. See http://en.wikipedia.org/wiki/Ctags
|
||||
and http://ctags.sourceforge.net/
|
||||
@@ -0,0 +1,35 @@
|
||||
.. _mkdeps:
|
||||
|
||||
===================================================================
|
||||
``mkdeps.c``, ``cnvwindeps.c``, ``mkwindeps.sh``, ``mknulldeps.sh``
|
||||
===================================================================
|
||||
|
||||
NuttX uses the GCC compiler's capabilities to create Makefile dependencies.
|
||||
The program mkdeps is used to run GCC in order to create the dependencies.
|
||||
If a NuttX configuration uses the GCC toolchain, its Make.defs file (see
|
||||
:doc:`/components/boards`) will include a line like::
|
||||
|
||||
MKDEP = $(TOPDIR)/tools/mkdeps[.exe] (See NOTE below)
|
||||
|
||||
If the NuttX configuration does not use a GCC compatible toolchain, then
|
||||
it cannot use the dependencies and instead it uses mknulldeps.sh::
|
||||
|
||||
MKDEP = $(TOPDIR)/tools/mknulldeps.sh
|
||||
|
||||
The mknulldeps.sh is a stub script that does essentially nothing.
|
||||
|
||||
mkwindeps.sh is a version that creates dependencies using the Windows
|
||||
native toolchain. That generates Windows native paths in the dependency
|
||||
file. But the mkwindeps.sh uses cnvwindeps.c to convert the Windows
|
||||
paths to POSIX paths. This adds some time to the Windows dependency
|
||||
generation but is generally the best option available for that mixed
|
||||
environment of Cygwin with a native Windows GCC toolchain.
|
||||
|
||||
mkdeps.c generates mkdeps (on Linux) or mkdeps.exe (on Windows).
|
||||
However, this version is still under-development. It works well in
|
||||
the all POSIX environment or in the all Windows environment but also
|
||||
does not work well in mixed POSIX environment with a Windows toolchain.
|
||||
In that case, there are still issues with the conversion of things like
|
||||
'c:\Program Files' to 'c:program files' by bash. Those issues may,
|
||||
eventually be solvable but for now continue to use mkwindeps.sh in
|
||||
that mixed environment.
|
||||
@@ -0,0 +1,15 @@
|
||||
==============================
|
||||
``mkexport.sh``, ``Export.mk``
|
||||
==============================
|
||||
|
||||
These implement part of the top-level Makefile's 'export' target. That
|
||||
target will bundle up all of the NuttX libraries, header files, and the
|
||||
startup object into an export-able, binary NuttX distribution. The
|
||||
Export.mk is used only by the mkexport.sh script to parse out options
|
||||
from the top-level Make.defs file.
|
||||
|
||||
USAGE: tools/mkexport.sh [-d] [-z] [-u] -t <top-dir> [-x <lib-ext>] -l "lib1 [lib2 [lib3 ...]]"
|
||||
|
||||
This script also depends on the environment variable MAKE which is set
|
||||
in the top-level Makefile before starting mkexport.sh. If MAKE is not
|
||||
defined, the script will set it to `which make`.
|
||||
@@ -0,0 +1,13 @@
|
||||
===============
|
||||
``mkfsdata.pl``
|
||||
===============
|
||||
|
||||
This perl script is used to build the "fake" file system and CGI support
|
||||
as needed for the apps/netutils/webserver. It is currently used only
|
||||
by the Makefile at apps/examples/uip. That example serves as an example
|
||||
of how to configure the uIP webserver "fake" file system.
|
||||
|
||||
.. note::
|
||||
|
||||
This perl script comes from uIP and was (probably) written by Adam Dunkels.
|
||||
uIP has a license that is compatible with NuttX.
|
||||
@@ -0,0 +1,12 @@
|
||||
=================
|
||||
``mkromfsimg.sh``
|
||||
=================
|
||||
|
||||
This script may be used to automate the generation of a ROMFS file system
|
||||
image. It accepts an rcS script "template" and generates an image that
|
||||
may be mounted under /etc in the NuttX pseudo file system.
|
||||
|
||||
.. tip::
|
||||
|
||||
Edit the resulting header file and mark the generated data values as
|
||||
``const`` so that they will be stored in FLASH.
|
||||
@@ -0,0 +1,31 @@
|
||||
================================================
|
||||
``mksymtab.c``, ``cvsparser.c``, ``cvsparser.h``
|
||||
================================================
|
||||
|
||||
This is a C file that is used to build symbol tables from comma separated
|
||||
value (CSV) files. This tool is not used during the NuttX build, but
|
||||
can be used as needed to generate files.
|
||||
|
||||
Usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./mksymtab [-d] <cvs-file> <symtab-file> [<symtab-name> [<nsymbols-name>]]
|
||||
|
||||
Where::
|
||||
|
||||
<cvs-file> : The path to the input CSV file (required)
|
||||
<symtab-file> : The path to the output symbol table file (required)
|
||||
<symtab-name> : Optional name for the symbol table variable
|
||||
Default: "g_symtab"
|
||||
<nsymbols-name> : Optional name for the symbol table variable
|
||||
Default: "g_nsymbols"
|
||||
-d : Enable debug output
|
||||
|
||||
Example:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ cd nuttx/tools
|
||||
$ cat ../syscall/syscall.csv ../lib/libc.csv | sort >tmp.csv
|
||||
$ ./mksymtab.exe tmp.csv tmp.c
|
||||
@@ -0,0 +1,24 @@
|
||||
=================================================
|
||||
``mksyscall.c``, ``cvsparser.c``, ``cvsparser.h``
|
||||
=================================================
|
||||
|
||||
This is a C file that is used to build mksyscall program. The mksyscall
|
||||
program is used during the initial NuttX build by the logic in the top-
|
||||
level syscall/ directory.
|
||||
|
||||
If you build NuttX as a separately compiled, monolithic kernel and separate
|
||||
applications, then there is a syscall layer that is used to get from the
|
||||
user application space to the NuttX kernel space. In the user application
|
||||
"proxies" for each of the kernel functions are provided. The proxies have
|
||||
the same function signature as the kernel function, but only execute a
|
||||
system call.
|
||||
|
||||
Within the kernel, there are "stubs" for each of the system calls. The
|
||||
stubs receive the marshalled system call data, and perform the actually
|
||||
kernel function call (in kernel-mode) on behalf of the proxy function.
|
||||
|
||||
Information about the stubs and proxies is maintained in a comma separated
|
||||
value (CSV) file in the syscall/ directory. The mksyscall program will
|
||||
accept this CVS file as input and generate all of the required proxy or
|
||||
stub files as output. See :doc:`/components/syscall` for additional information.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
=================================================
|
||||
``mkversion.c``, ``cfgdefine.c``, ``cfgdefine.h``
|
||||
=================================================
|
||||
|
||||
This is C file that is used to build mkversion program. The mkversion
|
||||
program is used during the initial NuttX build.
|
||||
|
||||
When you build NuttX there should be a version file called .version in
|
||||
the top level NuttX directory (See Documentation/NuttXPortingGuide.html).
|
||||
The first time you make NuttX, the top-level makefile will build the
|
||||
mkversion executable from mkversion.c (using Makefile.host). The top-level
|
||||
Makefile will then execute the mkversion program to convert the
|
||||
.version file in the top level directory into include/nuttx/version.h.
|
||||
version.h provides version information that can be included by C files.
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
=============
|
||||
``netusb.sh``
|
||||
=============
|
||||
|
||||
Helper script used to set up the CDC ECM Ethernet Over USB driver,
|
||||
host routes, and IP Tables rules to support networking with a NuttX
|
||||
system that has a CDC ECM Ethernet Over USB driver configured. Only
|
||||
supported on Linux.
|
||||
|
||||
General usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/netusb.sh
|
||||
Usage: tools/netusb.sh <main-interface> <usb-net-interface> <on|off>
|
||||
|
||||
This has been tested on the SAMA5D3-Xplained board; see
|
||||
`Documentation/platforms/arm/sama5/boards/sama5d3-xplained/README.txt`
|
||||
for more information on how to configure the CDC ECM driver for that board.
|
||||
@@ -0,0 +1,35 @@
|
||||
=============
|
||||
``nxstyle.c``
|
||||
=============
|
||||
|
||||
I am embarrassed that this is here. This program is a complete hack but,
|
||||
unfortunately, it has become so useful to me that I need to keep it here.
|
||||
|
||||
A little background: I have tinkered with pretty printers for some
|
||||
time and have not been happy with the results. An alternative that
|
||||
occurred to me would be just a standard checker that examines a C
|
||||
file that gives warnings for violations of the coding standard.
|
||||
|
||||
This turns out to be more difficult that you might think. A pretty
|
||||
printer understands C syntax: They break the file up into its C
|
||||
components then reassembles the output in the format. But parsing the
|
||||
C loses the original file layout and so it not useful in this case.
|
||||
|
||||
This program instead, uses a collection of heuristics (i.e., hacks and
|
||||
bandaids) to examine the C file for obvious violations of the coding
|
||||
standard. This program is completely ignorant of C syntax; it simply
|
||||
performs crude pattern matching to check the file.
|
||||
|
||||
Prints formatted messages that are classified as info, warn, error,
|
||||
fatal. In a parsable format that can be used by editors and IDEs.
|
||||
|
||||
Usage::
|
||||
|
||||
nxstyle [-m <excess>] [-v <level>] [-r <start,count>] <filename>
|
||||
nxstyle -h this help
|
||||
nxstyle -v <level> where level is
|
||||
0 - no output
|
||||
1 - PASS/FAIL
|
||||
2 - output each line (default)
|
||||
|
||||
See also indent.sh and uncrustify.cfg
|
||||
@@ -0,0 +1,22 @@
|
||||
======================
|
||||
``nxtagspkgsfetch.sh``
|
||||
======================
|
||||
|
||||
This script downloads all NuttX RTOS and Application snapshot packages
|
||||
from the upstream git repository based on the provided git tags list.
|
||||
These are NOT official release packages as checksum will differ.
|
||||
When launched from the local NuttX git repository clone the script will
|
||||
obtain all available tags to be downloaded, otherwise list of tags needs
|
||||
to be provided manually (or when just selected tag is required).
|
||||
This script uses ``wget`` underneath, make sure this tool is installed.
|
||||
Fetch log file is created with a timestamp in name next to the packages.
|
||||
|
||||
Having all tags packaged is important for changes comparison
|
||||
between specific versions, testing a specific version, compatibility
|
||||
checks, searching for a feature introduction timeline, etc.
|
||||
|
||||
Usage: ``./nxtagspkgsfetch.sh [download_path] [tags_list_space_separated]``
|
||||
|
||||
You can provide optional download path (default ``../../nuttx-packages``)
|
||||
and tags list to get packages for (default all tags from local git clone).
|
||||
When providing tags you also need to provide download path.
|
||||
@@ -1,5 +1,6 @@
|
||||
parsetrace.py
|
||||
=============
|
||||
=================
|
||||
``parsetrace.py``
|
||||
=================
|
||||
|
||||
`parsetrace.py` is a trace log parsing tool for the NuttX RTOS. It supports converting binary or text trace logs into a human-readable systrace format, and can resolve symbols and type information from ELF files. The tool also supports real-time trace data parsing via serial port.
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
=======
|
||||
pic32mx
|
||||
=======
|
||||
|
||||
This directory contains build tools used only for PIC32MX/Z platforms
|
||||
@@ -0,0 +1,122 @@
|
||||
==============
|
||||
``refresh.sh``
|
||||
==============
|
||||
|
||||
.. note::
|
||||
|
||||
This script with ``--silent`` is really obsolete. The silent option really
|
||||
adds default values. However, as of 217-07-09, defconfig files are retained
|
||||
in a compressed format, i.e., with default values removed. So the
|
||||
``--silent`` option will accomplish nothing. Without ``--silent``, you will
|
||||
have the opportunity over override the default value from the command line
|
||||
and, in that case, the script may still have some minimal value.
|
||||
|
||||
This is a bash script that automates refreshing of board default configuration
|
||||
(defconfig) files. It does not do anything special that you cannot do manually,
|
||||
but is useful for updating dozens of configuration files. It is also used in the
|
||||
NuttX CI process.
|
||||
|
||||
Configuration files have to be updated because over time, the configuration
|
||||
settings change; new configurations are added and new dependencies are added.
|
||||
So an old configuration file may not be usable anymore until it is refreshed.
|
||||
|
||||
Help is also available:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/refresh.sh --help
|
||||
tools/refresh.sh is a tool for refreshing board configurations
|
||||
|
||||
USAGE: tools/refresh.sh [options] <board>:<config>+
|
||||
|
||||
Where [options] include:
|
||||
--debug
|
||||
Enable script debug
|
||||
--silent
|
||||
Update board configuration without interaction. Implies --defaults.
|
||||
Assumes no prompt for save. Use --silent --prompt to prompt before saving.
|
||||
--prompt
|
||||
Prompt before updating and overwriting the defconfig file. Default is to
|
||||
prompt unless --silent
|
||||
--defaults
|
||||
Do not prompt for new default selections; accept all recommended default values
|
||||
--nocopy
|
||||
Do not copy defconfig from nuttx/boards/<board>/configs to nuttx/.config
|
||||
--help
|
||||
Show this help message and exit
|
||||
<board>
|
||||
The board directory under nuttx/boards/arch/chip/
|
||||
<config>
|
||||
The board configuration directory under nuttx/boards/arch/chip/<board>/configs
|
||||
<archname>
|
||||
The architecture directory under nuttx/boards/
|
||||
<chipname>
|
||||
The chip family directory under nuttx/boards/<arch>/
|
||||
|
||||
Note1: all configurations are refreshed if <board>:<config> is replaced with "all" keyword
|
||||
Note2: all configurations of arch XYZ are refreshed if "arch:<namearch>" is passed
|
||||
Note3: all configurations of chip XYZ are refreshed if "chip:<chipname>" is passed
|
||||
Note4: all configurations of board XYZ are refreshed if "board:<boardname>" is passed
|
||||
|
||||
The steps to refresh the file taken by ``refresh.sh`` are:
|
||||
|
||||
1. Make ``tools/cmpconfig`` if it is not already built.
|
||||
|
||||
2. Copy the defconfig file to the top-level NuttX directory as ``.config``
|
||||
(being careful to save any previous ``.config`` file that you might want to
|
||||
keep!).
|
||||
|
||||
3. Execute ``make` oldconfig` to update the configuration. ``make oldconfig``
|
||||
will prompt you for each change in the configuration that requires that you
|
||||
make some decision. With the ``--silent`` option, the script will use ``make
|
||||
oldefconfig`` instead and you won't have to answer any questions; the refresh
|
||||
will simply accept the default value for any new configuration settings.
|
||||
|
||||
4. Then it runs ``tools/cmpconfig`` to show the real differences between the
|
||||
configuration files. Configuration files are complex and things can move
|
||||
around so a simple 'diff' between two configuration files is often not
|
||||
useful. But tools/cmpconfig will show only the meaningful differences
|
||||
between the two configuration files.
|
||||
|
||||
5. It will edit the .config file to comment out the setting of the
|
||||
``CONFIG_APPS_DIR=`` setting. This setting should not be in checked-in
|
||||
defconfig files because the actually must be determined at the next time that
|
||||
the configuration is installed.
|
||||
|
||||
6. Finally, the refreshed defconfig file is copied back in place where it can be
|
||||
committed with the next set of difference to the command line. If you select
|
||||
the ``--silent`` option, this file copy will occur automatically. Otherwise,
|
||||
refresh.sh will prompt you first to avoid overwriting the defconfig file with
|
||||
changes that you may not want.
|
||||
|
||||
Usage examples:
|
||||
|
||||
Update all boards without verbose output:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/refresh.sh --silent --defaults all
|
||||
|
||||
Update all boards and configs from `arm` architecture:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/refresh.sh --silent arch:arm
|
||||
|
||||
Update all boards from ``stm32f7`` chip family:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/refresh.sh --silent chip:stm32f7
|
||||
|
||||
Update all configs from ``stm32f103-minimum`` board:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/refresh.sh --silent board:stm32f103-minimum
|
||||
|
||||
Update only the `.nsh.` config from stm32f103-minimum board:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/refresh.sh --silent stm32f103-minimum:nsh
|
||||
@@ -0,0 +1,7 @@
|
||||
==========
|
||||
``rmcr.c``
|
||||
==========
|
||||
|
||||
Removes all white space from the end of lines. Whitespace here includes space
|
||||
characters, TAB characters, horizontal and vertical TABs, and carriage returns.
|
||||
Lines will be terminated with the newline character only.
|
||||
@@ -0,0 +1,46 @@
|
||||
==============
|
||||
``sethost.sh``
|
||||
==============
|
||||
|
||||
Saved configurations may run on Linux, Cygwin (32- or 64-bit), or other
|
||||
platforms. The platform characteristics can be changed use 'make menuconfig'.
|
||||
Sometimes this can be confusing due to the differences between the platforms.
|
||||
Enter sethost.sh
|
||||
|
||||
sethost.sh is a simple script that changes a configuration to your host
|
||||
platform. This can greatly simplify life if you use many different
|
||||
configurations. For example, if you are running on Linux and you configure like
|
||||
this:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/configure.sh board:configuration
|
||||
|
||||
The you can use the following command to both (1) make sure that the
|
||||
configuration is up to date, AND (2) the configuration is set up
|
||||
correctly for Linux:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/sethost.sh -l
|
||||
|
||||
Or, if you are on a Windows/Cygwin 64-bit platform:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/sethost.sh -c
|
||||
|
||||
Other options are available:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./sethost.sh -h
|
||||
|
||||
USAGE: ./sethost.sh [-l|m|c|g|n] [make-opts]
|
||||
./sethost.sh -h
|
||||
|
||||
Where:
|
||||
-l|m|c|g|n selects Linux (l), macOS (m), Cygwin (c),
|
||||
MSYS/MSYS2 (g) or Windows native (n). Default Linux
|
||||
make-opts directly pass to make
|
||||
-h will show this help test and terminate
|
||||
@@ -0,0 +1,14 @@
|
||||
===============
|
||||
``showsize.sh``
|
||||
===============
|
||||
|
||||
Show the top 10 biggest memory hogs in code and data spaces. This must be
|
||||
executed from the top-level NuttX directory like:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/showsize.sh
|
||||
TOP 10 BIG DATA
|
||||
...
|
||||
TOP 10 BIG CODE
|
||||
...
|
||||
@@ -0,0 +1,15 @@
|
||||
================
|
||||
``simbridge.sh``
|
||||
================
|
||||
|
||||
Helper script used to set up a bridge to support networking with the
|
||||
simulator under Linux.
|
||||
|
||||
General usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/simbridge.sh
|
||||
Usage: tools/simbridge.sh <interface> <on|off>
|
||||
|
||||
See ``boards/sim/sim/sim/NETWORK-LINUX.txt`` for further information.
|
||||
@@ -0,0 +1,15 @@
|
||||
===================
|
||||
``simhostroute.sh``
|
||||
===================
|
||||
|
||||
Helper script used to set up the tap driver, host routes, and IP Tables rules to
|
||||
support networking with the simulator under Linux.
|
||||
|
||||
General usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ tools/simhostroute.sh
|
||||
Usage: tools/simhostroute.sh <interface> <on|off>
|
||||
|
||||
See ``boards/sim/sim/sim/NETWORK-LINUX.txt`` for further information.
|
||||
@@ -0,0 +1,75 @@
|
||||
================
|
||||
``testbuild.sh``
|
||||
================
|
||||
|
||||
This script automates building of a set of configurations. The intent is
|
||||
simply to assure that the set of configurations build correctly. The -h
|
||||
option shows the usage:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./testbuild.sh -h
|
||||
USAGE: tools/testbuild.sh -h [-l|m|c|g|n] [-d] [-e <extraflags>] [-x] [-j <ncpus>] [-a <appsdir>] [-t <topdir>] [-p]
|
||||
[-A] [-C] [-G] [-N] [-R] [-S] [--codechecker] <testlist-file>
|
||||
|
||||
Where:
|
||||
-h will show this help test and terminate
|
||||
-l|m|c|g|n selects Linux (l), macOS (m), Cygwin (c),
|
||||
MSYS/MSYS2 (g) or Windows native (n). Default Linux
|
||||
-d enables script debug output
|
||||
-e pass extra c/c++ flags such as -Wno-cpp via make command line
|
||||
-x exit on build failures
|
||||
-j <ncpus> passed on to make. Default: No -j make option.
|
||||
-a <appsdir> provides the relative path to the apps/ directory. Default ../apps
|
||||
-t <topdir> provides the absolute path to top nuttx/ directory. Default ../nuttx
|
||||
-p only print the list of configs without running any builds
|
||||
-A store the build executable artifact in ARTIFACTDIR (defaults to ../buildartifacts
|
||||
-C Skip tree cleanness check.
|
||||
-G Use "git clean -xfdq" instead of "make distclean" to clean the tree.
|
||||
This option may speed up the builds. However, note that:
|
||||
* This assumes that your trees are git based.
|
||||
* This assumes that only nuttx and apps repos need to be cleaned.
|
||||
* If the tree has files not managed by git, they will be removed
|
||||
as well.
|
||||
-N Use CMake with Ninja as the backend.
|
||||
-R execute "run" script in the config directories if exists.
|
||||
-S Adds the nxtmpdir folder for third-party packages.
|
||||
--codechecker enables CodeChecker statically analyze the code.
|
||||
<testlist-file> selects the list of configurations to test. No default
|
||||
|
||||
Your PATH variable must include the path to both the build tools and the
|
||||
kconfig-frontends tools
|
||||
|
||||
This script needs two pieces of information:
|
||||
|
||||
1. A description of the platform that you are testing on. This description
|
||||
is provided by the optional -l, -m, -c, -g and -n options.
|
||||
|
||||
2. A list of configurations to build. That list is provided by a test
|
||||
list file. The final, non-optional parameter, <testlist-file>,
|
||||
provides the path to that file.
|
||||
|
||||
The test list file is a sequence of build descriptions, one per line. One
|
||||
build descriptions consists of two comma separated values. For example::
|
||||
|
||||
stm32f429i-disco:nsh
|
||||
arduino-due:nsh
|
||||
/arm
|
||||
/risc-v
|
||||
|
||||
The first value is the usual configuration description of the form
|
||||
``<board-name>:<configuration-name>`` or ``/<folder-name>`` and must correspond to a
|
||||
configuration or folder in the nuttx/boards directory.
|
||||
|
||||
The second value is valid name for a toolchain configuration to use
|
||||
when building the configuration. The set of valid toolchain
|
||||
configuration names depends on the underlying architecture of the
|
||||
configured board.
|
||||
|
||||
The prefix ``-`` can be used to skip a configuration::
|
||||
|
||||
-stm32f429i-disco/nsh
|
||||
|
||||
or skip a configuration on a specific host(e.g. Darwin)::
|
||||
|
||||
-Darwin,sim:rpserver
|
||||
@@ -0,0 +1,69 @@
|
||||
==================
|
||||
``uncrustify.cfg``
|
||||
==================
|
||||
|
||||
This is a configuration script for the uncrustify code beautifier.
|
||||
Uncrustify does well with forcing braces into "if" statements and
|
||||
indenting per the NuttX C coding standard. It correctly does things
|
||||
like placing all braces on separate lines at the proper indentation
|
||||
level. It cannot handle certain requirements of the coding standard
|
||||
such as
|
||||
|
||||
- FAR attributes in pointer declarations.
|
||||
- The NuttX standard function header block comments.
|
||||
- Naming violations such as use of CamelCase variable names,
|
||||
lower case pre-processor definitions, etc.
|
||||
|
||||
Comment blocks, function headers, files headers, etc. must be formatted
|
||||
manually.
|
||||
|
||||
Its handling of block comments is fragile. If the comment is perfect,
|
||||
it leaves it alone, but if the block comment is deemed to need a fix
|
||||
it starts erroneously indenting the continuation lines of the comment.
|
||||
|
||||
- uncrustify.cfg messed up the indent of most block comments.
|
||||
cmt_sp_before_star_cont is applied inconsistently. I added::
|
||||
|
||||
cmt_indent_multi = false # disable all multi-line comment changes
|
||||
|
||||
to the .cfg file to limit its damage to block comments.
|
||||
- It is very strict at wrapping lines at column 78. Even when column 79
|
||||
just contained the ``/`` of a closing ``*/``. That created many
|
||||
bad continuation lines.
|
||||
|
||||
- It moved '{' that opened a struct to the line defining the struct.
|
||||
nl_struct_brace = add (or force) seemed to be ignored.
|
||||
|
||||
- It also aligned variable names in declarations and '=' signs in
|
||||
assignment statements in a seemingly arbitrary manner. Making changes
|
||||
that were not necessary.
|
||||
|
||||
.. note::
|
||||
|
||||
uncrustify.cfg should **ONLY** be used with new files that have an
|
||||
inconsistent coding style. uncrustify.cfg should get you in the ballpark,
|
||||
but you should expect to review and hand-edit the files to assume 100%
|
||||
compliance.
|
||||
|
||||
.. warning::
|
||||
|
||||
**NEVER** use uncrustify.cfg for modifications to existing NuttX files. It
|
||||
will probably corrupt the style in subtle ways!
|
||||
|
||||
This was last verified against uncrustify 0.66.1 by Bob Feretich.
|
||||
|
||||
About uncrustify: Uncrustify is a highly configurable, easily modifiable
|
||||
source code beautifier. To learn more about uncrustify:
|
||||
|
||||
http://uncrustify.sourceforge.net/
|
||||
|
||||
Source code is available on GitHub:
|
||||
|
||||
https://github.com/uncrustify/uncrustify
|
||||
|
||||
Binary packages are available for Linux via command line installers.
|
||||
Binaries for both Windows and Linux are available at:
|
||||
|
||||
https://sourceforge.net/projects/uncrustify/files/
|
||||
|
||||
See also :doc:`/components/tools/indent` and :doc:`/components/tools/nxstyle`.
|
||||
@@ -0,0 +1,6 @@
|
||||
===
|
||||
zds
|
||||
===
|
||||
|
||||
This directory contains build tools used only with the ZDS-II
|
||||
platforms (z8, ez80, zNeo).
|
||||
@@ -0,0 +1,27 @@
|
||||
============
|
||||
``zipme.sh``
|
||||
============
|
||||
|
||||
I use this script to create the nuttx-xx.yy.tar.gz tarballs for
|
||||
release. It is handy because it also does the kind of clean up
|
||||
that you need to do to make a clean code release.
|
||||
It can also PGP sign the final tarballs and create their SHA512 hash.
|
||||
Any VCS files or directories are excluded from the final tarballs.
|
||||
|
||||
Help:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/zipme.sh -h
|
||||
USAGE="USAGE: ./tools/zipme.sh [-d|h|v|s] [-b <build]> [-e <exclude>] [-k <key-id>] [<major.minor.patch>]"
|
||||
|
||||
Examples:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ ./tools/zipme.sh -s 9.0.0
|
||||
# Create version 9.0.0 tarballs and sign them.
|
||||
$ ./tools/zipme.sh -s -k XXXXXX 9.0.0
|
||||
# Same as above but use the key-id XXXXXX to sign the tarballs
|
||||
$ ./tools/zipme.sh -e "*.swp tmp" 9.0.0
|
||||
# Create the tarballs but exclude any .swp file and the "tmp" directory.
|
||||
Reference in New Issue
Block a user