ricardgb commented on code in PR #19256: URL: https://github.com/apache/nuttx/pull/19256#discussion_r3642931624
########## arch/arm/src/rp23xx/rp23xx_textheap.c: ########## @@ -0,0 +1,99 @@ +/**************************************************************************** + * arch/arm/src/rp23xx/rp23xx_textheap.c + * + * SPDX-License-Identifier: Apache-2.0 + * + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. The + * ASF licenses this file to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance with the + * License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations + * under the License. + * + ****************************************************************************/ + +/**************************************************************************** + * Text-heap allocator for the RP2350. + * + * Dynamically loaded code (e.g. a "lifted arm" copied in from NFS) must be + * placed in memory that the CPU can both write and then execute. On the + * RP2350 the on-chip SRAM (0x20000000) is normal, executable memory, and + * this port runs without the MPU enabled (CONFIG_ARM_MPU=n), so RAM is not + * marked no-execute. The general-purpose kernel heap therefore already + * satisfies the requirements of a text heap, and these wrappers simply + * forward to it (the same approach used by arch/arm/src/cxd56xx). + * + * Because the instruction and data views of this memory are the same + * address, ARCH_HAVE_TEXT_HEAP_SEPARATE_DATA_ADDRESS is not selected and + * up_textheap_data_address() is not required. + ****************************************************************************/ + +/**************************************************************************** + * Included Files + ****************************************************************************/ + +#include <nuttx/config.h> + +#include <sys/types.h> +#include <stdbool.h> + +#include <nuttx/arch.h> +#include <nuttx/kmalloc.h> + +#ifdef CONFIG_ARCH_USE_TEXT_HEAP + +/**************************************************************************** + * Public Functions + ****************************************************************************/ + +/**************************************************************************** + * Name: up_textheap_memalign + * + * Description: + * Allocate aligned, executable memory for dynamically loaded code. + * + ****************************************************************************/ + +void *up_textheap_memalign(size_t align, size_t size) +{ + return kmm_memalign(align, size); Review Comment: Fair question — selecting ARCH_HAVE_TEXT_HEAP isn't claiming the text heap is a different region; it's what allows CONFIG_ARCH_USE_TEXT_HEAP to be enabled on this chip, so portable consumers of the text-heap API (the ELF loader's section allocation in libs/libc/elf/elf_load.c, dynamic code generators) can run unmodified. On architectures where ordinary heap memory isn't executable (e.g. separate IRAM), up_textheap_memalign() maps to a real separate heap; on the RP2350 all SRAM is executable and NuttX runs with the MPU disabled, so the correct implementation is simply the kernel heap — same pattern as other flat-memory ports. Without this, code written against the portable API can't target rp23xx at all. If you'd prefer, I can add a comment in the file making this rationale explicit. -- 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]
