Linux/PROCESSOR-SDK-AM57X: DSP internal memory usage

Franz Franz

Prodigy 50 points

Part Number: PROCESSOR-SDK-AM57X

Tool/software: Linux

Hi!

I am currently testing IPC between Linux and the C66x DSP Coprocessor on the AM57xx SOC.

I need some advice regarding the remoteproc subsystem in the Linux Kernel:

Here is a code snippet of the rsc_table_vayu_dsp.h file, which I am using for my tests:

    {
        TYPE_CARVEOUT,
        DSP_MEM_TEXT, 0,
        DSP_MEM_TEXT_SIZE, 0, 0, "DSP_MEM_TEXT",
    },

    {
        TYPE_CARVEOUT,
        DSP_MEM_DATA, 0,
        DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
    },

    {
        TYPE_CARVEOUT,
        DSP_MEM_HEAP, 0,
        DSP_MEM_HEAP_SIZE, 0, 0, "DSP_MEM_HEAP",
    },

If I understand it correctly, then the whole generated Code of the DSP will be mapped to the Main Memory of the AM57xx SOC, using the DSP MMU. Is that correct?

The linker.cmd file confirms this, as all sections are mapped to some kind of virtual address and not to the internal memory which is located at 0x800000:

MEMORY
{
    L2SRAM (RWX) : org = 0x800000, len = 0x40000
    OCMC_RAM1 (RWX) : org = 0x40300000, len = 0x80000
    OCMC_RAM2 (RWX) : org = 0x40400000, len = 0x100000
    OCMC_RAM3 (RWX) : org = 0x40500000, len = 0x100000
    EXT_CODE (RWX) : org = 0x95000000, len = 0x100000
    EXT_DATA (RW) : org = 0x95100000, len = 0x100000
    EXT_HEAP (RW) : org = 0x95200000, len = 0x300000
    TRACE_BUF (RW) : org = 0x9f000000, len = 0x60000
    EXC_DATA (RW) : org = 0x9f060000, len = 0x10000
    PM_DATA (RWX) : org = 0x9f070000, len = 0x20000
}

SECTIONS
{
    .text: load >> EXT_CODE
    .ti.decompress: load > EXT_CODE
    .stack: load > EXT_DATA
    GROUP: load > EXT_DATA
    {
        .bss:
        .neardata:
        .rodata:
    }
    .cinit: load > EXT_DATA
    .pinit: load >> EXT_DATA
    .init_array: load > EXT_DATA
    .const: load >> EXT_DATA
    .data: load >> EXT_DATA
    .fardata: load >> EXT_DATA
    .switch: load >> EXT_DATA
    .sysmem: load > EXT_DATA
    .far: load >> EXT_DATA
    .args: load > EXT_DATA align = 0x4, fill = 0 {_argsize = 0x64; }
    .cio: load >> EXT_DATA
    .ti.handler_table: load > EXT_DATA
    .c6xabi.exidx: load > EXT_DATA
    .c6xabi.extab: load >> EXT_DATA
    .tracebuf: load > TRACE_BUF
    .errorbuf: load > EXC_DATA
    .vecs: load > EXT_CODE
    .resource_table: load > 0x95000000, type = NOINIT
    xdc.meta: load > EXT_DATA, type = COPY

}

Now the question: What do I need to do if I want to use the IPC example as it is, but using the dedicated internal memory of the DSP?

I guess I need to modify the linker.cmd file to map all sections to L2SRAM and then remove all DSP_MEM_TEXT, DSP_MEM_DATA and DSP_MEM_HEAP from the resource table. Is that correct?

Just out of curiosity: What happens if I change the linker.cmd file to use the internal L2SRAM and also add the L2SRAM addresses as carveouts in the resource table?

From the remoteproc driver perspective it looks like the elf loader would place the DSP firmware into the correct physical L2SRAM location, however also the MMU would then be configured to map the address 0x800000 to the main memory. What would be the behavior then? Is it even possible to mmu-map the address 0x800000 to the main memory?

Thanks for your answer!

Regards,
Franz

over 8 years ago

0 Biser Gatchev-XID over 8 years ago

TI__Guru**** 393215 points

The software team have been notified. They will respond here.

0 Garrett Ding over 8 years ago in reply to Biser Gatchev-XID

TI__Mastermind 43296 points

Hi Franz,

On 4.4+ kernels, OMAP (AM57x) remoteproc driver supports the internal memory loading, and the internal memory regions need to be supplied through the DT. Older versions specifically required the RSC_INTMEM resource to be supplied through the resource table, and required the patch lists.infradead.org/.../270534.html. If the linker.cmd is updated properly, you should be able to run everything from INTMEM. I am trying to find an example that demonstrates the use case.

Regards,
Garrett

0 Franz Franz over 8 years ago in reply to Garrett Ding

Prodigy 50 points

Hi Garrett!

Thanks for your answer! That's what I already expected. So it should be sufficient (on 4.4+ Kernels) to just delete the TYPE_CARVEOUT entries (DSP_MEM_TEXT, DSP_MEM_DATA and DSP_MEM_HEAP) from the rsc table and adapt the linker.cmd file accordingly?

Thanks, regards,
Franz

0 Suman Anna over 8 years ago in reply to Franz Franz

TI__Guru** 113435 points

Hi Franz,

Yes, that should be sufficient. Do note that the current remoteproc infrastructure doesn't support vrings or vring buffers to be placed in a remote processor's internal memory, so vrings and vring buffers for the virtio rpmsg transport would still need to be using external DDR. The resource table should still have the DSP_MEM_IPC_VRING entry. DSP_MEM_IPC_DATA entry is used for remoteproc traces, so unless you also relocate and link it against internal memory, you will need to continue to maintain the corresponding resource table entry.

Regarding your other question about adding L2SRAM as a CARVEOUT, it would be a no-op. The DSP MMUs do cover the entire 4 GB space, so the remoteproc will allocate DDR memory and map that memory into the MMU using the L2SRAM addresses, but no accesses from DSP will ever reach the MMU using that address. The DSP CPU address views only go out over the XMC interface starting from 0x12000000. The remoteproc driver does look up the translation for DSP device addresses using the remoteproc platform driver's .da_to_va() rproc ops first, so it will still translate the addresses correctly while loading.

regards
Suman

0 Franz Franz over 8 years ago in reply to Suman Anna

Prodigy 50 points

Hi Suman!

Thanks for your answer! Now it is perfectly clarified!

Regards,
Franz

Processors

Processors forum

Linux/PROCESSOR-SDK-AM57X: DSP internal memory usage