NXP IMXRT10XX Toolchain Linker Issues with SDRAM

[dkouba-atym]

Describe the bug

Hi all, we are working with the NXP IMXRT1064 and are intending to use the SDRAM as a memory region for some specific data structures, while the application runs out of OCRAM.

With the default SoC/board configuration (sdram0 node enabled in the device tree), this linker script is included in the build process which creates a MEMORY region for the SDRAM.

However when I try to assign a data structure to the SDRAM region:

__attribute__((section("SDRAM"), aligned(32))) <big data structure>;

This results in a linker error:

/Users/dankouba/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: warning: orphan section `SDRAM' from `app/libapp.a(cs_sm_impl.c.obj)' being placed in section `SDRAM'
/Users/dankouba/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `SDRAM' will not fit in region `FLASH'
/Users/dankouba/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `FLASH' overflowed by 4799424 bytes

To get around this, I add the following to my overlay:

&sdram0 {
    compatible = "zephyr,memory-region", "mmio-sram";
    zephyr,memory-region = "SDRAM";                     /* Name creates a linker region & an MPU mapping */
    zephyr,memory-attr = <(DT_MEM_ARM(ATTR_MPU_RAM))>;  /* Normal, cacheable RAM, non-exec */
    status = "okay";
};

With this, I am able to assign my variable to the region successfully. However, this results in a linker warning:

[578/588] Linking C executable zephyr/zephyr_pre0.elf
/Users/dankouba/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd:zephyr/linker_zephyr_pre0.cmd:11: warning: redeclaration of memory region `SDRAM'
[582/588] Linking C executable zephyr/zephyr_pre1.elf
/Users/dankouba/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd:zephyr/linker_zephyr_pre1.cmd:11: warning: redeclaration of memory region `SDRAM'
[588/588] Linking C executable zephyr/zephyr.elf
/Users/dankouba/zephyr-sdk-0.16.8/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd:zephyr/linker.cmd:11: warning: redeclaration of memory region `SDRAM'

When I inspect linker.cmd, I do see the regions duplicated:

MEMORY
     {
        SDRAM (wx) : ORIGIN = (2147483648), LENGTH = (33554432)
     }
 OUTPUT_FORMAT("elf32-littlearm")
_region_min_align = 32;
MEMORY
    {
    FLASH (rx) : ORIGIN = (0x70000000 + 0x0), LENGTH = (4096 * 1024 - 0x0 - 0x0)
    RAM (wx) : ORIGIN = 0x20200000, LENGTH = (512 * 1K)
    ITCM ( rw ) : ORIGIN = (0), LENGTH = (131072) DTCM ( rw ) : ORIGIN = (536870912), LENGTH = (131072) OCRAM ( rw ) : ORIGIN = (539492352), LENGTH = (262144) OCRAM2 ( rw ) : ORIGIN = (538968064), LENGTH = (524288) SDRAM ( rw ) : ORIGIN = (2147483648), LENGTH = (33554432)
    IDT_LIST (wx) : ORIGIN = 0xFFFF7FFF, LENGTH = 32K
    }

To me, it seems like the custom linker script should be removed and this all should be dealt with via the .dts file, wrapping in the definition of the memory region using zephyr,memory-region. However, I am not well-versed in this area of Zephyr and I don't know what that may break or if that is the recommended standard practice.

If someone can provide guidance as to the correct approach to fixing this, I'd be happy to contribute a PR with the changes.

Regression

• This is a regression.

Steps to reproduce

No response

Relevant log output

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

No response

Additional Context

No response

[decsny]

@dkouba-atym I converted your issue #95083 to this discussion because it is not an issue. But you can give feedback here for how you think the situation can be improved to be more convenient or useful to you.

The reason for the redeclaration linker warning when you added the DT prop is because the SOC linker script is still pulled in, in addition to the DT defined linker regions that are defined by a macro in the cortex-m linker script.

Before that, the reason for your error is because you are using this compiler section attribute on something that is not a section. "SDRAM" is a memory region, not a section. What you did is add a new input section which didn't have any special rule to apply it into any output section that will go into the SDRAM region, so it ended up just getting put into flash. The reason for why it goes there specifically when this happens, I haven't investigated the details, but it's moot, because the bug was on your code using "SDRAM" as an input section without any linker script describing where that section goes.

[decsny]

If you want to avoid the warning you are getting now, you can delete the SDRAM declaration in the SOC linker script and only have the DT one. Maybe that is an option to generically do for these RT boards in Zephyr, as a newer approach. The reason for this linker script having that declared is historical - it used to be also where the RAM, ITCM, and DTCM were declared before there was a way to describe memory regions in DT and the apps or some other software had to write the custom linker script to put things there. It's just this one never got converted to a new way of doing things whereas the others did.

History:
f78f707
4afc478
588890f
6bcdcc3

[jacob-wienecke-nxp]

@dkouba-atym

After looking at the linker script you referenced, the purpose is to provide the linker the information that that region exists, but it does not provide the section placement rules.

I believe, given the current implementation, and given the possibility that there could be a more generic SEMC solution later that the "cleanest solution" would be to have a custom linker script which has the section placement rules.

Something like:

SDRAM (NOLOAD) : { 
    __SDRAM_start = .; 
    KEEP(*(SDRAM)) 
    __SDRAM_end = .; 
} > SDRAM 
__SDRAM_size = __SDRAM_end - __SDRAM_start; 
__SDRAM_load_start = LOADADDR(SDRAM);

Then you can include the custom section placement rules by adding:
zephyr_linker_sources(SECTIONS large-data-section.ld)

to CMakeLists.txt.

I am somewhat conflicted on the purpose of the current linker script declaration of the SDRAM region, since it does not provide section placement rules, but it does serve the purpose of ensuring that "SDRAM" is only available to linker in the event that zephyr,sram is directed elsewhere.

[Ductapemaster]

Is there a reason why #95299 won't work and avoid the linker script altogether?

[decsny]

My suggestion above was to remove the SDRAM region from the soc linker script, and use a board-defined DT memory region for SDRAM.