boards/esp32-devkitc: Let ostest finish on the knsh configuration

[casaroli]

Summary

A full ostest run never reached the end on esp32-devkitc:knsh. It stopped in the barrier test:

barrier_test: ERROR thread 6 create, status=12
barrier_test: Test aborted with waiting threads
ostest_main: Exiting with status 256

This lowers the barrier thread count for that configuration, and the run completes.

Cause

Two settings that are each reasonable on their own.

CONFIG_TLS_ALIGNED is set and CONFIG_TLS_LOG2_MAXSTACK is 13, so every pthread stack must begin on an 8 KiB boundary. The barrier threads take the 2 KiB default stack, so each one occupies an 8 KiB aligned slot — four times what it uses.

A protected build has a 96 KiB user heap. Eight aligned slots do not fit it once the tests before the barrier have fragmented it, and the allocation fails:

up_create_stack: ERROR: Failed to allocate stack, size 2048

The flat build has the same two settings and passes, because its heap is 320 KiB against 96 KiB here. That is the whole difference.

Two things this is not, both measured rather than assumed. It is not the user heap running out: 75,544 bytes were free with a 47,096 byte largest block when a 2048 byte request failed. It is not the kernel heap: raising CONFIG_MM_KERNEL_HEAPSIZE from 8 KiB to 32 KiB changed nothing, and the failure stayed on thread 6 exactly.

Why not grow the heap instead

The user heap cannot grow far. User data has to sit in the MMU governed window of SRAM2, 0x3ffc0000 to 0x3ffdffff, which is 128 KiB in total, and the kernel currently holds the first 32 KiB of it. Recovering that would move the kernel/user boundary and the per-page access rights in esp32_userspace.c, which is a larger change to an experimental subsystem and does not belong in a fix for a test configuration.

Four threads still test a barrier. They also leave margin: six was the most that ever started, so six would pass with none at all.

Testing

Board: ESP32-DevKitC V4, with an ESP32-D0WD-V3 revision 3.1.

Host: macOS 15 on Apple Silicon, xtensa-esp32-elf-gcc 12.2.0.

Configured from the edited defconfig after a distclean, so the result comes from the committed file:

barrier_test: Thread 0 completed with result=0
barrier_test: Thread 1 completed with result=0
barrier_test: Thread 2 completed with result=0
barrier_test: Thread 3 completed with result=0
...
ostest_main: Exiting with status 0

Before this change the same board and toolchain gave Exiting with status 256.

tools/checkpatch.sh -c -u -m -g reports no errors.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb