arch/xtensa: use arch atomic when enable iram heap #14805

zyfeier · 2024-11-15T06:24:23Z

Summary

This PR fixed EPS32 issue after enable #14465
Use arch atomic when enable iram heap.
S32C1I instructions may target cached, cache-bypass, and data RAM memory locations. S32C1I instructions are not permitted to access memory addresses in data ROM, instruction memory or the address region allocated to the XLMI port. Attempts to direct the S32C1I at these addresses will cause an exception.

Impact

ESP32 iram heap

Testing

esp32-devkit:sotest boot success

arch/xtensa/src/lx6/Toolchain.defs

nuttxpr · 2024-11-15T07:53:02Z

[Experimental Bot, please feedback here]

This PR appears to mostly meet the NuttX requirements, but is missing some key information.

Missing/Needs Improvement:

Summary: While the summary explains the "why" (fixing an issue introduced by another PR), it lacks clarity on the "what" and "how." Be more specific about which functional part of the code is changed (e.g., memory allocation, heap management, atomic operations). Explain precisely how the use of arch atomics resolves the issue with S32C1I instructions and the iram heap.
Impact: The impact section is too brief. While it mentions the ESP32 iram heap, it doesn't explicitly answer the required questions (user impact, build impact, hardware impact, documentation, security, compatibility). Even if the answer is "NO" for most, it should be stated explicitly. For example:
- Impact on user: NO
- Impact on build: NO
- Impact on hardware: YES (affects ESP32 using iram heap)
- Impact on documentation: NO/YES (Specify if documentation needs updating or if you've updated it).
- Impact on security: NO/YES (Consider potential implications of changing atomic operations).
- Impact on compatibility: NO/YES
Testing: While you mention a successful boot, this isn't sufficient. Provide more details:
- Build Host: Specify your build host OS, CPU architecture, and compiler version.
- Target: You mentioned esp32-devkit:sotest. Be more explicit about the ESP32 chip variant and the NuttX configuration used (e.g., esp32-devkitc:nsh).
- Logs: "boot success" is not a log. Show relevant log output before and after the change. Demonstrate that the issue existed before and is resolved after. Ideally, the logs should show the specific error that occurred before the fix and its absence afterward. If sotest was used, provide the sotest output.

Example of Improved Impact Section:

## Impact

* Is new feature added? NO
* Is existing feature changed? YES (Fixes iram heap functionality on ESP32)
* Impact on user: NO (Users should see corrected behavior with iram heap).
* Impact on build: NO
* Impact on hardware: YES (Specifically affects ESP32 architectures using the iram heap).
* Impact on documentation: NO (No documentation updates required/provided).
* Impact on security: NO (No known security implications).
* Impact on compatibility: NO (No compatibility issues expected).
* Anything else to consider: NO

By providing more complete information in these sections, the PR will be much easier to review and merge.

yamt · 2024-11-15T07:59:09Z

arch/xtensa/src/esp32/Kconfig

@@ -859,6 +859,7 @@ config ESP32_RTC_HEAP
 config ESP32_IRAM_HEAP
 	bool "Use the rest of IRAM as a separate heap"
 	select ARCH_HAVE_EXTRA_HEAPS
+	select LIBC_ARCH_ATOMIC


LIBC_ARCH_ATOMIC has been removed while ago. am i missing something?

Was add in this PR #14803

Shouldn't it be enabled for ESP32-S2 and ESP32-S3 too?

ESP32-S2 and ESP32-S3 do not support IRAM HEAP, so there is no need

tmedicci · 2024-11-18T12:00:43Z

Hi @zyfeier , I'll test on our internal CI, thanks!

tmedicci · 2024-11-18T13:08:12Z

Hi @zyfeier , I still couldn't make it work for esp32-devkit:sotest:

*** Booting NuttX ***
I (27) boot: chip revision: v3.0
I (28) boot.esp32: SPI Speed      : 40MHz
I (28) boot.esp32: SPI Mode       : DIO
I (29) boot.esp32: SPI Flash Size : 4MB
I (33) boot: Enabling RNG early entropy source...
dram: lma 0x00001020 vma 0x3ffb20a0 len 0x1024   (4132)
iram: lma 0x0000204c vma 0x40080000 len 0x6000   (24576)
padd: lma 0x00008058 vma 0x00000000 len 0x7fa0   (32672)
imap: lma 0x00010000 vma 0x400e0000 len 0x179b4  (96692)
padd: lma 0x000279bc vma 0x00000000 len 0x865c   (34396)
dmap: lma 0x00030020 vma 0x3f400020 len 0x7f60   (32608)
total segments stored 6
A__esp32_start: ESP32 chip revision is v3.0
Bxtensa_user_panic: User Exception: EXCCAUSE=0003 task: Idle_Task
dump_assert_info: Current Version: NuttX  10.4.0 74610b03bf Nov 18 2024 10:03:19 xtensa
dump_assert_info: Assertion failed user panic: at file: common/xtensa_assert.c:180 task: Idle_Task process: Kernel 0x4
up_dump_register:    PC: 400f0b35    PS: 00060d30
up_dump_register:    A0: 800e3949    A1: 3ffb0af0    A2: 40086000    A3: 00040000
up_dump_register:    A4: 00040000    A5: 40086000    A6: 00040001    A7: 00040001
up_dump_register:    A8: 00000000    A9: ffff0000   A10: 00000001   A11: 00000000
up_dump_register:   A12: 3ffb0cc4   A13: 00000000   A14: 00000000   A15: 00000001
up_dump_register:   SAR: 00000020 CAUSE: 00000003 VADDR: 40086000
up_dump_register:  LBEG: 400e4f6c  LEND: 400e4f79  LCNT: 00000000
dump_stacks: ERROR: Stack pointer is not within the stack
dump_stackinfo: User Stack:
dump_stackinfo:   base: 0
dump_stackinfo:   size: 00000000
stack_dump: 0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dump_tasks:    PID GROUP PRI POLICY   TYPE    NPX STATE   EVENT      SIGMASK          
STACKBASE  STACKSIZE   COMMAND

NuttX: 74610b0 (this PR's commit)
NuttX apps: fee82bd3d32e32e6353ce0ab20add8079ea0f0ea

Built/flashed with:

make flash EXTRAFLAGS="-Wno-cpp -Werror" ESPTOOL_BINDIR=./ ESPTOOL_PORT=/dev/ttyUSB1 -s -j$(nproc) && minicom -D /dev/ttyUSB1

Compiler's version:
xtensa-esp32-elf-gcc (crosstool-NG esp-12.2.0_20230208) 12.2.0

nuttx.zip

Anything Am I missing here?

zyfeier · 2024-11-18T13:21:34Z

Hi @zyfeier , I still couldn't make it work for esp32-devkit:sotest:

*** Booting NuttX ***
I (27) boot: chip revision: v3.0
I (28) boot.esp32: SPI Speed      : 40MHz
I (28) boot.esp32: SPI Mode       : DIO
I (29) boot.esp32: SPI Flash Size : 4MB
I (33) boot: Enabling RNG early entropy source...
dram: lma 0x00001020 vma 0x3ffb20a0 len 0x1024   (4132)
iram: lma 0x0000204c vma 0x40080000 len 0x6000   (24576)
padd: lma 0x00008058 vma 0x00000000 len 0x7fa0   (32672)
imap: lma 0x00010000 vma 0x400e0000 len 0x179b4  (96692)
padd: lma 0x000279bc vma 0x00000000 len 0x865c   (34396)
dmap: lma 0x00030020 vma 0x3f400020 len 0x7f60   (32608)
total segments stored 6
A__esp32_start: ESP32 chip revision is v3.0
Bxtensa_user_panic: User Exception: EXCCAUSE=0003 task: Idle_Task
dump_assert_info: Current Version: NuttX  10.4.0 74610b03bf Nov 18 2024 10:03:19 xtensa
dump_assert_info: Assertion failed user panic: at file: common/xtensa_assert.c:180 task: Idle_Task process: Kernel 0x4
up_dump_register:    PC: 400f0b35    PS: 00060d30
up_dump_register:    A0: 800e3949    A1: 3ffb0af0    A2: 40086000    A3: 00040000
up_dump_register:    A4: 00040000    A5: 40086000    A6: 00040001    A7: 00040001
up_dump_register:    A8: 00000000    A9: ffff0000   A10: 00000001   A11: 00000000
up_dump_register:   A12: 3ffb0cc4   A13: 00000000   A14: 00000000   A15: 00000001
up_dump_register:   SAR: 00000020 CAUSE: 00000003 VADDR: 40086000
up_dump_register:  LBEG: 400e4f6c  LEND: 400e4f79  LCNT: 00000000
dump_stacks: ERROR: Stack pointer is not within the stack
dump_stackinfo: User Stack:
dump_stackinfo:   base: 0
dump_stackinfo:   size: 00000000
stack_dump: 0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dump_tasks:    PID GROUP PRI POLICY   TYPE    NPX STATE   EVENT      SIGMASK          
STACKBASE  STACKSIZE   COMMAND

NuttX: 74610b0 (this PR's commit) NuttX apps: fee82bd3d32e32e6353ce0ab20add8079ea0f0ea

Built/flashed with:

make flash EXTRAFLAGS="-Wno-cpp -Werror" ESPTOOL_BINDIR=./ ESPTOOL_PORT=/dev/ttyUSB1 -s -j$(nproc) && minicom -D /dev/ttyUSB1

Compiler's version: xtensa-esp32-elf-gcc (crosstool-NG esp-12.2.0_20230208) 12.2.0

nuttx.zip

Anything Am I missing here?

@tmedicci From the disassembly file, it can be seen that the s32c1i instruction is still used，could you to check if -D__STDC_NO_ATOMICS__ was include in compile flag?

tmedicci · 2024-11-18T17:36:19Z

STDC_NO_ATOMICS

Hi @zyfeier ! Thanks fo your quick response!

In fact, __STDC_NO_ATOMICS__ wasn't being set. I was able to make it work with the following patch:

diff --git a/arch/xtensa/src/lx6/Toolchain.defs b/arch/xtensa/src/lx6/Toolchain.defs
index a979b9a0de..76fee69376 100644
--- a/arch/xtensa/src/lx6/Toolchain.defs
+++ b/arch/xtensa/src/lx6/Toolchain.defs
@@ -97,7 +97,7 @@ ifeq ($(CONFIG_ARCH_INSTRUMENT_ALL),y)
   ARCHOPTIMIZATION += -finstrument-functions
 endif
 
-ARCHCFLAGS += -fno-common
+ARCHCFLAGS := -fno-common
 ARCHCXXFLAGS += -fno-common
 
 ARCHCFLAGS += -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas
@@ -156,7 +156,7 @@ ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
 endif
 
 ifeq ($(CONFIG_LIBC_ARCH_ATOMIC),y)
-  CFLAGS += -D__STDC_NO_ATOMICS__
+  ARCHCFLAGS += -D__STDC_NO_ATOMICS__
 endif
 
 # Default toolchain

I had to set __STDC_NO_ATOMICS__ to ARCHCFLAGS. However, this flag was being set twice while compiling esp32_boot.c and a redefinition error occurred. That's why I had to change it to ARCHCFLAGS := -fno-common (to let it be defined instead of redefined to avoid duplication). I couldn't find ARCHCFLAGS := anywhere else in the firmware (I couldn't understand why it was being redefined when processing esp32_boot.c too), so I'm not sure if this patch is acceptable. Any ideas?

zyfeier · 2024-11-19T03:19:30Z

STDC_NO_ATOMICS

Hi @zyfeier ! Thanks fo your quick response!

In fact, __STDC_NO_ATOMICS__ wasn't being set. I was able to make it work with the following patch:
diff --git a/arch/xtensa/src/lx6/Toolchain.defs b/arch/xtensa/src/lx6/Toolchain.defs
index a979b9a0de..76fee69376 100644
--- a/arch/xtensa/src/lx6/Toolchain.defs
+++ b/arch/xtensa/src/lx6/Toolchain.defs
@@ -97,7 +97,7 @@ ifeq ($(CONFIG_ARCH_INSTRUMENT_ALL),y)
   ARCHOPTIMIZATION += -finstrument-functions
 endif
 
-ARCHCFLAGS += -fno-common
+ARCHCFLAGS := -fno-common
 ARCHCXXFLAGS += -fno-common
 
 ARCHCFLAGS += -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas
@@ -156,7 +156,7 @@ ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
 endif
 
 ifeq ($(CONFIG_LIBC_ARCH_ATOMIC),y)
-  CFLAGS += -D__STDC_NO_ATOMICS__
+  ARCHCFLAGS += -D__STDC_NO_ATOMICS__
 endif
 
 # Default toolchain
I had to set __STDC_NO_ATOMICS__ to ARCHCFLAGS. However, this flag was being set twice while compiling esp32_boot.c and a redefinition error occurred. That's why I had to change it to ARCHCFLAGS := -fno-common (to let it be defined instead of redefined to avoid duplication). I couldn't find ARCHCFLAGS := anywhere else in the firmware (I couldn't understand why it was being redefined when processing esp32_boot.c too), so I'm not sure if this patch is acceptable. Any ideas?

@tmedicci I found that when compiling esp32/common, scripts/Make.defs is included twice, which causes the flags in ARCHCFLAGS to be doubled.

tmedicci · 2024-11-19T14:07:48Z

STDC_NO_ATOMICS

Hi @zyfeier ! Thanks fo your quick response!
In fact, __STDC_NO_ATOMICS__ wasn't being set. I was able to make it work with the following patch:
diff --git a/arch/xtensa/src/lx6/Toolchain.defs b/arch/xtensa/src/lx6/Toolchain.defs
index a979b9a0de..76fee69376 100644
--- a/arch/xtensa/src/lx6/Toolchain.defs
+++ b/arch/xtensa/src/lx6/Toolchain.defs
@@ -97,7 +97,7 @@ ifeq ($(CONFIG_ARCH_INSTRUMENT_ALL),y)
   ARCHOPTIMIZATION += -finstrument-functions
 endif
 
-ARCHCFLAGS += -fno-common
+ARCHCFLAGS := -fno-common
 ARCHCXXFLAGS += -fno-common
 
 ARCHCFLAGS += -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas
@@ -156,7 +156,7 @@ ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
 endif
 
 ifeq ($(CONFIG_LIBC_ARCH_ATOMIC),y)
-  CFLAGS += -D__STDC_NO_ATOMICS__
+  ARCHCFLAGS += -D__STDC_NO_ATOMICS__
 endif
 
 # Default toolchain
I had to set __STDC_NO_ATOMICS__ to ARCHCFLAGS. However, this flag was being set twice while compiling esp32_boot.c and a redefinition error occurred. That's why I had to change it to ARCHCFLAGS := -fno-common (to let it be defined instead of redefined to avoid duplication). I couldn't find ARCHCFLAGS := anywhere else in the firmware (I couldn't understand why it was being redefined when processing esp32_boot.c too), so I'm not sure if this patch is acceptable. Any ideas?
@tmedicci I found that when compiling esp32/common, scripts/Make.defs is included twice, which causes the flags in ARCHCFLAGS to be doubled.

That's perfect!

I was able to make it work (and, in fact, it fixes esp32-devkitc:sotest, esp32-devkitc:elf and esp32-devkitc:module). However, it's failing to build esp32-devkitc:wamr_wasi_debug:

make -j distclean && ./tools/configure.sh esp32-devkitc:wamr_wasi_debug && make -s -j$(nproc)
.
.
.
CC:  dirent/lib_closedir.c In file included from wamr/core/shared/utils/../platform/include/platform_api_extension.h:128,
                 from wamr/core/shared/utils/bh_platform.h:11,
                 from wamr/core/iwasm/aot/aot_runtime.h:9,
                 from wamr/core/iwasm/aot/aot_intrinsic.h:9,
                 from wamr/core/iwasm/aot/aot_intrinsic.c:6:
/home/tiago/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/lib/gcc/xtensa-esp32-elf/12.2.0/include/stdatomic.h:31:5: error: redeclaration of enumerator 'memory_order_relaxed'
   31 |     memory_order_relaxed = __ATOMIC_RELAXED,
      |     ^~~~~~~~~~~~~~~~~~~~
In file included from /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/nuttx/atomic.h:90,
                 from /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/nuttx/fs/fs.h:45,
                 from /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/stdio.h:36,
                 from wamr/core/shared/platform/nuttx/platform_internal.h:20,
                 from wamr/core/shared/utils/../platform/include/platform_common.h:13,
                 from wamr/core/shared/utils/bh_platform.h:9:
/home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/nuttx/lib/stdatomic.h:170:5: note: previous definition of 'memory_order_relaxed' with type 'enum <anonymous>'
  170 |     memory_order_relaxed = __ATOMIC_RELAXED,
      |     ^~~~~~~~~~~~~~~~~~~~
.
.
.

zyfeier · 2024-11-19T14:13:24Z

STDC_NO_ATOMICS

Hi @zyfeier ! Thanks fo your quick response!
In fact, __STDC_NO_ATOMICS__ wasn't being set. I was able to make it work with the following patch:
diff --git a/arch/xtensa/src/lx6/Toolchain.defs b/arch/xtensa/src/lx6/Toolchain.defs
index a979b9a0de..76fee69376 100644
--- a/arch/xtensa/src/lx6/Toolchain.defs
+++ b/arch/xtensa/src/lx6/Toolchain.defs
@@ -97,7 +97,7 @@ ifeq ($(CONFIG_ARCH_INSTRUMENT_ALL),y)
   ARCHOPTIMIZATION += -finstrument-functions
 endif
 
-ARCHCFLAGS += -fno-common
+ARCHCFLAGS := -fno-common
 ARCHCXXFLAGS += -fno-common
 
 ARCHCFLAGS += -Wall -Wstrict-prototypes -Wshadow -Wundef -Wno-attributes -Wno-unknown-pragmas
@@ -156,7 +156,7 @@ ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
 endif
 
 ifeq ($(CONFIG_LIBC_ARCH_ATOMIC),y)
-  CFLAGS += -D__STDC_NO_ATOMICS__
+  ARCHCFLAGS += -D__STDC_NO_ATOMICS__
 endif
 
 # Default toolchain
I had to set __STDC_NO_ATOMICS__ to ARCHCFLAGS. However, this flag was being set twice while compiling esp32_boot.c and a redefinition error occurred. That's why I had to change it to ARCHCFLAGS := -fno-common (to let it be defined instead of redefined to avoid duplication). I couldn't find ARCHCFLAGS := anywhere else in the firmware (I couldn't understand why it was being redefined when processing esp32_boot.c too), so I'm not sure if this patch is acceptable. Any ideas?
@tmedicci I found that when compiling esp32/common, scripts/Make.defs is included twice, which causes the flags in ARCHCFLAGS to be doubled.

That's perfect!

I was able to make it work (and, in fact, it fixes esp32-devkitc:sotest, esp32-devkitc:elf and esp32-devkitc:module). However, it's failing to build esp32-devkitc:wamr_wasi_debug:

make -j distclean && ./tools/configure.sh esp32-devkitc:wamr_wasi_debug && make -s -j$(nproc)
.
.
.
CC:  dirent/lib_closedir.c In file included from wamr/core/shared/utils/../platform/include/platform_api_extension.h:128,
                 from wamr/core/shared/utils/bh_platform.h:11,
                 from wamr/core/iwasm/aot/aot_runtime.h:9,
                 from wamr/core/iwasm/aot/aot_intrinsic.h:9,
                 from wamr/core/iwasm/aot/aot_intrinsic.c:6:
/home/tiago/.espressif/tools/xtensa-esp32-elf/esp-12.2.0_20230208/xtensa-esp32-elf/lib/gcc/xtensa-esp32-elf/12.2.0/include/stdatomic.h:31:5: error: redeclaration of enumerator 'memory_order_relaxed'
   31 |     memory_order_relaxed = __ATOMIC_RELAXED,
      |     ^~~~~~~~~~~~~~~~~~~~
In file included from /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/nuttx/atomic.h:90,
                 from /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/nuttx/fs/fs.h:45,
                 from /home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/stdio.h:36,
                 from wamr/core/shared/platform/nuttx/platform_internal.h:20,
                 from wamr/core/shared/utils/../platform/include/platform_common.h:13,
                 from wamr/core/shared/utils/bh_platform.h:9:
/home/tiago/Documents/work/espressif/projects/nuttx/nuttxspace_beta/nuttx/include/nuttx/lib/stdatomic.h:170:5: note: previous definition of 'memory_order_relaxed' with type 'enum <anonymous>'
  170 |     memory_order_relaxed = __ATOMIC_RELAXED,
      |     ^~~~~~~~~~~~~~~~~~~~
.
.
.

@tmedicci wamr_wasi_debug build issue will fixed in PR #14827, and also i move the Make.def modify to PR #14855

tmedicci

Approved. Thanks, @zyfeier !

xiaoxiang781216 · 2024-11-19T18:08:03Z

arch/xtensa/src/cmake/Toolchain.cmake

@@ -188,3 +188,7 @@ endif()
 if(CONFIG_DEBUG_SYMBOLS)
  add_compile_options(${CONFIG_DEBUG_SYMBOLS_LEVEL})
 endif()
+
+if(CONFIG_LIBC_ARCH_ATOMIC)
+  add_compile_options(-D__STDC_NO_ATOMICS__)


why need add STDC_NO_ATOMICS?

not use stdc atomic function, use arch_atomic when use iram heap

but why do we check __STDC_NO_ATOMICS__ not CONFIG_LIBC_ARCH_ATOMIC?

S32C1I instructions may target cached, cache-bypass, and data RAM memory locations. S32C1I instructions are not permitted to access memory addresses in data ROM, instruction memory or the address region allocated to the XLMI port. Attempts to direct the S32C1I at these addresses will cause an exception. Signed-off-by: zhangyuan29 <zhangyuan29@xiaomi.com>

github-actions bot added Arch: xtensa Issues related to the Xtensa architecture Size: XS The size of the change in this PR is very small labels Nov 15, 2024

xiaoxiang781216 requested a review from tmedicci November 15, 2024 06:27

zyfeier force-pushed the sem_atomic branch from aab82d0 to 2b4626c Compare November 15, 2024 07:04

zyfeier marked this pull request as ready for review November 15, 2024 07:04

xiaoxiang781216 reviewed Nov 15, 2024

View reviewed changes

arch/xtensa/src/lx6/Toolchain.defs Show resolved Hide resolved

zyfeier force-pushed the sem_atomic branch from 2b4626c to 7fe6ce4 Compare November 15, 2024 07:47

github-actions bot added Size: S The size of the change in this PR is small and removed Size: XS The size of the change in this PR is very small labels Nov 15, 2024

yamt reviewed Nov 15, 2024

View reviewed changes

zyfeier force-pushed the sem_atomic branch 2 times, most recently from c599baa to 74610b0 Compare November 15, 2024 13:00

acassis approved these changes Nov 16, 2024

View reviewed changes

zyfeier force-pushed the sem_atomic branch from 74610b0 to 19d07f2 Compare November 19, 2024 03:37

github-actions bot added the Board: xtensa label Nov 19, 2024

zyfeier mentioned this pull request Nov 19, 2024

xtensa/esp32: Remove duplicate board Make.defs #14855

Merged

tmedicci approved these changes Nov 19, 2024

View reviewed changes

xiaoxiang781216 reviewed Nov 19, 2024

View reviewed changes

zyfeier force-pushed the sem_atomic branch from 19d07f2 to 9266587 Compare November 20, 2024 01:20

github-actions bot removed the Board: xtensa label Nov 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

arch/xtensa: use arch atomic when enable iram heap #14805

arch/xtensa: use arch atomic when enable iram heap #14805

zyfeier commented Nov 15, 2024 •

edited

Loading

nuttxpr commented Nov 15, 2024

yamt Nov 15, 2024

zyfeier Nov 15, 2024

tmedicci Nov 18, 2024

zyfeier Nov 19, 2024

tmedicci commented Nov 18, 2024

tmedicci commented Nov 18, 2024

zyfeier commented Nov 18, 2024

tmedicci commented Nov 18, 2024

zyfeier commented Nov 19, 2024

tmedicci commented Nov 19, 2024

zyfeier commented Nov 19, 2024

tmedicci left a comment

xiaoxiang781216 Nov 19, 2024

zyfeier Nov 20, 2024

xiaoxiang781216 Nov 20, 2024

arch/xtensa: use arch atomic when enable iram heap #14805

Are you sure you want to change the base?

arch/xtensa: use arch atomic when enable iram heap #14805

Conversation

zyfeier commented Nov 15, 2024 • edited Loading

Summary

Impact

Testing

nuttxpr commented Nov 15, 2024

yamt Nov 15, 2024

Choose a reason for hiding this comment

zyfeier Nov 15, 2024

Choose a reason for hiding this comment

tmedicci Nov 18, 2024

Choose a reason for hiding this comment

zyfeier Nov 19, 2024

Choose a reason for hiding this comment

tmedicci commented Nov 18, 2024

tmedicci commented Nov 18, 2024

zyfeier commented Nov 18, 2024

tmedicci commented Nov 18, 2024

zyfeier commented Nov 19, 2024

tmedicci commented Nov 19, 2024

zyfeier commented Nov 19, 2024

tmedicci left a comment

Choose a reason for hiding this comment

xiaoxiang781216 Nov 19, 2024

Choose a reason for hiding this comment

zyfeier Nov 20, 2024

Choose a reason for hiding this comment

xiaoxiang781216 Nov 20, 2024

Choose a reason for hiding this comment

zyfeier commented Nov 15, 2024 •

edited

Loading