What is the role of detached section?

[dbaluta]

I'm having this issue on imx8mp with M7 core where ITCM section is not copied in the final .rimage because the corresponding section is marked as detached.

Here is the memory map for A53/M7 cores for ITCM:

It looks like SOF marks any sections that's between this two limits:

define SOF_MODULE_DRAM_LINK_START»     0
#define SOF_MODULE_DRAM_LINK_END»       0x08000000

as detached and not copied in the final rimage.

So, what is the purpose of this detached section? Is there a way we can easily make this work? Would it make sense to add a per platform option named ignore_detached ?

Cc: @lyakh @lgirdwood

[lgirdwood]

Oh, thats a good question our architecture is NUMA. I've no objection, but I would have expected rimage to deal with multiple detached sections

[lyakh]

@dbaluta the purpose of "detached" sections is to implement "cold" data and text on Intel ADSP platforms. Those "cold" sections are then kept and used directly in DRAM without being copied to SRAM. So, firstly cold sections definitely do get copied to the rimage in Intel builds, so maybe you could do the same for your platform. But I'm not sure I understand - from your section map above it looks like all the 3 sections (OCRAM, DTCM, ITCM) are below SOF_MODULE_DRAM_LINK_END so there should be no difference between them?

[lgirdwood]

@lyakh I'm thinking this should be supported but never tried for IMX given that we have cache, uncache and DRAM regions which are all detached from each other, I suspect the Intel arch could maybe be baked into some rimage assumptions as IIUC rimage should obey the linker sections.

[dbaluta]

@dbaluta the purpose of "detached" sections is to implement "cold" data and text on Intel ADSP platforms. Those "cold" sections are then kept and used directly in DRAM without being copied to SRAM. So, firstly cold sections definitely do get copied to the rimage in Intel builds, so maybe you could do the same for your platform. But I'm not sure I understand - from your section map above it looks like all the 3 sections (OCRAM, DTCM, ITCM) are below SOF_MODULE_DRAM_LINK_END so there should be no difference between them?

OCRAM and DTCM would be in the same situation yes! But we only use ITCM for jumpstart code then everything is executed from DRAM.

If we decide in the future that we would want to use OCRAM and DTCM they would also be marked as detached as per rimage implementation.

[dbaluta]

@dbaluta the purpose of "detached" sections is to implement "cold" data and text on Intel ADSP platforms. Those "cold" sections are then kept and used directly in DRAM without being copied to SRAM. So, firstly cold sections definitely do get copied to the rimage in Intel builds, so maybe you could do the same for your platform. But I'm not sure I understand - from your section map above it looks like all the 3 sections (OCRAM, DTCM, ITCM) are below SOF_MODULE_DRAM_LINK_END so there should be no difference between them?

Any idea where this Intel cold sections are copied in the rimage?

later edit

Maybe I'm missing something but ROM and detached looks like are not copied:

    »       if (out_section->detached) {                                                                                                                                                  
»       »       »       /* Detached sections are copied as is and don't contribute to metadata */
»       »       »       fprintf(stdout, " detached");
»       »       } else if (out_section->rom) {
»       »       »       /* ROM sections aren't included in the output image */
»       »       »       fprintf(stdout, " ROM");
»       »       } else {
»       »       »       /* Add section to list */
»       »       »       if (info)
»       »       »       »       sections_info_add(info, out_section);
»       »       }

I mean I thought that sections are copied to rimage only if they are added to the section list. I will continue investigation because what you say makes sense and it looks like it should work even if the section is marked as detached.

[lyakh]

@dbaluta

at the moment the only type of "detached" sections, supported by SOF are "cold" (text and data) sections:

sof/tools/rimage/src/module.c

Lines 368 to 369 in a32d983

	if (out_section->detached)
	cold_data_size += out_section->size;

sof/tools/rimage/src/module.c

Lines 375 to 376 in a32d983

	if (out_section->detached)
	cold_text_size += out_section->size;

When the base module is built those sections are then linked into a separate "cold.mod" module: https://github.com/thesofproject/sof/actions/runs/22758903606/job/66010318688?pr=10599#step:8:1129 which is then linked into the final zephyr.ri https://github.com/thesofproject/sof/actions/runs/22758903606/job/66010318688?pr=10599#step:8:1039

With LLEXT modules this is a bit different - there all sections (hot and cold) are linked into the same module.

Maybe we could define SOF_MODULE_DRAM_LINK_END per platform and if it's 0 all sections will be treated as SRAM?

[dbaluta]

I see. Thanks! Yes having a per platform SOF_MODULE_DRAM_LINK_END would work. Will send a patch.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[lgirdwood]

@lyakh just hit this as well when loading llext unit test modules using the shell. i.e. they are not audio modules, but I have a command to call the ctor which would fail unless this was applied: zephyrproject-rtos/zephyr@main...lgirdwood:zephyr:topic/llext_plt
Not sure if you came across this during your llext dev re detached sections though ?
@dbaluta not sure if this helps you ?