This patch fixed userspace headers conflict. Architecture-related definition and API should not be exposed to users.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
since bootloader may call modlib functions directly
to load elf firmware without binfmt, dlfcn or module.
BTW, this patch also remove the duplicated selecttion
Signed-off-by: Xiang Xiao <xiaoxiang@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>
maintains the same semantics as Kernel’s module build
and compatible with Kconfiglib implementation.
The problem of kconfiglib not being able to use tri-states is this:
linux is here torvalds/linux@6dd85ff
The module option is extracted from one of the triate three states into a MODULE keyword.
Kconfiglib supports the default implementation of module to be MODULE for compatibility with the linux kernel, and triate degenerates into bool two states
Refer to this code: 061e71f7d7/kconfiglib.py (L4274-L4284)
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
Revert "Parallelize depend file generation"
This reverts commit d5b6ec450f.
parallel depend ddc does not significantly speed up compilation,
intermediately generated .ddc files can cause problems if compilation is interrupted unexpectedly
Signed-off-by: xuxin19 <xuxin19@xiaomi.com>
reason:
1 On different architectures, we can utilize more optimized strategies
to implement up_current_regs/up_set_current_regs.
eg. use interrupt registersor percpu registers.
code size
before
text data bss dec hex filename
262848 49985 63893 376726 5bf96 nuttx
after
text data bss dec hex filename
262844 49985 63893 376722 5bf92 nuttx
size change -4
Configuring NuttX and compile:
$ ./tools/configure.sh -l qemu-armv8a:nsh_smp
$ make
Running with qemu
$ qemu-system-aarch64 -cpu cortex-a53 -smp 4 -nographic \
-machine virt,virtualization=on,gic-version=3 \
-net none -chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel ./nuttx
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>
(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>
Set sh_addr for regions that are not allocated. Some relocations might
depend on this.
The fault in my case occurs when setting CONFIG_HAVE_CXX=y. In this case,
the .ctor and .dtor sections do not get allocated, but the crt code
depends on linker defined symbols _sctors/_ectors etc. These generate PC
relative relocations and thus, the .ctor and .dtor output sections need
an output VMA even though nothing is there. Otherwise the relocations will
point to god knows where (in my case to address 0).
The problem results in full system crash later:
elf_symvalue: Other: 00000000+00000001=00000001
up_relocateadd: PCREL_HI20 at c00002dc [00000417] to sym=0x80409e80 st_value=1
_calc_imm: offset=-3221226203: hi=-786432 lo=-731
up_relocateadd: ERROR: PCREL_HI20 at c00002dc bad:ffffffff40000000
elf_relocateadd: ERROR: Section 2 reloc 52: Relocation failed: -22
The RISC-V elf64 linker does not like the uninitialized PC relative
relocation entries, as the relocation offset cannot be reached with
with the RV64 instruction set.
More about this issue can be found here:
https://github.com/apache/nuttx/pull/11322
The ELF loader needs to load the app into the memory before
executing it from the same location. As expected, this memory space
should be able to execute code. For architectures containing data
and instruction buses, the instruction bus may not be able to be
accessed in a non-aligned way, which is usually required when
copying data to that location. Eventually, this same memory space
can be accessed through the data bus, using different address
ranges. This commit enables accessing the memory through the data
bus to copy the app's data before executing it when
`CONFIG_ARCH_HAVE_TEXT_HEAP_WORD_ALIGNED_READ` is enabled.
sched implementation not depends on macro abstraction, so revert below commit:
This reverts commit 4e62d0005a
This reverts commit 0f0c370520
This reverts commit ad0efd04ee
Signed-off-by: chao an <anchao@lixiang.com>
As long as the process id reversed between parent and child,
the process member ship will automatically reversed.
Fix Regression by PR #11848:
| commit ec08031e4b
| Author: chao an <anchao@lixiang.com>
| Date: Wed Mar 6 10:13:47 2024 +0800
|
| sched/group: change type of task group member to single queue
|
| Change the type of task group member to single list chain to
| avoid accessing the memory allocator to improve the performance
|
| Signed-off-by: chao an <anchao@lixiang.com>
Signed-off-by: chao an <anchao@lixiang.com>
Change the type of task group member to single list chain to
avoid accessing the memory allocator to improve the performance
Signed-off-by: chao an <anchao@lixiang.com>
Add support for static tcb, applications in some special case can
initialize system resources in advance through static tcb.
| static struct task_tcb_s g_tcb;
|
| memset(&g_tcb, 0, sizeof(struct task_tcb_s));
| g_tcb.cmn.flags = TCB_FLAG_TTYPE_KERNEL;
| nxtask_init(&g_tcb, "PTCB", 101, NULL, 1024, ptcb_task, NULL, NULL, NULL);
|
| ...
| nxtask_activate(&g_tcb.cmn);
Signed-off-by: chao an <anchao@lixiang.com>
this is to adjust levels of a few of them based on debugging
experiences. These non-critical logs were marked as errors. So we
likely can adjust them as warnings so that real errors can
stand out easily.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
There is a problem with the current elf loader for risc-v: when a pair of
PCREL_HI20 / LO12 relocations are encountered, it is assumed that these
will follow each other immediately, as follows:
label:
auipc a0, %pcrel_hi(symbol) // R_RISCV_PCREL_HI20
load/store a0, %pcrel_lo(label)(a0) // R_RISCV_PCREL_LO12_I/S
With this assumption, the hi/lo relocations are both done when a hi20
relocation entry is encountered, first to the current instruction (addr)
and to the next instruction (addr + 4).
However, this assumption is wrong. There is nothing in the elf relocation
specification[1] that mandates this. Thus, the hi/lo relocation always
needs to first fixup the hi-part, and when the lo-part is encountered, it
needs to find the corresponding hi relocation entry, via the given "label".
This necessitates (re-)visiting the relocation entries for the current
section as well as looking for "label" in the symbol table.
The NuttX elf loader does not allow such operations to be done in the
machine specific part, so this patch fixes the relocation issue by
introducing an architecture specific cache for the hi20 relocation and
symbol table entries. When a lo12 relocation is encountered, the cache
can be consulted to find the hi20 part.
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc
The task files should consult the "spawn action" and "O_CLOEXEC flags"
to determine further whether the file should be duplicated.
This PR will further optimize file list duplicating to avoid the performance
regression caused by additional file operations.
Signed-off-by: chao an <anchao@xiaomi.com>
VELAPLATFO-18473
refs:
https://man7.org/linux/man-pages/man2/fcntl.2.html
If the FD_CLOEXEC bit is set, the file descriptor will automatically
be closed during a successful execve(2).
(If the execve(2) fails, the file descriptor is left open.)
modify:
1. Ensure that the child task copies all fds of the parent task,
including those with O_CLOEXE.
2. Make sure spawn_file_action is executed under fd with O_CLOEXEC,
otherwise it will fail.
3. When a new task is activated or exec is called, close all fds
with O_CLOEXEC flags.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Using up_textheap_memalign to allocate memory if arch support textheap
for loading section.
The default system heap does not support execution permissions,
so up_textheap_memalign allocation is required.
this patch can fix issue about #11043
update esp32 elf config:
remove -CONFIG_ARCH_USE_TEXT_HEAP=y becuase ARCH_CHIP_ESP32 select
ARCH_HAVE_TEXT_HEAP
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Handle task spawn attributes as task spawn file actions are handled.
Why? This removes the need for sched_lock() when the task is being
spawned. When loading the new task from a file the scheduler can be
locked for a VERY LONG time, in the order of hundreds of milliseconds!
This is unacceptable for real time operation.
Also fixes a latent bug in exec_module, spawn_file_actions is executed
at a bad location; when CONFIG_ARCH_ADDRENV=y actions will point to the
new process's address environment (as it is temporarily instantiated at
that point). Fix this by moving it to after addrenv_restore.
There is a problem when vfork() calls execv() (or execl()) to start a new application:
When the parent thread calls vfork() it receives and gets the pid of the vforked task,
and not the pid of the desired execv'ed application.
see issue #3334
Signed-off-by: yangyalei <yangyalei@xiaomi.com>
The 'filename' parameter comes from user space and cannot be accessed
after calling ret = addrenv_select(binp->addrenv, &binp->oldenv); as
it changes the address environment and 'filename' points to who knows
where. In this case, calling nxtask_init(filename...) will cause a crash.
Solve this by making a local copy before changing address environment IF
argv = NULL. Why ? Because argv[0] contains the process name in this case
and the argument vector is already copied into kernel memory, thus
passing argv[0] to nxtask_init(argv[0]...) is safe.
Fix the problem when vfork() calls execv() (or execl()) to start a new application:
When the parent thread calls vfork() it receives and gets the pid of the vforked task,
and not the pid of the desired execv'ed application.
issue #3334
Signed-off-by: yangyalei <yangyalei@xiaomi.com>
This option enables architecture-specific memory copy for dynamic code loading.
For example, Ambiq has MRAM regions for instruction which can't load by
the memcpy directly.
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
Load all sections to LMA not VMA, so the startup code(e.g. start.S) need
relocate .data section to the final address(VMA) and zero .bss section by self.
For example, SiFli and Actions: Background: Device with small sram,
Bootloader run in sram and psram, need boot to Application, with memory overlap
and without XIP. VMA of .data is in "psram" and LMA in "rom", if not enable
`ELF_LOADTO_LMA`, ELF loader will load the section to VMA (will fill bootloader
itself).
Signed-off-by: wangjianyu3 <wangjianyu3@xiaomi.com>
ouyangxiangzhen