Firstly call arm_coredump_add_region in up_initialize to add nvic region, then call
coredump_set_memory_region to add board mem region, at this moment, an overlap occurs.
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
Add a custom note for NuttX information including magic and coredump
file data size, so when system reboots, we can check if the block device
contains valid coredump file, and save it to file system.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
elf_emit_tcb_note: nitems(status.pr_regs) is 18, g_tcbinfo.regs_num is 17, then g_tcbinfo.reg_off.p[17] has been out of bounds
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
This commit cleans up redundant header file includes throughout the codebase.
The changes include:
- Removing duplicate #include directives that were present in the same file
- Consolidating includes that were split across multiple lines unnecessarily
- Removing unused includes that were no longer needed
- Fixing some formatting issues with includes
The changes improve code organization and maintainability by:
- Reducing unnecessary dependencies
- Making include dependencies more explicit
- Following consistent include patterns
- Removing dead code
No functional changes are made - this is purely a code cleanup commit.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
reason:
Since assert may synchronously wait to stop another CPU, potentially
leading to a deadlock, we replace enter_critical_section with a
small spinlock to avoid such a situation.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Don't compile dump_assert_info logic if CONFIG_DEBUG_ALERT=n
With _alert() disabled this logic does nothing, but the compiler
is not smart enough to optimize this code.
on minimal stm32f3 configuration it saves 220B of flash.
reason:
When entering an exception or interrupt, there are two sets of registers:
one is the "running regs", which we need to save,
and the other is the "ready to running regs", which we may soon use.
For consistency in logic, we can always store the "running regs" in the regs field of g_running_tasks,
otherwise it may lead to errors in the storage location of the "running regs."
When we need to access the "running regs," we should uniformly retrieve them from the regs field of g_running_tasks.
As the next step, we will rename the set_current_regs/up_current_regs functions
for each architecture to more appropriate names, solely for the purpose of identifying interrupts.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
reason:
The old implementation of the SMP call, even when using the "no wait" parameter,
could still result in waiting, if invoking it within a critical section
may lead to deadlocks. Therefore, in order to implement a truly asynchronous SMP
call strategy, we have added nxsched_smp_call_async.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Don't compile dump_task logic if CONFIG_DEBUG_ALERT=n.
With _alert() disabled this logic does nothing, but the compiler
is not smart enough to optimize this code.
on minimal stm32f3 configuration it saves 396B of flash.
This patch fixed userspace headers conflict. Architecture-related definition and API should not be exposed to users.
Signed-off-by: ouyangxiangzhen <ouyangxiangzhen@xiaomi.com>
smaller than it should be.
0x21000000 0x210105e8 0x210105f8 0x21044000
|----------------|-------------|--------------|
If there is already a range of 0x210105e8 - 0x210105f8, adding another
range of 0x21000000 - 0x21044000 would result in an incorrect range of
0x210105e8 - 0x21044000.
Signed-off-by: wanggang26 <wanggang26@xiaomi.com>
When coredump to mtd, it maybe cost lots of time, do flush syslog can
make user access all log when coredump processing, should be better.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
bug:
thread 1: get mutexA
wait a sem
thread 2: wait mutexA
This situation will be mistakenly judged as a deadlock.
Signed-off-by: anjiahao <anjiahao@xiaomi.com>
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
1. extract dump from assert main flow
2. use OSINIT_PANIC for fatal error.
3. fix the method to judge kernel thread.
Signed-off-by: xuxingliang <xuxingliang@xiaomi.com>
