Some USB controllers can receive or send multiple data packets then
generate one interrupt. This mechanism can reduce the number of data
copies. Extend req buf to accommodate this.
Signed-off-by: yangsong8 <yangsong8@xiaomi.com>
This PR configures the BL808 MMU to cache the the User Text, Data and Heap. We enable the T-Head MMU Flags for Shareable, Bufferable and Cacheable, as explained in the previous PR: https://github.com/apache/nuttx/pull/13199
This PR fixes the Slow Memory Access for NuttX Apps on Ox64 BL808 SBC: https://github.com/apache/nuttx/issues/12696. With this fix, Ox64 NuttX CoreMark jumps from 19 to 1,104. (Close to Buildroot Linux CoreMark)
Modified Files:
`arch/risc-v/Kconfig`: Enabled `ARCH_MMU_EXT_THEAD` for BL808 SoC.
In protected build mode, the syscall returns without setting correct value for the CONTROL register, which causes the userspace threads working in privileged mode after syscall.
Signed-off-by: pangzhen1 <pangzhen1@xiaomi.com>
This PR configures the T-Head MMU to cache the the User Text, Data and Heap. We enable the MMU Flags for Shareable, Bufferable and Cacheable, as explained in this article: https://lupyuen.github.io/articles/plic3#appendix-mmu-caching-for-t-head-c906
This PR fixes the Slow Memory Access for NuttX Apps on BL808 and SG2000 SoCs: https://github.com/apache/nuttx/issues/12696. With this fix, SG2000 NuttX CoreMark jumps from 21 to 2,423. (Close to SG2000 Debian CoreMark)
We introduce a Kconfig Option: `ARCH_MMU_EXT_THEAD` ("System Type > Enable T-Head MMU extension support"). Enabling this Kconfig Option will configure the T-Head MMU to cache the User Text, Data and Heap.
This PR enables the MMU cache for only SG2000 SoC (Milk-V Duo S SBC). The next PR will apply the same settings to BL808 SoC (Pine64 Ox64 SBC).
Modified Files:
`arch/risc-v/Kconfig`: Added Kconfig Option `ARCH_MMU_EXT_THEAD` that will configure the T-Head MMU. Enabled `ARCH_MMU_EXT_THEAD` for SG2000 SoC.
`arch/risc-v/src/common/riscv_mmu.h`: Set the T-Head MMU Flags (Shareable, Bufferable and Cacheable) for User Text, Data and Heap, if `ARCH_MMU_EXT_THEAD` is enabled
`arch/risc-v/src/common/riscv_addrenv.c`: Extended the MMU Flags from 32 bits to 64 bits, to accommodate the T-Head MMU Flags
`arch/risc-v/src/common/riscv_exception.c`: Extended the MMU Flags from 32 bits to 64 bit, to accommodate the T-Head MMU Flags. This code is enabled only for MMU Paging (`CONFIG_PAGING`).
Currently concerns only arm.
tools/ci/testlist/msys2.dat:
At the moment I only added the board nucleo-l152re:nsh
.github/workflows/build.yml:
Enabled cmake for msys2
since not all Armv7-m platform support double-precision floating
operations, so we add an extra option that help those specific platform
could define the single-precision floating operations.
for example, qemu-mps platform(armv7-m) support double-precision
floating operations, so we do not need to open
CONFIG_ARM_FPU_SINGLE_HARDWARE build options;
but for fc7300 platform(armv7-m) only support single-precision floating
operations, so if we pass "-fhard" build option to "ghs" compiler, then
the following instruction will be generated:
vcvt.f64.s32 d9, s18
which will fail to execute on fc7300 platform.
with "-fsingle" build option, the "ghs" compiler will generate hardware
instruction for single-precision floating operation, and generate
software instruction for double-precision floating operation.
Signed-off-by: guoshichao <guoshichao@xiaomi.com>
To support greenhill compilation, LDFLAGS removes the code that adds -T through addprefix to ARCHSCRIPT(greenhill requires a space between -T and ldscript files, but addprefix didn't do it). However,if we modified like this, when ARCHSCRIPT has more than one ldscript, the -T is only added to the first ldscript, but not to the following ldscripts, which results in a warning when linking.
To solve this problem, we can just add a space after $(SCRIPT_OPT) when using addprefix, instead of deleting addprefix.
Signed-off-by: pangzhen1 <pangzhen1@xiaomi.com>
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>
