• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1684 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSP L2SRAM allocation

G T
Expert 1940 points
Other Parts Discussed in Thread: SYSBIOS

I am trying to allocate DSP L2SRAM in DSP1 firmware on a DRA72x processor. ARM is running on Linux and DSP1 is on TI RTOS.

For this I updated the platform package using CCS6 RTSC tools and allocated entire L2 as SRAM with nothing for L2 Cache.

My resulting linker.cmd has these sections in it.

MEMORY
{
L2SRAM (RWX) : org = 0x800000, len = 0x47fff
EXT_CODE (RWX) : org = 0x95000000, len = 0x400000

------

------

}

SECTIONS
{
.text: load >> EXT_CODE
.ti.decompress: load > EXT_CODE
.stack: load > EXT_HEAP
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 = 0x0; }
.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
.fastiramdata: load > L2SRAM
.vecs: load > EXT_CODE
.resource_table: load > 0x95000000, type = NOINIT
xdc.meta: load > EXT_DATA, type = COPY

}

DSP firmware build succeed and I can see stuff in .map file matching what I allocated, but remoteproc is failing when it tries to load DSP1 firmware and as a result DSP is in offline state.

The following is the log I see when remoteproc tries to load DSP firmware.

[ 4.096124] remoteproc2: powering up 40800000.dsp
[ 4.096155] remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 6703864
[ 4.270851] remoteproc2: bad phdr da 0x800000 mem 0x4000
[ 4.270879] remoteproc2: Failed to load program segments: -22
[ 4.764514] remoteproc2: rproc_boot() failed -22
[ 4.764595] remoteproc2: registered virtio3 (type 7)

It looks to me, like for some reason, L2SRAM is not being set properly or something.

Any ideas what might be going wrong here?

 

Thanks,

Girish

 

  • 0
    TI__Guru*** 125430 points

    Girish Tummala said:

    The following is the log I see when remoteproc tries to load DSP firmware.

    [ 4.096124] remoteproc2: powering up 40800000.dsp
    [ 4.096155] remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 6703864
    [ 4.270851] remoteproc2: bad phdr da 0x800000 mem 0x4000
    [ 4.270879] remoteproc2: Failed to load program segments: -22
    [ 4.764514] remoteproc2: rproc_boot() failed -22
    [ 4.764595] remoteproc2: registered virtio3 (type 7)

    This makes sense.  The address 0x00800000 is part of the DSP's private address space.  This should be address 0x40800000 in the global address map.

    In the past, I've generally recommended that the memory map should be created using the global address (0x40800000) rather than the local address (0x00800000).  That avoids a lot of issues such as this one.  I think we need someone from the BIOS team to comment on why the generated code is using the private address instead of the global address.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    I have moved this thread to the TI-RTOS forum so the sysbios team can comment on why the generated linker command file is using referencing a private address rather than a global address.

  • 0 in reply to Brad Griffis
    Expert 1940 points

    Brad,

    I updated the platform package to use global address for L2SRAM. But I am still seeing the same error while loading DSP1 firmware even when the memory map shows global address.

    [ 4.867757] remoteproc2: powering up 40800000.dsp
    [ 4.867787] remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 6703864
    [ 4.921444] remoteproc2: bad phdr da 0x40800000 mem 0x4000
    [ 4.921471] remoteproc2: Failed to load program segments: -22
    [ 5.367063] remoteproc2: rproc_boot() failed -22
    [ 5.367150] remoteproc2: registered virtio3 (type 7)

    Also, now the linker.cmd file and .map file reflect this updated global address change.

    Thanks,

    Girish

  • 0 in reply to G T
    TI__Guru*** 125430 points
    I moved this back to the DRA forum since you figured that out. Has some kind of config option been added to choose local vs global? It's been a while since I looked at that piece of the puzzle.

    So going back to your specific issue. First, the specific file of code that deals with this issue is <linux>/drivers/remoteproc/omap_remoteproc.c. And in fact, there's a function specifically related to internal memory... Please see omap_rproc_of_get_internal_memories(). There's a huge comment block in that code discussing the L2 memory.

    A couple items come to mind looking at this code:

    1. It looks like it is specifically looking for a section called "l2ram". So that looks to be one issue, i.e. your section is called L2SRAM and not l2ram.
    2. I think my initial suggestion to use the global address is not the right thing here. This code very much looks to be expecting the L2 at an offset of 0x00800000, which perhaps that makes sense because that is true of all 6000 DSPs. So please change that back to the local address and see if you can change the name.

    If this doesn't work right away, you should probably add a few extra prints into this code so we can understand where things are going awry.
  • 0 in reply to Brad Griffis
    Expert 1940 points
    I looked at omap_remoteproc.c file and that function doesn't even exist in the version I am currently using.
    The Linux Kernel I am using is 3.14.63.
    Am I missing some functionality/support here?

    I modified the name to match l2ram, but still seeing the same failure.
    I will add some prints and see if I can find out what is going on.

    -Girish
  • 0 in reply to G T
    TI__Guru*** 125430 points
    I assumed you were on Proc SDK Auto 3.01 (latest release) which uses a 4.4 kernel. Looks like you're using GLSDK 7.04? I recommend that you pull the latest updates from the ti-linux-3.14.y branch. The function I mentioned from the 4.4 kernel actually exists in 3.14 as well, but in an updated version of the branch:

    git.ti.com/.../omap_remoteproc.c

    This specific commit added the function I mentioned:

    git.ti.com/.../omap_remoteproc.c

    At a bare minimum I think you'll want to pull this latest kernel as I don't see any chance of this working without these functions!

    Brad