Summary:
This commit removes the riscv_mhartid function and replaces all its
usages with up_cpu_index. The functionality is consolidated into
up_cpu_index which provides a more consistent API for getting the
current CPU/hart ID across different execution modes (machine/supervisor).
Impact:
- Removes riscv_mhartid.S and its references from build systems
- Updates all arch-specific code to use up_cpu_index instead
- Adds more detailed documentation for up_cpu_index behavior
- Changes the implementation of up_cpu_index to use percpu scratch
register in supervisor mode
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Summary:
- Separated CPU index functionality from CPU ID mapping configuration
- Moved CPU ID mapping functions to new riscv_cpuidmap.c file
- Made up_cpu_index() implementation dependent on ARCH_USE_S_MODE
- Updated build system to handle new file organization
Impact:
- Improves code organization by separating concerns between basic CPU index
functionality and advanced CPU ID mapping features
- Makes CPU index functionality available independently of CPU ID mapping
- Reduces conditional compilation complexity in header files
- Better aligns with RISC-V architecture modes (M-mode vs S-mode)
Testing:
GitHub CI and local testing
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
This would fix readv/writev issues mentioned in
https://github.com/apache/nuttx/pull/12674.
(only for this specific driver though. with this approach,
we basically have to fix every single drivers and
filesystems.)
Lightly tested on the serial console, using micropython REPL
on toywasm with esp32s3-devkit:toywasm, which used to be
suffered by the readv issue.
* Make readv/writev implementations update struct uio
This can simplify partial result handling.
* change the error number on the overflow from EOVERFLOW to EINVAL
to match NetBSD
* add a commented out uio_offset field. I used "#if 0" here as
C comments can't nest.
* add a few helper functions
Note on uio_copyfrom/uio_copyto:
although i'm not quite happy with the "offset" functionality,
it's necessary to simplify the adaptation of some drivers like
drivers/serial/serial.c, which (ab)uses the user-supplied buffer
as a line-buffer.
arch/risc-v/src/common/riscv_addrenv.c:418:
{
...
database = resvbase + MM_PGALIGNUP(resvsize);
...
}
need use MM_PGALIGNUP(resvsize) inside of ARCH_DATA_RESERVE_SIZE
if not add MM_PGALIGNUP(resvsize), will mismatch address load .data
section
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Sumamry:
Adjust VIRT_FLASH_PSECTION from 0x00000000-0x08000000 -> 0x00600000-0x08000000
The above changes avoid the problem of directly restarting when the process accesses/executes at address 0x0 without causing assert
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
It will be used to distinguish between hardware KASan and software KASan. Hardware KASan does not need to use plug-in
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
reason:
In AMP mode, we can also use SGI as an inter-core interrupt,
and ensure that arm_gic0_initialize is called only once.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
arm/qemu-v7a:
1. Keep arm/smp configuration, use kasan in generic mode
arm64/qemu-v8a:
1. Keep arm/citest configuration, use kasan in generic mode
2. Keep arm/swtags configuration, use kasan in software tag mode
sim:
1. Keep sim/ostest, use asan
2. Keep sim/ostest_oneholder, use kasan in generic mode
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>
When assembly code calls a C function, it needs to save the context. After enabling KASAN, the inserted __asan_load8_noabort function uses the rsi register, causing the value of rsi in the interrupt handler to be modified, which results in an incorrect interrupt number.
Signed-off-by: liwenxiang1 <liwenxiang1@xiaomi.com>
This guards use of `-r` in LDELFFLAGS in risc-v common/Toolchain.defs so
that it is only used when BINFMT_ELF_RELOCATABLE is selected.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
Add support for watchdog timer notifer chain so that users
can customize the callback function when the watchdog timer
times out which enabled by Auto-monitor
Signed-off-by: yaojiaqi <yaojiaqi@lixiang.com>
If thread 1 is executing kasan_unpoison but a scheduling occurs and the block is trampled upon, the displayed backtracking may still be from the previously allocated backtracking
Signed-off-by: wangmingrong1 <wangmingrong1@xiaomi.com>