Zephyr-embARC_MLI internal review - #2
Conversation
|
Thanks, I'll have a closer look later. Quick feedback: for the earlier PR, Zephyr TSC feedback was that they did not like pulling in another MPI copy/module as there already is one. Could you do a comparison between these? Would it e.g. be feasible to merge the ARC MLI changes into that one, or are they too different? |
|
In my understanding, what the TSC said for another ML module is Tensorflow. In Tensorflow, other than generic ML code, it also has some platform-specific library, including embARC_MLI to accelerate some part of kernel functions.
For context switch, it only support non-preemptive switching, without adding DSP registers, it also work. If you want me to add DSP registers in callee-saved register, I can help. |
e31e474 to
0055daf
Compare
Add arc XY mem configuration Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
Add embarc_mli_v2.0 module and linker script Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
add hello_world example to mli module Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
add cifar10 example to mli module Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
add har example to mli module Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
code style update Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
0055daf to
8d848b2
Compare
The syscall call_id is passed to the SVC in r6, but it was declared as an input-only operand and omitted from the clobber list. The SVC handler z_arm_do_syscall() destroys r6 (lsl r6, #2 to index _k_syscall_table[]) and the exception return does not restore it, since Cortex-M hardware only stacks r0-r3/r12/lr/pc/xpsr. Because the asm told the compiler r6 survives the SVC, it was free to hoist the (loop-invariant) call_id load out of a retry loop. GCC happened to rematerialize it before each svc, but Clang hoisted it: on a sys_sem futex retry loop, the second iteration issued the SVC with the already shifted r6 (e.g. 42<<2 = 168), dispatching a bogus, unimplemented syscall and faulting with 'Unimplemented system call'. Declare r6 as a read-write ("+r") operand in every arch_syscall_invokeN so the compiler knows the SVC clobbers it and reloads call_id on each invocation. It cannot be added to the clobber list directly as it is also an operand. Reproduced and verified on mps2/an385 with the LLVM toolchain: tests/kernel/mem_protect/sys_sem (test_sem_take_multiple) now passes, and the GCC build is unaffected. Assisted-by: GitHub Copilot:claude-opus-4.6 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
struct bt_uuid was used for storage instead of struct bt_uuid_any
resulting in overflow when converting BTP UUID to bt_uuid.
==3608402==ERROR: AddressSanitizer: stack-buffer-overflow on address
0xe02f5da2 at pc 0x0805a750 bp 0xe14e2048 sp 0xe14e2038
WRITE of size 2 at 0xe02f5da2 thread T7
#0 0x805a74f in btp2bt_uuid zephyr/tests/bluetooth/tester/src/btp_gatt.c:212
#1 0x805d31c in get_handle_from_uuid zephyr/tests/bluetooth/tester/src/btp_gatt.c:2149
#2 0x804f12c in cmd_handler zephyr/tests/bluetooth/tester/src/btp.c:122
#3 0x807c582 in z_thread_entry zephyr/kernel/sys/thread_entry.c:60
#4 0x807cdd2 in posix_arch_thread_entry zephyr/arch/posix/core/thread.c:124
#5 0x80ff2bd in nct_thread_starter zephyr/scripts/native_simulator//common/src/nct.c:291
#6 0xeb1949a3 in asan_thread_start ../../../../../src/libsanitizer/asan/asan_interceptors.cpp:234
#7 0xeaea5136 (/lib32/libc.so.6+0x8b136) (BuildId: 798ae816ef14b98dc77560340190445fb200634a)
#8 0xeaf39de7 (/lib32/libc.so.6+0x11fde7) (BuildId: 798ae816ef14b98dc77560340190445fb200634a)
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
No description provided.