Skip to content

Zephyr-embARC_MLI internal review - #2

Open
SiyuanCheng-CN wants to merge 6 commits into
siyuan-embarc_mli_v2.0-base_tempofrom
siyuan-embarc_mli_v2.0
Open

Zephyr-embARC_MLI internal review#2
SiyuanCheng-CN wants to merge 6 commits into
siyuan-embarc_mli_v2.0-base_tempofrom
siyuan-embarc_mli_v2.0

Conversation

@SiyuanCheng-CN

Copy link
Copy Markdown

No description provided.

@ruuddw

ruuddw commented Jun 23, 2022

Copy link
Copy Markdown
Member

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?

@SiyuanCheng-CN

SiyuanCheng-CN commented Jun 24, 2022

Copy link
Copy Markdown
Author

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.
From what I can see now:

  1. The version of embARC_MLI in Tensorflow is v1.1, now the latest version is v2.0. Difference between them is big.
  2. embARC_MLI now support plenty of networks, example in Tensorflow only accelerate one network.
  3. Example in Tensorflow only targets emsdp.
  4. Seems like example can only run in Tensorflow, not in Zephyr.

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.

Siyuan Cheng added 6 commits July 4, 2022 14:18
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>
@SiyuanCheng-CN
SiyuanCheng-CN force-pushed the siyuan-embarc_mli_v2.0 branch from 0055daf to 8d848b2 Compare July 4, 2022 06:26
AFOliveira pushed a commit that referenced this pull request Jul 9, 2025
Add possibility to perform crop on all pipes and compose (downscale) on
pixel pipes (endpoint #1 and endpoint #2).
Rework the code in order to move the downscale control from
the set_fmt into the set_selection (compose).

Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
M-Moawad pushed a commit that referenced this pull request Jun 24, 2026
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>
M-Moawad pushed a commit that referenced this pull request Jul 16, 2026
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants