CONFIG_CODE_DATA_RELOCATION may conflict with __ramfunc on Cortex-M7


Has anyone had issues combining data/code relocation and __ramfunc support?  

__ramfunc functions as expected on an iMXRT1062 system.  When additional code is relocated via the file-based CONFIG_CODE_DATA_RELOCATION feature, __ramfunc no longer executes properly.  If you look at the flash contents, they appear to be offset by 16 as are the resultant instructions loaded in RAM.  Perhaps this is an alignment bug in the solution.  

   0x80000cc0 <flexSpiNorInit+0>: movs r0, r0   <-------  0's for first 16 memory locations
   0x80000cc2 <flexSpiNorInit+2>: movs r0, r0
   0x80000cc4 <flexSpiNorInit+4>: movs r0, r0
   0x80000cc6 <flexSpiNorInit+6>: movs r0, r0
   0x80000cc8 <flexSpiNorInit+8>: movs r0, r0
   0x80000cca <flexSpiNorInit+10>: movs r0, r0
   0x80000ccc <flexSpiNorInit+12>: movs r0, r0
   0x80000cce <flexSpiNorInit+14>: movs r0, r0
   0x80000cd0 <flexSpiNorInit+16>: push {lr}             <---- this is incorrectly offset by 16 in _ramfunc_rom_start
   0x80000cd2: sub sp, #60 ; 0x3c
   0x80000cd4: add r0, sp, #4
   0x80000cd6: bl 0x80000104 <FLEXSPI_GetDefaultConfig+16>
   0x80000cda: movs r0, #0
   0x80000cdc: add sp, #60 ; 0x3c
   0x80000cde: ldr.w r0, [sp, r0]


In general, it does not appear that code and data relocation currently manages the MPU.  For example, z_arch_configure_static_mpu_regions() had no provision for a potential SRAM region of execution generated by this feature.   This renders the code relocation unusable in userspace implementations.  Since zephyr will disable all unused MPU regions, it isn't possible to simply enable access to these regions at boot.  Zephyr modifications will be required.  

A combination of custom linker scripts and appropriate hooks for user additions to MPU configuration and section initialization may be more flexible and direct.