An NXFLAT module reaches the base firmware through a "thunk" file: one
assembly stub per imported function, generated by mknxflat. That tool
has always lived outside this repository, in the NuttX buildroot NXFLAT
toolchain, so building an NXFLAT module needs a separate checkout and a
separate build of a tool that links against libbfd.
libbfd is why it stayed out. It is GPL, which an Apache project cannot
depend on, and it is awkward to obtain besides -- a stock binutils
install often ships libbfd without the libiberty it needs to link. But
the dependency was never deep. mknxflat used libbfd for eight calls,
all of them opening the file and walking the symbol table; it never
relocates or rewrites anything. That is replaced here by reading the
ELF symbol table directly, which removes the dependency outright and
costs about a hundred lines.
The emitted text is unchanged. The format strings live in the .def
files, which are carried here byte-for-byte from upstream, and the
selection rule for what becomes a thunk is the upstream one: everything
undefined that is not explicitly an object. Symbol typing cannot be
trusted for this -- imported functions are routinely emitted as
STT_NOTYPE rather than STT_FUNC, while a weakly defined object does
appear as an undefined object -- so the test is on what a symbol is not.
Upstream chose the instruction set at compile time through an "arch"
symlink pointing at either arm/ or thumb2/. A symlink cannot be carried
in the repository, and one host binary has to serve boards of both
flavours, since lpc31xx is ARM while lpc17xx, tiva, stm32f1 and rp23xx
are Thumb-2. That choice becomes a runtime "-a" option. The "-f"
option, which read further command line arguments from a file, is
dropped; nothing in the tree used it.
This commit changes no output. Against the upstream tool, for both
architectures, with and without -w, over modules exercising the plain,
weak and non-returning thunk paths, the generated thunk files are
byte-identical.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Add standalone host PBKDF2-HMAC-SHA256 mkpasswd, board_romfs_mkpasswd.sh,
and promptpasswd.sh with confirm-password support. Integrate ROMFS passwd
generation in Board.mk and CMake. Drop TEA key checks from passwd_keys.mk.
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Introduce mkpasswd, a pure-C host tool for generating encrypted password
files at build time using TEA encryption. This enables secure,
credential-free firmware images while allowing build-time password
configuration.
Changes:
* Add mkpasswd.c host tool for TEA-based password hashing and encryption
* Integrate mkpasswd into Make build system (tools/Makefile.host)
* Add CMake support for mkpasswd compilation and ROMFS passwd generation
* Add CONFIG_BOARD_ETC_ROMFS_PASSWD_* configuration options to Kconfig
* Implement credential exclusion from defconfig to prevent password leaking
* Update savedefconfig.cmake to strip sensitive credentials
* Fix mkdir() portability for Windows Native builds (CONFIG_WINDOWS_NATIVE)
* Change default username from "admin" to "root" (POSIX convention)
* Improve build-failure error message with full menuconfig navigation path
BREAKING CHANGE: Boards enabling CONFIG_BOARD_ETC_ROMFS_PASSWD_ENABLE
must set CONFIG_BOARD_ETC_ROMFS_PASSWD_PASSWORD to a non-empty string
of at least 8 characters. The build now fails with an explicit error if
this config is left empty. To fix: run 'make menuconfig' and navigate to:
Board Selection --->
Auto-generate /etc/passwd at build time --->
Admin password
Signed-off-by: Abhishek Mishra <mishra.abhishek2808@gmail.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Use `JLinkGDBServer -rtos libnuttxplugin` to add this plugin.
Then in gdb can use command:
- `info threads` to show all threads infos
- `thread (id) ` to switch thread.
- `bt` to show thread backtrace.
Signed-off-by: zhuyanlin <zhuyanlin1@xiaomi.com>
the mkspk tool will automaticaly be built if CONFIG_CXD56_BINARY
is set.
Test:
nuttx.spk was succesfully generated
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Make.defs under board folder can still overwrite the default as needed
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I1c300a8ace4b54d475ef8d398661ed65ca273a2e
Remove tools/logparser.c. This tool converted 'git log' output into the format used by the obsoleted ChangeLog files. Since the ChangeLog files are obsoleted, the tool servers no purpose.
Namely this changes HOSTOS for macOS from "Other" to "Darwin".
Also, suppress the following harmless messages during a "make":
(Missing redirect in tools/Makefile.host)
uname: illegal option -- o
usage: uname [-amnprsv]
1. Can't pipe uname stderr output to /dev/null. /dev/null does not exist in the Windows native enviornment.
2. Don't test if CONFIG_WINDOWS_NATIVE is defined. Tht leads to a "chicken'n'egg" problem: We need to build configure.c in order to configure the system, but we can't get the CONFIG_WINDOWS_NATIVE until after the system is configured.
3. The default name of the MinGW GCC compiler is mingw32-gcc.exe, not mingw-gcc.exe
Squashed commit of the following:
tools/gencromfs.c: Seems basically functional but has not has not yet been integrated with CROMFS.
tools/gencromfs.c: Revist previous commit. Let's make no assumptions about the compatibility of the host system and NuttX.
tools/gencromfs.c: I think access mode bits are sufficiently standard that we can just copy them from the host. This is don't mostly to pick up the executable bits and other conbinations of bits without doing a bit-for-bit decode.
tools/gencromfs.c: Code complete but only partially functional.
tools/gencromfs.c: type definitions must precede data definitions
tools/gencromfs.c: Adds a little more logic to gencromfs tools. Still not complete but can traverse directories and generate directory and hard-link nodes.
tools/gencromfs.c: Beginning of a genromfs tool that will eventually be used for generation of CROMFS file system images.
