40Grit
commented
3 years ago I'd rather we all just come together and define some MCU address space partitioning standards, along with some standards to enable dynamic placement of firmware images in a partition and then develop a minimum viable '0th stage' bootloader to interpret the partitions and boot the dynamic images.
Is your feature request related to a problem? Please describe. I'd like to be able to use MBED_ROM_START macros to know in my C code (which might perhaps be a custom bootloader) where different memory regions start and end. This seems to come from
targets.json. However, many targets don't have the memory map described intargets.json.Describe the solution you'd like Could we migrate the memory region information
tools/arm_pack_manager/index.jsontotargets.json? Is that a good way forward?Describe alternatives you've considered We could also update mbed-tools to parse
tools/arm_pack_manager/index.json. It's unclear what automation is currently in place to keep this file up-to-date, however, if any. The filetargets.jsonseems like a good place to hold the memory map for targets given that when porting a new target, you have to set properties in this file anyway.We might also standardize on common-across-all-targets linker-defined symbols for marking the start and end of regions, and use those in place of MBEDROM or MBEDRAM macros. We generally define symbols for the regions today, but this may not be aligned across all targets yet. We'd need to put tests in place to ensure alignment. Using linker-defined boundary symbols might be a good alternative to using MBED_ROM_START and friends in my C code (which may be a custom bootloader).
Additional context Please refer to the discussion thread in PR #270 for some more context and detail. See also #222 for more detail about the possible use cases of these defines.