fdcavalcanti commented on code in PR #20125:
URL: https://github.com/apache/nuttx/pull/20125#discussion_r4004812692


##########
arch/risc-v/src/common/espressif/Kconfig:
##########
@@ -238,6 +251,84 @@ config ESPRESSIF_REGION_PROTECTION
        ---help---
                Configure the MPU to disable access to invalid memory regions.
 
+               Must be disabled in a protected build; esp_start.c fails the 
build
+               if it is not.  It only adds a second, redundant call to
+               esp_cpu_configure_region_protection() late in esp_start() -- the
+               regions have already been programmed from bootloader_init() by 
then
+               -- and in a protected build the kernel owns the PMP and 
re-describes
+               it during userspace initialisation, so the extra call is 
pointless
+               at best and racy against that setup at worst.
+
+               This is enforced with a compile-time check rather than
+               "depends on !BUILD_PROTECTED".  This symbol selects 
ARCH_USE_MPU and
+               BUILD_PROTECTED depends on ARCH_USE_MPU, so a dependency on the
+               build type closes a loop that Kconfig resolves by making
+               BUILD_PROTECTED unsatisfiable -- which silently collapses the 
whole
+               "Memory organization" choice for every board in the tree.
+
+config ESPRESSIF_KERNEL_OWNS_PMP
+       bool "Kernel owns the PMP configuration"
+       depends on ARCH_CHIP_ESP32P4
+       default n
+       select ARCH_USE_MPU
+       ---help---
+               Drop the HAL's esp_cpu_configure_region_protection() from the 
build
+               and supply a NuttX build of the same code with the PMP lock bit
+               cleared.  The region layout, and the PMA setup the SoC needs in
+               order to run at all, are unchanged; only the lock bit differs.
+
+               The HAL version sets the lock bit on every entry it writes, and 
runs
+               from bootloader_init() before NuttX can intervene.  PMP lock 
bits
+               are irreversible without the Smepmp extension, which the 
ESP32-P4
+               does not implement, so a protected build has to prevent the 
locking
+               rather than undo it.
+
+               A protected build requires this and must set it explicitly in 
its
+               defconfig; esp_start.c fails the build if the two disagree.  It 
is
+               deliberately not "default y if BUILD_PROTECTED": this symbol 
selects
+               ARCH_USE_MPU, BUILD_PROTECTED depends on ARCH_USE_MPU, and a 
default
+               conditioned on BUILD_PROTECTED closes that loop.  Kconfig 
resolves
+               the circularity by making BUILD_PROTECTED unsatisfiable, which
+               silently collapses the whole "Memory organization" choice for 
every
+               board in the tree.
+
+               Enabling it on its own is legitimate only for bring-up: unlocked
+               entries do not constrain machine mode, so a flat build ends up 
with
+               less protection than it would otherwise have.
+
+if BUILD_PROTECTED
+
+config ESPRESSIF_USER_IMAGE_OFFSET

Review Comment:
   How is the MCUboot support?
   This could clash against MCUboot similar option.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to