[2/3] mm/pgalloc, arch/xtensa: Support BUILD_KERNEL on Xtensa

[casaroli]

Summary

Split from #19772, part 2 of 3, as asked in review.

This is the architecture-independent half: mm/pgalloc learns larger pages, and arch/xtensa/src/common learns BUILD_KERNEL. No chip code and no board code — those are part 3.

This part does not depend on part 1. It adds no fork() or vfork() code and refers to neither. It applies to master on its own, and the two parts can be merged in any order.

mm/pgalloc supported 1 KB, 2 KB and 4 KB pages. The Espressif cache MMU has a fixed 64 KB page for external flash and 32 KB for external RAM, so those two sizes are added. Nothing else changes for existing users, who keep whatever they already selected.

On the Xtensa side, BUILD_KERNEL needs the pieces every kernel build needs and Xtensa did not have: a kernel stack for a user thread, a signal trampoline that returns through a system call, an initial register state that starts a user task on the right stack at the right privilege, and the system call paths to move between the two worlds.

Two details are worth a reviewer's attention.

The kernel stack is aligned to 16 bytes because the windowed ABI requires it, and a stack pointer carries a base save area in the 16 bytes below it holding the caller's spilled a0–a3. Anything that moves or builds a stack pointer has to leave that area alone, which is why the signal trampoline reserves it explicitly rather than assuming the space below the pointer is free.

crt0.c uses STRINGIFY from nuttx/macro.h rather than defining its own, per review.

Impact

Xtensa can be built with CONFIG_BUILD_KERNEL once a chip provides an address environment. No chip does so in this patch, so nothing changes for any existing configuration.

mm/pgalloc gains two page sizes and changes no default. MM_PGSIZE is read only when CONFIG_MM_PGALLOC is set, so existing kernel builds keep the arm they already took.

Testing

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

This branch adds no chip code, so no kernel build is possible yet. BUILD_KERNEL needs ARCH_USE_MMU and ARCH_ADDRENV, and the ESP32-S3 selects ARCH_HAVE_MMU and ARCH_HAVE_ADDRENV only in part 3. The check that matters here is that the common code compiles, links and does not disturb a working flat build.

esp32s3-devkit:nsh builds clean on this branch alone, with neither ARCH_HAVE_VFORK nor ARCH_HAVE_FORK set.

esp32s3-devkit:ostest was also run on hardware, on this branch alone, to show no regression.

board	module	core	configuration	result
ESP32-S3-DevKitC	ESP32-S3-WROOM-2 N32R8V, 32 MB, octal	LX7	esp32s3-devkit:ostest	runs to the end, status 0

NuttShell (NSH) NuttX-12.2.1
nsh> ostest
...
ostest_main: Exiting with status 0

The 32 MB octal part also needs ESP32S3_FLASH_MODE_OCT and ESP32S3_SPI_FLASH_USE_32BIT_ADDRESS.

The kernel build that exercises this code lives in part 3, and its results are reported there.

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

[casaroli]

This work is now in #19798, together with the ESP32-S3 chip code and the user mode isolation that a kernel build needs.

Please review #19798 instead of this one.

This pull request stays open for reference, and it will be closed when #19798 is merged.