How to make two fragments of non-contiguous memory a single ROMMABLE region ?

[SumitNandi-eaton]

Hi,

• The linker and map generated for the blinky sample on stm32mp157c_dk2 board uses
  320KB of multiple SRAMs (SRAM0,SRAM1,SRAM2..) as RAM and
  64KB RETRAM as ROM
  

What I am trying to achieve is use bigger space for ROM as my code size is bound to grow beyond 64K.
so i want to use a chunk of SRAM as well for my code part.

I referred the code relocation examples under /~https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/application_development but i could not figure out any method to create ROMMABLE region out of fragmented non-contiguous memory.

Do i need to create a custom linker w.r.t. /~https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/arm/st_stm32/stm32mp1/linker.ld

or there is some other better way to handle this?

Any help/insights/hints is much appreciated

Thanks in advance

[rhaberkorn]

I was trying something very similar, but ultimately failed. I was using

CONFIG_CODE_DATA_RELOCATION=y
CONFIG_HAVE_CUSTOM_LINKER_SCRIPT=y
CONFIG_CUSTOM_LINKER_SCRIPT="linker_arm_nocopy.ld"
CONFIG_XIP=y

Two additional code sections (I also have IPC buffers at 0x10040000, that I didn't manage to move elsewhere):

    mcusram1: memory1@10000000 {
        compatible = "mmio-sram";
        reg = <0x10000000 DT_SIZE_K(64)>;
    };

    mcusram4: memory4@10046000 {
        compatible = "mmio-sram";
        reg = <0x10046000 DT_SIZE_K(40+64)>;
    };

With a corresponding custom linker script:

#include <zephyr/linker/sections.h>
#include <zephyr/devicetree.h>

#include <zephyr/linker/linker-defs.h>
#include <zephyr/linker/linker-tool.h>

#define MCUSRAM1_NODE	DT_NODELABEL(mcusram1)
#define MCUSRAM1_ADDR	DT_REG_ADDR(MCUSRAM1_NODE)
#define MCUSRAM1_SIZE	DT_REG_SIZE(MCUSRAM1_NODE)

#define MCUSRAM4_NODE	DT_NODELABEL(mcusram4)
#define MCUSRAM4_ADDR	DT_REG_ADDR(MCUSRAM4_NODE)
#define MCUSRAM4_SIZE	DT_REG_SIZE(MCUSRAM4_NODE)

MEMORY
{
	MCUSRAM1 (rwx) : ORIGIN = MCUSRAM1_ADDR, LENGTH = MCUSRAM1_SIZE
	MCUSRAM4 (rwx) : ORIGIN = MCUSRAM4_ADDR, LENGTH = MCUSRAM4_SIZE
}

#include <linker.ld>

Here I am trying to relocate a single file:

zephyr_code_relocate(FILES src/main.c LOCATION MCUSRAM1 NOCOPY NOKEEP)

The code is loaded by the remoteproc's ELF loader, so we can use NOCOPY.
Also note, that you need to mark these additional sections as executable which I did with a separate compilaton unit, that must never be relocated:

#include <string.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>

#include <zephyr/kernel.h>
#include <zephyr/device.h>

static int disable_mpu_rasr_xn(void)
{
    for (uint32_t index = 0U; index < 8; index++) {
        MPU->RNR = index;
        if (MPU->RASR & MPU_RASR_XN_Msk)
            MPU->RASR ^= MPU_RASR_XN_Msk;
    }

    return 0;
}

SYS_INIT(disable_mpu_rasr_xn, PRE_KERNEL_1, 0);

The original code_relocation_nocopy Zephyr example did this in main(), but then you couldn't relocate anything from within Zephyr that's executed before main(). My method above should be a bit more flexible and allow more drivers to be relocated.

Still, it did not fully work because global variables (data section) in the relocated compilation units were not initialized correctly. That's strange because the corresponding data is in the ELF file and there are ELF header entries with the correct virtual addresses. Either the Linux kernel does not load these memory areas correctly or something in Zephyr's startup code overwrites these memory areas.

I feel this must be possible somehow and it can't be that difficult, but unfortunately I have no more time to debug the problem.

[rhaberkorn]

I believe that Zephyr is causing the relocated data objects to be loaded into RETRAM (via paddr from the ELF entry), expecting them to be copied into their final destinations later on. From the generated linker_relocate.ld:

        SECTION_PROLOGUE(.mcusram1_data_reloc,,)
        {
                . = ALIGN(4);

                *main.c.obj(.data.foo)

                . = ALIGN(4);
        }
#ifdef CONFIG_XIP
GROUP_DATA_LINK_IN(MCUSRAM1 , ROMABLE_REGION)
#else
GROUP_DATA_LINK_IN(MCUSRAM1 , MCUSRAM1 )
#endif

If I comment that out - so we always do GROUP_DATA_LINK_IN(MCUSRAM1 , MCUSRAM1 ) even in the presence of CONFIG_XIP - as a quick and dirty test in gen_relocate_app.py, I do actually get it to link correctly and my relocated data objects are initialized properly. Obviously now the vaddr and paddr are the same in the generated ELF, the Linux kernel loads everything into their final runtime destinations and there is no additional copying required by Zephyr.

I believe we should bring this up as a ticket to discuss how to solve the issue properly. We will probably require additional/new Kconfig settings.