According to the current design on the armv7-a platform,
only fiq is processed in TEE, while irq and fiq are processed
in REE.
If we enable the irq function in TEE, when we process
some signal-related scenarios in TEE,
such as the ostest sighand testcase, this testcase will
call up_irq_enable() to enable irq interrupt in the
arm_sigdeliver() function. After the signal processing
logic is executed, irq will be disabled again.
During the interval of enabling irq, some external device
irq interrupts will be enabled, but these external device
irqs do not have corresponding handlers registered in TEE,
so an "unexpected irq isr exception" will be triggered.
Therefore, a better implementation is to keep the original
implementation of the up_irq_enable() function, that is,
to enable only fiq in TEE and to enable irq and fiq in REE.
Then for vendor-specific requirements, such as the need to
briefly enable irq during the TEE initialization process
and then disable irq before starting APz in TEE, we directly
provide a separate implementation of enabling irq in the
vendor, without modifying the implementation of the public
up_enable_irq() function.
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
==263401==ERROR: AddressSanitizer: stack-use-after-return on address 0xf515f260 at pc 0x042434f0 bp 0x9ac24e78 sp 0x9ac24e68
WRITE of size 4 at 0xf515f260 thread T0
#0 0x42434ef in nxsem_get_value semaphore/sem_getvalue.c:65
#1 0x413110d in work_thread wqueue/kwork_thread.c:195
#2 0x412c4f6 in nxtask_start task/task_start.c:129
#3 0x427b1fc in pre_start sim/sim_initialstate.c:52
Address 0xf515f260 is located in stack of thread T0 at offset 32 in frame
#0 0x928c9e3 in host_settimer sim/posix/sim_hosttime.c:104
This frame has 1 object(s):
[32, 48) 'it' (line 105) <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
Signed-off-by: cuiziwei <cuiziwei@xiaomi.com>
arch/xtensa/src/esp32s3/hardware/esp32s3_sdmmc.h|esp32s3_soc.h,
boards/xtensa/esp32s3/common/include/esp32s3_board_sdmmc.h,
boards/xtensa/esp32s3/common/src/Make.defs|esp32s3_board_sdmmc.c,
boards/xtensa/esp32s3/esp32s3-devkit/src/esp32s3_bringup.c: add SD/mmc driver
Support 1-bit bus width and 4-bit bus width. Support eMMC high speed SDR mode.
Support transfer data with DMA. Support SD clock frequency up to 40MHZ.
Signed-off-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Tested-by: Yinzhe Wu <Yinzhe.Wu@sony.com>
CC: unistd/lib_setregid.c "/mnt/yang/qixinwei_vela_warnings_04_23/nuttx/include/nuttx/irq.h", line 53: warning #193-D:
zero used for undefined preprocessing identifier "NR_IRQS"
# if NR_IRQS <= 256
^
"/mnt/yang/qixinwei_vela_warnings_04_23/nuttx/include/nuttx/irq.h", line 82: warning #193-D:
zero used for undefined preprocessing identifier "NR_IRQS"
#if NR_IRQS <= 256
CC: mount/fs_umount2.c "/mnt/yang/qixinwei_vela_warnings_04_23/nuttx/include/nuttx/irq.h", line 72: warning #193-D:
zero used for undefined preprocessing identifier "NR_IRQS"
#if NR_IRQS <= 256
Signed-off-by: yanghuatao <yanghuatao@xiaomi.com>
the greenhills compiler provide its own implementation of va_start,
va_end, va_arg, va_copy. so if we are build vela with greenhills
compiler, we should using the stdarg implementation provided by
greenhills, not our own
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
Enabling CONFIG_PRIORITY_INHERITANCE config causes a build error
Based on Nuttx OS reserve memory for mutex struct.
Pass build based on
- CONFIG_PRIORITY_INHERITANCE y
- CONFIG_SEM_PREALLOCHOLDERS 0/8
Pass CP15_CACHE_INVALIDATE argument with r1 register to cp15_dcache_op_level.
cache level is 0(L1 D-Cache) with r0 register.
prototype:
void cp15_dcache_op_level(uint32_t level, int op)
Signed-off-by: Jinliang Li <lijinliang1@lixiang.com>
"/mnt/yang/qixinwei_vela_warnings/nuttx/include/nuttx/spinlock.h", line 252: warning #76-D:
argument to macro is empty
SP_DSB();
^
"/mnt/yang/qixinwei_vela_warnings/nuttx/include/nuttx/spinlock.h", line 261: warning #76-D:
argument to macro is empty
SP_DMB();
^
"/mnt/yang/qixinwei_vela_warnings/nuttx/include/nuttx/spinlock.h", line 252: warning #76-D:
argument to macro is empty
SP_DSB();
^
"/mnt/yang/qixinwei_vela_warnings/nuttx/include/nuttx/spinlock.h", line 261: warning #76-D:
argument to macro is empty
SP_DMB();
^
"/mnt/yang/qixinwei_vela_warnings/nuttx/include/nuttx/spinlock.h", line 296: warning #76-D:
argument to macro is empty
SP_DSB();
^
Signed-off-by: yanghuatao <yanghuatao@xiaomi.com>
according to armv6-m/armv7-m arch reference manual:
the three ISB {<opt>}, DSB {<opt>}, DMB {<opt>} instructions <opt>
field are defined as:
Specifies an optional limitation on the ISB/DSB/DMB operation. Allowered
values are:
Full system ISB/DSB/DMB operation, encoded as option=='1111'. Can be
omitted.
All other encodings of the options are RESERVED.
the "#opt" field of "isb #opt"
So we could remove the options field in Armv7-m platform.
The following are the build error with greenhills compiler:
CC: common/arm_exit.c [asarm] (error #2071) /tmp/gh_001h70j1.si 92: bad parameter
isb 15
------^
[asarm] (error #2071) /tmp/gh_001h70j1.si 112: bad parameter
isb 15
------^
[asarm] (error) errors during processing
According to armv8-m arch reference manual:
the ISB/DMB instruction's "opt" encoding rule is same as
armv6-m/armv7-m, but the "DSB" instruction is different, in armv8-m, the
"DSB {<opt>}" field has two valid encoding options: 0b0000, 0b0100.
and all other encoding options are reserved.
In Armv7-a/Armv8-a, the dsb/dmb option field has 8 valid state value.
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
The following are the compile error that reported
by GreenHills compiler:
"/mnt/yang/qixinwei_commit/nuttx/include/arch/syscall.h", line 156 (col. 17): error #2036-D:
cannot allocate "reg0" to specified caller-saved register
"/mnt/yang/qixinwei_commit/nuttx/include/arch/syscall.h", line 157 (col. 17): error #2036-D:
cannot allocate "reg1" to specified caller-saved register
Then we fix this greenhills compilation error by explicitly specifying
the registers in the clobber list in the inline assembly code.
This fix is successful in compiling on the
nuttx/boards/arm/mps/mps2-an500/configs/nsh platform and passes
the ostest test.
However, if we keep the implementation the same for both the default
and Greenhills compilers, the default compiler will report the
following two issues:
1. the "sys_call6" function will report compile error when
compiling on "./vendor/qemu/boards/smartspeaker/configs/smartspeaker-knsh"
platform, the detailed error info:
CC: proxies/PROXY_mq_getattr.c In file included from /home/guoshichao/work_profile/vela_os/vela_qemu_1/nuttx/include/sys/syscall.h:35,
from /home/guoshichao/work_profile/vela_os/vela_qemu_1/nuttx/include/syscall.h:30,
from proxies/PROXY_mmap.c:5:
In function 'sys_call6',
inlined from 'mmap' at proxies/PROXY_mmap.c:9:22:
/home/guoshichao/work_profile/vela_os/vela_qemu_1/nuttx/include/arch/syscall.h:297:3: error: 'asm' operand has impossible constraints
297 | __asm__ __volatile__
| ^~~~~~~
2. when running on qemu-armv7-a platform, the modification to
"smh_call()" function will make the system fail to boot up, so
we need to keep the default compiler implementation and greenhills
compiler implementation separate
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
(cherry picked from commit cb48b749b1c9cad8cfb96bff7c5e9b6ebf20fc8a)
Some multicore RV chips (mpfs, jh7110 etc) have hart clusters
and globally numbered mhartids. Clusters with single hart or
SMP support can be managed by one NuttX instance. Currently
NuttX expects to use cluster-local ids.
This allows us to get local ids by offsetting mhartids with a
base value.
Note that there are chips (e.g. k230) that use cluster-local
ids directly, so this is not needed for them.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
1. For some reasons, the bootloader will set CPU source to BBPLL and enable it,
but there are calibration issues, so we need turn off the BBPLL and do calibration again to fix the issue.
2. Corresponding issue link: 89cc9084ab
Signed-off-by: chenwen@espressif.com <chenwen@espressif.com>
This generalizes the in-kernel syscall approach from KERNEL mode to
all build modes so that to unify in-kernel syscall invocations. As
a result, machine mode ECALL and the supervisor folder are no longer
needed.
Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>
This commit adds missing add_link_options to specify sanitizers
also during linking stage.
Signed-off-by: Daniel Jasinski <jasinskidaniel95szcz@gmail.com>
When executing fork() via a system call, the parent's stack gets corrupted
by the child, as during exception return the child loads the parent's
stack pointer from the context save area.
This happens because the full parent stack (including what has been pushed
during the system call) is copied to the child. What should be copied, is
only the user stack of the parent (the kernel stack is not interesting).
Fix this by only copying the parent's user stack to the child; and make
the child return directly to userspace (not via dispatch_syscall).
Simplifies the implementation of dispatch_syscall, making it easier to
understand and maintain. Let the C-compiler do most of the work, instead
of doing everything as inline assembly.
