The mcuboot-loader image overflows its flash region once the FAT deferred-delete change is applied. Long filename support is not needed by the bootloader, which boots from flash areas and never opens FAT files by long name, so disable CONFIG_FAT_LFN to reclaim the space while keeping short filename support intact.
Signed-off-by: Arnav Sharma <2006arnavsharma@gmail.com>
ARM PIC has used r10 as the base register, but the tree has never been
consistent about it. Toolchain.defs gives CONFIG_BUILD_PIC
-mpic-register=r9 and CONFIG_PIC -mpic-register=r10, twenty-five lines
apart, and arm_initialstate.c sets REG_R9 from inline assembly under one
and REG_PIC under the other, with a comment reading "Set the PIC base
register (probably R10)". This settles it on r9 for all of PIC: NXFLAT,
ELF PIC and CONFIG_BUILD_PIC alike.
r9 is the right choice rather than an arbitrary one. It is the AAPCS
platform register, the "static base", and it is what GCC itself picks
for -msingle-pic-base on an EABI target; r10 is the non-EABI default.
It also removes a combination that cannot build today. Stack checking
adds -ffixed-r10 in armv7-m/Toolchain.defs and armv8-m/Toolchain.defs,
while CONFIG_PIC adds -mpic-register=r10, and GCC rejects the pair with
"unable to use 'r10' for PIC register". The comment above REG_PIC has
always said the register "can be R9 if stack checking is enabled", but
the definition was unconditionally REG_R10, so it would have named the
wrong register even had the build succeeded.
The thunk generator moves with the firmware. NXFLAT import stubs had
the register baked in as "add ip,ip,sl", so a module built for r9 would
load and then branch to a wild address on its first call out. The stubs
now come from NXFLAT_PIC_REG in the in-tree tool, which is built only
when CONFIG_NXFLAT is set, following the
CONFIG_BOARD_ETC_ROMFS_PASSWD_ENABLE precedent in tools/Unix.mk.
That leaves modules built before this change, and they are the reason
for the ABI marker. The NXFLAT header cannot carry a version: h_magic
is written by ldnxflat, which is GPL, derived from elf2flt, and stays
out of this repository, so it can never be changed in step with the
loader. The import table can, because both of its ends are in-tree --
mknxflat emits it and nxflat_bindimports() reads it -- and ldnxflat
passes it through untouched. So every module now imports
__nxflat_abi_v2, the base firmware defines it, and a module that does
not import it is refused.
Making the marker a real exported symbol rather than a name the loader
special-cases is what keeps it out of the build system's way: a board's
symbol table picks it up exactly as it picks up printf, so mksymtab.sh
and its equivalents need no change. It also gives the reverse direction
a diagnosis for free -- a module built against a newer ABI than its
firmware fails with "Exported symbol __nxflat_abi_v2 not found".
Most of the remaining churn is boards restating a default. ARCHPICFLAGS
is a "?=" default so that a board only speaks up when it differs, and
twenty-six were assigning the value the default already had. MKNXFLAT
gets the same treatment: thirteen boards named the same tool, and the
only thing that varies is ARM versus Thumb-2, which falls out of
CONFIG_ARM_THUMB. LDNXFLAT gains a default too -- it stays an
out-of-tree PATH lookup, but naming it centrally fixes boards that never
assigned it, where it expanded to nothing and handed make a recipe
beginning "-e", whose leading dash make ate as "ignore errors".
The non-ARM boards carrying -mpic-register=r10 lose it: it is an
ARM-only option, reachable only through CPICFLAGS, which is only used to
build NXFLAT modules, and no non-ARM board enables NXFLAT.
Boards keep nothing about PIC flags any more. ARCHPICFLAGS was set by
sixty-three of them and only ever fed CPICFLAGS, which is only used to
build NXFLAT modules; no board outside arch/arm enables NXFLAT, so every
non-ARM copy was setting a variable nothing read. Those are removed
rather than moved somewhere more central, which would only make dead
text look load-bearing. LDNXFLAT goes the same way as MKNXFLAT, for the
same reason: thirteen boards named the same tool that Toolchain.defs now
names once.
One of them was not merely redundant. am67/t3-gem-o1 asked for
"-mpic-register=r10 -ffixed-r10", which GCC refuses outright with
"unable to use 'r10' for PIC register" -- the very combination the
filter-out machinery in Toolchain.defs exists to prevent. It has
survived because that board does not build NXFLAT modules, so the flags
are never handed to a compiler. Renaming the register would have
carried the fault forward unchanged, so the line goes.
Tested on lm3s6965-ek:qemu-nxflat under QEMU, configured and built with
no overrides. The nxflat example runs the errno, hello and struct
modules with output identical to the same config built from master.
Built with the old out-of-tree thunk generator instead, the same
firmware refuses all three with ENOEXEC rather than locking up in a
HardFault, which is what this change is for. mps3-an547:picostest,
which is CONFIG_PIC without CONFIG_NXFLAT, builds clean and does not
build the thunk generator.
The .def files pick up two cosmetic changes here alongside the register:
a "Dyanamic" typo that codespell rejects, and a reworded comment in each
thunk_*.c. Neither appears in the emitted thunk -- both are in C
comments -- so the generated text is still what the upstream tool
produces, modulo the register itself.
BREAKING CHANGE: ARM PIC moves from r10 to r9. An NXFLAT module built
before this change has r10 baked into its import stubs and will not run
against a firmware carrying it; the two cannot be mixed. The module is
refused with ENOEXEC rather than branching to a wild address, by way of the
__nxflat_abi_v2 marker described below.
Quick fix: rebuild the module against this tree. Its source needs no
change. A board that reserved r10 by hand, or that assigned ARCHPICFLAGS
or MKNXFLAT to restate a default, should drop those assignments; nothing
else is affected, and CONFIG_PIC without CONFIG_NXFLAT needs no action.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Toolchain.defs adds --fixed-r10 to CFLAGS under CONFIG_PIC, but nearly
every board Make.defs includes that file and then assigns
CFLAGS := $(ARCHCFLAGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) ...
with ':=', which discards it. 266 of the 269 ARM board files assign
CFLAGS that way; the remaining three delegate to a shared makefile that
does the same thing.
The flag is what keeps the base firmware from allocating r10, the
register a PIC module reaches its own data through. Losing it is silent
and the symptom is remote from the cause: the build succeeds, and only a
callback from base firmware into module code -- qsort() with a module
comparison function is the standard case -- misbehaves, reading its data
through a register the firmware has since felt free to reuse.
Adding it to ARCHCFLAGS puts it on the far side of that ':=', which
re-expands ARCHCFLAGS, so every board picks it up with no board changes
at all.
A module is the other side of the --fixed-r10 contract: it gets r10 via
-mpic-register=r10, and GCC rejects both on one command line with
"unable to use 'r10' for PIC register". Every ARM board carried the
same three lines to set that up:
ARCHPICFLAGS = -fpic -msingle-pic-base -mpic-register=r10
CPICFLAGS = $(ARCHPICFLAGS) $(CFLAGS)
CXXPICFLAGS = $(ARCHPICFLAGS) $(CXXFLAGS)
They move to arch/arm/src/common/Toolchain.defs, which also filters
--fixed-r10 back out of CPICFLAGS, CXXPICFLAGS, CELFFLAGS and
CXXELFFLAGS in one place instead of each board having to know about the
interaction. ARCHPICFLAGS uses '?=' and the derived flags use deferred
'=', so a board can still override or append after including the file,
and CFLAGS is whatever the board finally set it to.
Two boards keep a definition because they genuinely differ: am67 adds
-ffixed-r10 and tiva conditionally adds -mno-pic-data-is-text-relative.
tlsr82 previously appended -fpic to an unset variable, so only -fpic
ever reached its compiler; it now inherits the standard set, verified
against tc32-elf-gcc 4.5.1.tc32-elf-1.5 (Telink TC32 v2.0), whose
ARM-derived backend honors -msingle-pic-base and -mpic-register=r10.
The mps2, mps3, qemu-armv7a, qemu-armv7r, fvp and mcx-nxxx families
referenced ARCHPICFLAGS without ever defining it, so their CPICFLAGS
carried no PIC flags at all; they get the standard set too.
Also adds the missing space in
CXXELFFLAGS = $(CXXFLAGS)-fvisibility=hidden -mlong-calls
which ran the last token of CXXFLAGS into -fvisibility=hidden, yielding
a single malformed token such as -DNDEBUG-fvisibility=hidden.
Also exempts the pre-existing "*.siz" gsize comment in Toolchain.defs
from codespell, which reads "siz" as a misspelling and fires for any
patch touching the file, since checkpatch scans whole files rather than
changed lines.
Before, with CONFIG_PIC=y: CFLAGS has --fixed-r10: NO
After: CFLAGS has --fixed-r10: YES
CPICFLAGS/CELFFLAGS: filtered out
Assisted-by: Claude Code:claude-opus-4-8
Assisted-by: Claude Code:claude-fable-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
Permissions (Part 2)
Description:
In kernel builds, any unprivileged process running on the NuttX
device can open /dev/efuse and attempt to read/write fuse content.
Reading the fuses may provide valuable information to an attacker
controlling the user process. The write operation, in extreme cases
where the fuse blocks are not locked, may brick the device.
DISCLAIMER: I tried to be strict with the settings, better to relax them
later if it's needed.
This is part of https://github.com/apache/nuttx/issues/19410
See https://github.com/apache/nuttx/issues/19410
Compiles ok.
Signed-off-by: Catalin Visinescu <catalin_visinescu@yahoo.com>
Long long support is now unconditional in printf/scanf and related
helpers. Remove the Kconfig option, the conditional compilation in
libvsprintf/libvscanf/ultoa_invert, the build-time #error in the
rn2xx3 driver, and clean up CONFIG_LIBC_LONG_LONG entries from all
board defconfigs.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
BREAKING CHANGE: remove PWM_MULTICHAN option
PWM_MULTICHAN option is redundant, we can just set CONFIG_PWM_NCHANNELS > 1.
At default CONFIG_PWM_NCHANNELS is set to 1, so the default behavior is preserved.
Access to single channel API is now `info->channels[0].XXX` instead of `info->XXX`
This is the first step to simplify PWM implementation and make it more portable.
Signed-off-by: raiden00pl <raiden00@railab.me>
Now that initialization is performed by BOARD_LATE_INITIALIZE,
app-specific initialization options are not needed.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
BREAKING: In an effort to simplify NuttX initialization, NSH_ARCHINIT is
removed. board_app_initialize is also removed. BOARD_LATE_INITIALIZE now
performs all board initialization logic, and is by default enabled. All
references to these symbols are removed. BOARDIOC_INIT remains, but will
result in -ENOTTY when called. It is to be removed in a later commit.
Quick fix: Boards relying on NSH_ARCHINIT should now enable
CONFIG_BOARD_LATE_INITIALIZE instead. If the application needs
fine-grained control over board initialization from userspace, the logic
performed by BOARDIOC_INIT may be copied to the board_finalinitialize
function and used instead via BOARDIOC_FINALINIT. All
board_app_initialize logic provided by NuttX is now moved to
board_late_initialize, and the same should be done for out-of-tree
boards.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Correct duplicate "is is" word found in 181 files throughout the
codebase.
In most cases "is is" was changed to "is", but in contexts like
"MCU is is sleep mode" it was corrected to "MCU in sleep mode".
Also fixes a "the the" typo in net/inet/inet_sockif.c.
This is a pure style/documentation fix that improves code readability.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Refactor heap pointer storage by moving us_heap field from userspace_s
to the nested userspace_data_s structure, enabling future extensibility
of user-space data without modifying the core userspace_s interface across
all board-specific implementations.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Userled register path shouldn't depend on LED example.
This dependency is broken, kernel code should not depend on apps code.
Signed-off-by: raiden00pl <raiden00@railab.me>
Upperhalf supports multiple working modes at the same time,
which is specified by NIC when register
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Disable configuration options that are not needed for MCUboot loader
- Disable floating point and long long support in libc
- Disable libm
- Disable POSIX features: environment variables, message queues, timers
and pthreads
- Disable RAMTEST app to save code space
Signed-off-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Nuttx currently has 2 types of sleep interfaces:
1. Signal-scheduled sleep: nxsig_sleep() / nxsig_usleep() / nxsig_nanosleep()
Weaknesses:
a. Signal-dependent: The signal-scheduled sleep method is bound to the signal framework, while some driver sleep operations do not depend on signals.
b. Timespec conversion: Signal-scheduled sleep involves timespec conversion, which has a significant impact on performance.
2. Busy sleep: up_mdelay() / up_udelay()
Weaknesses:
a. Does not actively trigger scheduling, occupy the CPU loading.
3. New interfaces: Scheduled sleep: nxsched_sleep() / nxsched_usleep() / nxsched_msleep() / nxsched_ticksleep()
Strengths:
a. Does not depend on the signal framework.
b. Tick-based, without additional computational overhead.
Currently, the Nuttx driver framework extensively uses nxsig_* interfaces. However, the driver does not need to rely on signals or timespec conversion.
Therefore, a new set of APIs is added to reduce dependencies on other modules.
(This PR also aims to make signals optional, further reducing the code size of Nuttx.)
Signed-off-by: chao an <anchao.archer@bytedance.com>
Most references to the readmes have been removed.
The removed references didn't make much sense and were inconsistent with other
sections of the code. Some sections linked to the readme, others didn't.
More importantly, most boards don't have any readme references.
Let's not treat developers as fools who need to be reminded at every step
to check the readme (which doesn't exit anymore anyway).
Signed-off-by: raiden00pl <raiden00@railab.me>
PIC32CZCA70 Curiosity evaluation kit now initializes and registers
a partition in an embedded flash. The end of the flash is used as
an example to avoid the interference with the actual code.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
We have adjusted the registration method for MTD devices
in nuttx/boards, replacing the previous approach using
ftl_initialize() and bchdev_register() with
register_mtddriver().
When registering MTD devices via register_mtddriver(),
FTL and BCH wrappers will be added during the open() process:
1. Character Device Mode:
When accessing the MTD device node via the open() interface,
the device will be automatically converted to a character
device. Both FTL and BCH wrappers will be implicitly added,
provided that BCH support is enabled in the configuration.
2. Block Device Mode:
When accessing the MTD device node via open_blockdriver(),
the device will be treated as a block device, with only
the FTL wrapper automatically applied.
Due to the automatic wrapping of MTD devices during the
open() process, the legacy registration methods
ftl_initialize() and bchdev_register() are no longer
required for MTD device registration for user code and should
be used only internally within fs and driver code.
Signed-off-by: jingfei <jingfei@xiaomi.com>
Renaming "modlib" to "libelf" is more in line with the implementation content,
which makes it easier for individual developers to understand the capabilities of this module.
CONFIG_LIBC_MODLIB -> CONFIG_LIBC_ELF
Signed-off-by: chao an <anchao.archer@bytedance.com>
The message RAM does not behave correctly if lower 16 bits of
buffer address overflow (upper 16 bits are set once in matrix driver
for the entire CAN driver). For example message RAM starting at
0x2040fc20 would not work for buffers that go beyond 0x20410000 and
MCAN would sent data located at 0x20400000 to the network. The same
issue would occur even if TX buffers would start directly at 0x20410000.
The upper 16 bits would still have 0x2040 value because of RX buffers
located in 0x2040ffff range.
This commit ensures the RAM is always located at the beginning of
the data section and thus the overflow mentioned above should never occur.
The alternative would be to use larger alignment, but the message RAM
can have up to 4352 words and this would cause a significant padding.
The RAM is also initialized to zero to ensure valid parity/ECC checksums.
The address issue is not described anywhere in the manual, so it is
possible this is caused by some incorrect configuration, but the context
of the registers looks valid.
This commit also fixes the compilation errors when the driver is run
without data cache.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
This adds the support for RX DMA polling. The board initializes
timer channel SAMV7_UART_RXDMA_POLL_TIMER with frequency
SAMV7_UART_RXDMA_POLL_FREQUENCY that triggers DMA polling function.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
This commit cleans up redundant header file includes throughout the codebase.
The changes include:
- Removing duplicate #include directives that were present in the same file
- Consolidating includes that were split across multiple lines unnecessarily
- Removing unused includes that were no longer needed
- Fixing some formatting issues with includes
The changes improve code organization and maintainability by:
- Reducing unnecessary dependencies
- Making include dependencies more explicit
- Following consistent include patterns
- Removing dead code
No functional changes are made - this is purely a code cleanup commit.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
reason:
svc call may trigger hardfault
Background
The origin of this issue is our desire to eliminate the function of storing
"regs" in g_current_regs and instead utilize (*running_task)->xcp.regs for storage.
The benefits of this approach include faster storage speed and
avoiding multiple accesses to g_current_regs during context switching,
thus ensuring that whether returning from an interrupt or an exception,
we consistently use this_task()->xcp.regs
Issue Encountered
However, when storing registers, we must ensure that (running_task)->xcp.regs is invalid
so that it can be safely overwritten.
According to the existing logic, the only scenario where (running_task)->xcp.regs
is valid is during restore_context. We must accurately identify this scenario.
Initially, we used the condition (running_task)==NULL for this purpose, but we deemed
this approach unsatisfactory as it did not align well with the actual logic.
(running_task) should not be NULL. Consequently, we adopted other arch-specific methods for judgment,
but due to special logic in some arch, the judgment was not accurate, leading to this issue.
Solution:
For armv6-m, we haven't found a more suitable solution, so we are sticking with (*running_task)==NULL.
For armv7-m/armv8-m, by removing support for primask, we can achieve accurate judgment.
PRIMASK is a design in armv6-m, that's why arm introduce BASEPRI from armv7-m.
It's wrong to provide this option for armv7-m/armv8-m arch.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
* It seems that they assume up_putc() and syslog() outputs to the
same device. Depending on the system and configurations, it's wrong.
* They are wrapped with "#if 0" and unused.
Fixes https://github.com/apache/nuttx/issues/14694
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>
This patch fixed userspace headers conflict. Architecture-related definition and API should not be exposed to users.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
Avoid compilation errors due to insufficient flash in CI
Configuration/Tool: same70-xplained/mcuboot-loader,CONFIG_ARM_TOOLCHAIN_GNU_EABI
2024-10-14 16:17:34
arm-none-eabi-ld: /github/workspace/sources/nuttx/nuttx section `.ramfunc' will not fit in region `flash'
arm-none-eabi-ld: region `flash' overflowed by 52 bytes
arm-none-eabi-ld: warning: /github/workspace/sources/nuttx/nuttx has a LOAD segment with RWX permissions
make[1]: *** [Makefile:212: nuttx] Error 1
make: *** [tools/Unix.mk:551: nuttx] Error 2
make: Target 'all' not remade because of errors.
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
After changing sp, following functions calling will result
in unpredictable behavior in case of jumping
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
