Interesting research on ESP32 and STM32 :-)
https://github.com/elttam/boot-security-in-the-mcu/blob/main/Boot_security_in_the_MCU_v1-0.pdf
https://www.youtube.com/watch?v=LXdSVcvhJuI
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Here is an interesting OS, an implementation of AutosarOS based on the
Nuttx kernel, which seems to follow the OSEK OS standard:
HaloOS:
https://gitee.com/haloos
NuttX Kernel:
https://gitee.com/haloos/vcos_kernel_nuttx
AutosarOS(OSEK) based on NuttX Kernel:
https://gitee.com/haloos/vcos_compone
Yes, I understood that, what if CPU A and CPU B enters the unlock routine with
1 lockcount on the same task and after the decrement they both go into
preemption and manipulating with linked list task list?
On April 24, 2025 8:06:36 AM UTC, hujun260 wrote:
>The lockcount can be understood as a l
Oh something to add;
The serial output is typically messed up (usually when "help" is ran, or
printf use). I tried to debug it, but the debugger "gives up / skips" on
random instructions. Or fails to write variables.
People seem to have accepted this behavior as normal, but I am very worried
about
Hi,
I am just going to share this here too.
I experienced ostest fails both on RP2040 and RP2350.
Disabling SMP on RP2350 only moved the problem elsewhere.
It stopped the ostest fails for a bit, but when adding more applications
and threads, the issue comes back.
Sometimes it hangs, rarely it halt
The lockcount can be understood as a local variable, so no race conditions will
occur.
编辑
分享
At 2025-04-24 15:54:48, "Serg Podtynnyi" wrote:
>Hi, I tried my best to understand the logic behind unlock and
>merge_pending routines and come up with this fix that works for me.
>I spl
Hi, I tried my best to understand the logic behind unlock and
merge_pending routines and come up with this fix that works for me.
I split the lockcount handling in 2 parts when lockcount is > 1 just
decrement fast as always,
but when it's 1 we enter critical section and make it 0 inside
it(pre-e
