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>
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>
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>
Implement PIC loading in armv8-m qemu,
for example: load address-independent AP ELF in the bootloader,
and the text segment in AP ELF is XIP,
no need to apply for memory and modify it.
Two config:
bootloader abbreviation bl:
use romfs to load ap elf, use the boot command to parse and jump to ap
application abbreviation ap:
run os test
We need to compile ap first, then compile bl.
compile step:
./tools/configure.sh mps3-an547:ap
make -j20
mkdir -p pic
cp boot pic/.
genromfs -a 128 -f ../romfs.img -d pic
make distclean -j20
./tools/configure.sh mps3-an547:bl
make -j20
run qemu:
qemu-system-arm -M mps3-an547 -m 2G -nographic -kernel nuttx.bin \
-gdb tcp::1127 -device loader,file=../romfs.img,addr=0x60000000
nsh> boot /etc/boot
ap> ostest
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
the detailed warning info:
ccarm: Warning: Unknown option "-Wno-cpp" ignored. Did you mean "--nocpp"?
ccarm: Warning: Unknown option "-pipe" passed to linker
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
Summary
MPS-521 support Dual Cortex-M33 and maybe suitable for AMP-like
case which is for AUTO OS, the change
1. add support for single core at msp-521 with nsh bringup
2. testing with ostest
TODO:
Dual core support for flat-build
Dual CORE support for Protected Build
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Signed-off-by: ligd <liguiding1@xiaomi.com>
Summary
1. add Protected build Support for ARM MPS AN500
2. refine mps Memory layout configure and enable MPU support
Note
1. ostest for an547:nsh
2. ostest for an500:nsh and an500:knsh
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
Signed-off-by: ligd <liguiding1@xiaomi.com>
(1) Keep the `.init_array` and `.ctors` symbols and sort them according to their initialization priority.
(2) Exclude symbols ending with crtend.* and crtbegin.* to support c++
application.if we not exclude crtend.* crtbegin.* frame_dummy will be
added when enable any c++ application with global variables, this symbol
execution is problematic, removing it does not affect the application.
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
