Wait for CMDDONE in esp32s3_waitresponse even an error response is received.
Otherwise, the CMDDONE event of this command will disrupt later command.
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>
Only in the non-critical region， nuttx can the respond to the irq and not hold the lock
When returning from the irq, there is no need to check whether the lock needs to be released
we also need keep restore_critical_section in svc call
test:
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>
This is the initial version for kernel mode build on the arm64 platform.
It works much in the same way as the risc-v implementation so any
highlights can be read from there.
Features that have been tested working:
- Creating address environments
- Loading init (nsh) from elf file
- Booting to nsh
- Starting other processes from nsh
- ostest runs to completion
Features that are not tested / do not work:
- SHM / shared memory support
- Kernel memory mapping (MM_KMAP)
- fork/vfork
An example qemu target is provided as a separate patch:
tools/configure.sh qemu-armv8a:knsh
Why? Because this allows optimizing the user system call path in such
a way that the parameter registers don't have to be read from the saved
integer register context when the system call is executed.
Some hardware devices use discontinuous framebuffers, which require SIM support for simulating discontinuous framebuffers.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
There is a false positive in asan of gcc-13, we need to mask it to ensure that other parts work properly
sanitizer_common/sanitizer_common_interceptors.inc:
// FIXME: under ASan the call below may write to freed memory and corrupt
// its metadata. See
// https://github.com/google/sanitizers/issues/321.
==572161==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0xed3d3f00 at pc 0xef46af64 bp 0xed3d3de8 sp 0xed3d39bc
WRITE of size 128 at 0xed3d3f00 thread T0
#0 0xef46af63 in __interceptor_pthread_sigmask ../../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4419
#1 0x5486aa7d in up_irq_save sim/posix/sim_hostirq.c:97
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
It can only read the contents of the first buffer, so fblen should be changed to ensure that it can read the second buffer as well.
Signed-off-by: jianglianfang <jianglianfang@xiaomi.com>
armv7-m/arm_mpu.c: In function 'mpu_dump_region':
armv7-m/arm_mpu.c:621:13: warning: format '%X' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
621 | _info("MPU-%d, alignedbase=0%08X l2size=%"PRIu32" SRD=%X"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
armv7-m/arm_mpu.c:621:13: warning: format '%X' expects argument of type 'unsigned int', but argument 6 has type 'long unsigned int' [-Wformat=]
621 | _info("MPU-%d, alignedbase=0%08X l2size=%"PRIu32" SRD=%X"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
armv7-m/arm_mpu.c:621:13: warning: format '%X' expects argument of type 'unsigned int', but argument 7 has type 'long unsigned int' [-Wformat=]
621 | _info("MPU-%d, alignedbase=0%08X l2size=%"PRIu32" SRD=%X"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
armv7-m/arm_mpu.c:621:13: warning: format '%u' expects argument of type 'unsigned int', but argument 8 has type 'long unsigned int' [-Wformat=]
621 | _info("MPU-%d, alignedbase=0%08X l2size=%"PRIu32" SRD=%X"
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
Due to the xtensa mpu feature, the size of the Region depends on the Base of the next Region. e.g.
Region[1] = 0x20000000
Region[0] = 0x30000000
Then Region[1] length = Region[0] - Region[1]
So this approach is not suitable to implement the behavior of cleaning
up the Region and such a configuration will result in affecting the very beginning (the higher) Region
Therefore, to address this feature, in this change we return the Region
value and implement the ability to modify the target Region's attributes
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Modified the input parameters of mpu_initialize to require the caller to provide the number of entries in the table
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Summary:
1.Modify the conditions for entering different include header files
2.Added pre-definition for _Atomic _Bool when it is missing
3.Added nuttx for stdatomic implementation. When toolchain does not support atomic, use lib/stdatomic to implement it
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Summary:
1. Add nuttx/atomic.h in include
2. Use nuttx/atomic.h instead of stdatomic.h in the nuttx directory
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Update internal reference to get the most updated Espressif's
libraries. Those libraries are based on branch `release/v5.1` of
the ESP-IDF and include `v5.1.4` version of it.
sim/posix/sim_alsa.c:728:24: runtime error: member
access within null pointer of type 'const struct sim_codec_ops_s'
Signed-off-by: jinxiuxu <jinxiuxu@xiaomi.com>
In a multicore task scenario, there may be a situation where the task runs on different cores at different time slices (when the task is not bound to a particular core).
When the task calls cache clean/flush(range > cache size), depending on the optimization, clean_all, flush_all are called. however, at this point, there may be dirty data or incomplete data profiles in the cache on the kernel that is running the task, which may result in dirty data being flushed into memory or make the application think that the flushed data should be successfully flushed into memory, leading to unknown consequences.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
In a multicore task scenario, there may be a situation where the task runs on different cores at different time slices (when the task is not bound to a particular core).
When the task calls cache clean/flush(range > cache size), depending on the optimization, clean_all, flush_all are called. however, at this point, there may be dirty data or incomplete data profiles in the cache on the kernel that is running the task, which may result in dirty data being flushed into memory or make the application think that the flushed data should be successfully flushed into memory, leading to unknown consequences.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
