794c325947 ("arch/x64:Syscall support is enabled by default", 2025-05-27)
changed nine guards from CONFIG_LIB_SYSCALL to CONFIG_ARCH_HAVE_SYSCALL but
never added the Kconfig symbol. Only ARCH_HAVE_SYSCALL_HOOKS exists in tree;
ARCH_HAVE_SYSCALL itself is defined nowhere, so it is always unset and since
that commit x86_64 has had no x86_64_syscall_entry(), no x86_64_syscall(), no
IA32_LSTAR/IA32_STAR programming and no syscall stub layer in any
configuration:
arch/x86_64/src/common/Make.defs:37 x86_64_syscall.c not compiled
arch/x86_64/src/common/CMakeLists.txt:41 likewise
arch/x86_64/include/irq.h:86
arch/x86_64/src/intel64/intel64_cpu.c:247, :386
arch/x86_64/src/intel64/intel64_head.S:83, :351, :538
arch/x86_64/src/intel64/intel64_saveusercontext.S:108
qemu-intel64:knsh_romfs and qemu-intel64:knsh_romfs_pci are the two
CONFIG_BUILD_KERNEL configurations in tree, and neither can have worked in
that time. They still link -- nothing references the missing pieces, so
libstubs.a is simply never pulled in -- and then die the first time user code
executes SYSCALL.
Define the symbol with the condition the code had before that commit, which
is LIB_SYSCALL: every protected and every kernel build needs the interface,
and a flat build is left exactly as it is today.
Impact: restores the system call interface for CONFIG_BUILD_KERNEL and
CONFIG_BUILD_PROTECTED on x86_64. CONFIG_BUILD_FLAT is unaffected --
qemu-intel64:nsh still builds with ARCH_HAVE_SYSCALL unset.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
While attempting to create architecture-specific implementation
of up_udelay, it was discovered that the overriding function is not
included in the final binary, the weak implementation was used instead.
Further investigation and experimentation showed that the linker
only overrides the weak implementation with the custom one if
the custom one is present in a .c source file that contains at least
one other function that is called from somewhere. Some additional
testing revealed that at least one other already present up_udelay
override (rv32m1-vega:nsh) is affected by this.
In a short mailing list discussion it was determined that this
is a likely result of using static libraries during the build process
and it was suggested to introduce configuration option that will
exclude weak implementations of the function from the build altogether.
This patch does that.
This patch does not enable this configuration option for any existing
board/chip because doing so would change its behaviour and needs
to be tested by users of the hardware.
Also changed is the static assertion in sched/clock/clock_delay.c
to not prevent building the code when architecture declares that
it does not use BOARD_LOOPSPERMSEC to determine required loop count.
BOARD_LOOPSPERMSEC is made undefined in such case.
Patch was tested by building breadxavr:nsh (identical binary by SHA256),
rv32m1-vega:nsh (identical text section) and rv-virt:nsh (text section
differs because of different ordering of functions in the binary, ostest
passed though.)
Signed-off-by: Kerogit <kr.git@kerogit.eu>
Implement up_backtrace() for TriCore by walking the CSA chain and
collecting return addresses from upper CSA A11 register.
Signed-off-by: LukeKun <donghaokun@lixiang.com>
Changes the default value for CONFIG_BOARD_LOOPSPERMSEC to -1, which is
invalid. All boards that forget to configure this value will encounter a
static assertion at compile time, enforcing that configurations
upstreamed to NuttX have calibrated values for correct delay timings.
Boards which implement ALARM_ARCH or TIMER_ARCH do not rely on the
busy-loop delay implementation and thus only have a run-time check to
ensure proper delay-timings (in the case where delays are used before
the alarm/timer driver is registered).
Some boards already in the NuttX upstream do not have calibrated values,
but there are no users who currently own the board to submit a
calibrated value for the configurations to use. In this scenario, the
value is temporarily set to 0 and a warning is displayed so that users
of these boards are informed of the calibration process.
Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
Enable SYSCALL_HOOKS architecture capability for TriCore platform.
This allows runtime interception and hooking of system calls on
TriCore architecture, enabling profiling, tracing, and debugging features.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Add ARCH_HAVE_PERF_EVENTS_USER_ACCESS capability to allow applications
to directly access hardware perf counters via perf_gettime() from
userspace, enabling performance monitoring and profiling without syscalls.
Signed-off-by: Yanfeng Liu <p-liuyanfeng9@xiaomi.com>
dd ARCH_PERF_COUNT_BITWIDTH configuration to support architectures
with different perf counter bit widths (TriCore 31-bit, others 32-bit),
enabling proper overflow correction across diverse platforms.
Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>
Add default values (0x0) for ARCH_TEXT_VBASE, ARCH_DATA_VBASE, and
ARCH_HEAP_VBASE to resolve cmake configuration warnings when these
values are not explicitly set during initialization.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Expand ARCH_KERNEL_STACK configuration to support both BUILD_KERNEL and
BUILD_PROTECTED modes. Change Kconfig dependency from "depends on BUILD_KERNEL"
to "depends on BUILD_KERNEL || BUILD_PROTECTED". Update pthread_create.c to
remove redundant BUILD_KERNEL check when allocating kernel stacks with
CONFIG_ARCH_KERNEL_STACK enabled. Enables protected builds to use separate
kernel and user stacks for processes.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Modify ARM64 architecture configuration to disable fork support in protected
build mode (BUILD_PROTECTED). Update ARCH_HAVE_FORK condition from
"!BUILD_KERNEL" to "!BUILD_KERNEL && !BUILD_PROTECTED", ensuring fork is
only available in flat/monolithic builds, not in protected kernel builds.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Add new CONFIG_NCPUS configuration option to support both SMP and AMP modes.
Replace SMP-specific CONFIG_SMP_NCPUS checks with generic CONFIG_NCPUS in ARM
boot code (ARMv7-A, ARMv7-R, ARMv8-R). CONFIG_NCPUS defaults to SMP_NCPUS when
SMP is enabled, or 1 otherwise, enabling multi-CPU support regardless of SMP mode.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
tricore csa is not continuous. when assert prints information, we need to handle the regs specially in order to dump all the registers.
Signed-off-by: zhangyu117 <zhangyu117@xiaomi.com>
Add condition checking in Kconfig source statement, for example:
source "arch/arm/Kconfig" is updated to:
if ARCH_ARM
source "arch/arm/Kconfig"
endif
Signed-off-by: Chengdong Wang <wangchengdong@lixiang.com>
In the toolchain, ARCH_TOOLCHAIN_XXX is used to select the compiler to be used. If clang is selected here, subsequent errors will occur
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
1. Add hw_tags.c, which will call arm64_mte to implement tagging of memory blocks by operating registers
2. It has been able to run normally on the default NX memory allocator, excluding mempool and tlsf
3. On more complex configurations, memory tests such as memstress can run normally without system crashes
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
Some code paths in drivers/serial/serial.c load head and tail values
of receive and transmit circular buffers with interrupts enabled,
making it possible that the interrupt handler changes the value.
As noted in the code, this is safe as long as the load itself is atomic.
That is not true for 8bit architectures which fetch the 16-bit values
using two load instructions. If interrupt handler runs between those
two instructions and changes the value, the read returns corrupted data.
This patch introduces CONFIG_ARCH_LDST_16BIT_NOT_ATOMIC configuration
option which is automatically selected for AVR architecture. Based
on this option, head and tail values are reduced to 8-bit length
so the read remains atomic.
Patch was tested by building on rv-virt:nsh - disassembly of functions
from serial.c showed no difference which is correct as Risc-V does
not need to protect reads of these values. There should be no impact
for architectures that do not set the new configuration option.
It was also tested by by custom echo application running on AVR128DA28.
Signed-off-by: Kerogit <kr.git@kerogit.eu>
Optimize crc32 standard(poly:0x04C11DB7) and crc32
castagnoli(poly:0x1EDC6F41) with arm crc32 extension instructions.
For example, crc32 standard caculates(lookup crc32 table) 1812 bytes data,
reduced the time from 118 us to 14 us through optimization.
Performance improved ~700%
Signed-off-by: Jinliang Li <lijinliang1@lixiang.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>
Implement hartid<->cpuid mapping for RISC-V. This is necessary for some
platforms which cannot use 1:1 mapping between logical and physical CPU /
core IDs. One example is MPFS where hart0 cannot be used for NuttX SMP as
it is a less capable "monitor" core (E51) compared to the application
cores hart1...3 (E54).
Why not just use a generic offset then? We also need the physical hart ID
for many things:
- Communication between harts (IPI)
- External interrupt acknowledgment (interrupt claim for specific CPU)
- Communication to SBI
Thus, create procedures that can do this translation:
- The default mapping is still logical=physical.
- Another flavor is to use the existing CONFIG_ARCH_RV_HARTID_BASE config
variable, which is just a simple offset
- The final flavor is to overload hartid<->cpuid on a per chip basis (no
example for this is provided yet)
This implements empty hooks to the arch/chip layer, which can implement
an optional translation between logical<->physical CPU/core id.
The default mapping is 1:1 i.e. logical=physical.
Summary:
Add the default CPU frequency configuration.
Signed-off-by: wangming9 <wangming9@xiaomi.com>
Signed-off-by: lipengfei28 <lipengfei28@xiaomi.com>
The feature depends on ARCH_USE_SEPARATED_SECTION
the different memory area has different access speed and cache
capability, so the arch can custom allocate them based on
section names to achieve performance optimization
test:
sim:elf
sim:sotest
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Some of PCI drivers require OS interfaces that can't be executed in the INIT context.
In that case we have to postpone PCI drivers probing and call it for example
in board initialization logic.
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
