During the boot phase, when we transition from tee smp to ap smp, we can use a busy waitflag to wait for the completion of the initialization of ap's core0
test:
We can use qemu for testing.
compiling
make distclean -j20; ./tools/configure.sh -l qemu-armv8a:nsh_smp ;make -j20
running
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>
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 restored
test:
We can use qemu for testing.
compiling
make distclean -j20; ./tools/configure.sh -l qemu-armv8a:nsh_smp ;make -j20
running
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>
cpu0 cpu1:
user_main
signest_test
sched_unlock
nxsched_merge_pending
nxsched_add_readytorun
up_cpu_pause
arm_sigdeliver
enter_critical_section
Reason:
In the SMP, cpu0 is already in the critical section and waiting for cpu1 to enter the suspended state.
However, when cpu1 executes arm_sigdeliver, it is in the irq-disabled state but not in the critical section.
At this point, cpu1 is unable to respond to interrupts and
is continuously attempting to enter the critical section, resulting in a deadlock.
Resolve:
adjust the logic, do not entering the critical section when interrupt-disabled.
test:
We can use qemu for testing.
compiling
make distclean -j20; ./tools/configure.sh -l qemu-armv8a:nsh_smp ;make -j20
running
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>
Purpose: make the the os crash when busyloop with interrupt disable
Follow the arm gicv2 spec, if we want to use the IRQ and FIQ
simultaneously when not using the processor Security Externsions.
We should:
1. IRQ to Group 1 and FIQ to Group 0;
2. Set CICC_CTLR.FIQEn to 1;
Then in NuttX:
1. implement the arm_decodefiq and directly crash in it;
2. provide interface to change the IRQ to FIQ, e.g. change the
watchdog IRQ to FIQ, so the watchdog can trigger even with the
interrupt disabled (up_irq_save() called);
Signed-off-by: wangbowen6 <wangbowen6@xiaomi.com>
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Signed-off-by: ligd <liguiding1@xiaomi.com>
cpu0 thread0: cpu1:
sched_yield()
nxsched_set_priority()
nxsched_running_setpriority()
nxsched_reprioritize_rtr()
nxsched_add_readytorun()
up_cpu_pause()
IRQ enter
arm64_pause_handler()
enter_critical_section() begin
up_cpu_paused() pick thread0
arm64_restorestate() set thread0 tcb->xcp.regs to CURRENT_REGS
up_switch_context()
thread0 -> thread1
arm64_syscall()
case SYS_switch_context
change thread0 tcb->xcp.regs
restore_critical_section()
enter_critical_section() done
leave_critical_section()
IRQ leave with restore CURRENT_REGS
ERROR !!!
Reason:
As descript above, cpu0 swith task: thread0 -> thread1, and the
syscall() execute slowly, this time cpu1 pick thread0 to run at
up_cpu_paused(). Then cpu0 syscall execute, cpu1 IRQ leave error.
Resolve:
Move arm64_restorestate() after enter_critical_section() done
This is a continued fix with:
https://github.com/apache/nuttx/pull/6833
Signed-off-by: ligd <liguiding1@xiaomi.com>
Adding the CONFIG_ARCH_PERF_EVENTS configuration to enable
hardware performance counting，solve the problem that some platform
hardware counting support is not perfect, you can choose to use
software interface.
This is configured using CONFIG_ARCH_PERF_EVENTS, so weak_functions
are removed to prevent confusion
To use hardware performance counting, must:
1. Configure CONFIG_ARCH_PERF_EVENTS, default selection
2. Call up_perf_init for initialization
Signed-off-by: wangming9 <wangming9@xiaomi.com>
We can use the driver in nuttx to download
files with debugger
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Signed-off-by: chao an <anchao@xiaomi.com>
When supporting high-priority interrupts, updating the
g_running_tasks within a high-priority interrupt may be
cause problems. The g_running_tasks should only be updated
when it is determined that a task context switch has occurred.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
According to the ARMv7a/r/m and ARMv8m architecture manuals
The allowed values are
0 Data or unified cache.
1 Instruction cache.
"One CCSIDR is implemented for each cache that can be accessed by the processor. CSSELR selects which Cache Size ID Register is accessible, see c0, Cache Size Selection Register (CSSELR)."
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
to avoid the infinite recusive dispatch:
*0 myhandler (signo=27, info=0xf3e38b9c, context=0x0) at ltp/testcases/open_posix_testsuite/conformance/interfaces/sigqueue/7-1.c:39
*1 0x58f1c39e in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:167
*2 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*3 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049334) at signal/sig_dispatch.c:115
*4 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049334) at signal/sig_dispatch.c:435
*5 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*6 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*7 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*8 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049304) at signal/sig_dispatch.c:115
*9 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049304) at signal/sig_dispatch.c:435
*10 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*11 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*12 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*13 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf40492d4) at signal/sig_dispatch.c:115
*14 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf40492d4) at signal/sig_dispatch.c:435
*15 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*16 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*17 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*18 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf40492a4) at signal/sig_dispatch.c:115
*19 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf40492a4) at signal/sig_dispatch.c:435
*20 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*21 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*22 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*23 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049274) at signal/sig_dispatch.c:115
*24 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049274) at signal/sig_dispatch.c:435
*25 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*26 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
*27 0x58fa0664 in up_schedule_sigaction (tcb=0xf4e20f40, sigdeliver=0x58f1bab5 <nxsig_deliver>) at sim/sim_schedulesigaction.c:88
*28 0x58f19907 in nxsig_queue_action (stcb=0xf4e20f40, info=0xf4049244) at signal/sig_dispatch.c:115
*29 0x58f1b089 in nxsig_tcbdispatch (stcb=0xf4e20f40, info=0xf4049244) at signal/sig_dispatch.c:435
*30 0x58f31853 in nxsig_unmask_pendingsignal () at signal/sig_unmaskpendingsignal.c:104
*31 0x58f1ca09 in nxsig_deliver (stcb=0xf4e20f40) at signal/sig_deliver.c:199
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
in SMP, signal processing cannot be nested, we use xcp.sigdeliver to identify whether there is currently a signal being processed, but this state does not match the actual situation
One possible scenario is that signal processing has already been completed, but an interrupt occurs, resulting in xcp.sigdeliver not being correctly set to NULL,
At this point, a new signal arrives, which can only be placed in the queue and cannot be processed immediately
Our solution is that signal processing and signal complete status are set in the same critical section, which can ensure status synchronization
Signed-off-by: hujun5 <hujun5@xiaomi.com>
CURRENT_REGS may change during assert handling, so pass
in the 'regs' parameter at the entry point of _assert.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
