• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 787 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.

OMAP L-137 Start/Stop DSP and Program DSP application

LUKLEM
Intellectual 275 points

Other Parts Discussed in Thread: OMAP-L137

I'm developing a Linux driver that communicates with the DSP. I've managed to map all DSP memory to userspace and I'm able to trigger and receive interrupts. I know that normally DSP Link is used to perform these actions but we are unable to use DSP Bios because it introduces a variable delay in the DSP application. Since we are not using DSP Bios the DSP Link is also not an option.

It's a known fact that the ARM UBL in it's normal behavior disables the DSP (put in wait-and-reset). In my assumption the DSP is reset and then the power to the device is cut using the Power Sleep Control. The DSP device is put in SwRstDisable so no clock and power goes to the device.

  •  Is this assumption about the DSP power and reset correct or not?

Does this mean that when I want to enable the DSP I have to write to PSC0 @ 0x01c0 0800 in register MDCTL15;
MDCTL[15] = ((MDCTL[15]) & (0xFFFFFFE0)) | (0x3); //0x3 stands for PSC_ENABLE
Then have to write in the PTCMD register of PSC0;
PTCMD |= (0x00000001 << 1); //shift 1 for domain 1
And then reset the DSP to start the execution by writing;
MDCTL[15] &= ~0x100;

  • Is this correct what I'm writing here? I used the ARM UBL code as reference but could not figure out what the domain parameters is in the DEVICE_LPSCTransition() function.
  • Is it better to first reset the DSP and then change the LPC or the other way around? I'm willing to enable the DSP.

I want to add this functionality to my Linux driver.

  • Has anyone experience with controlling the PSC and LPSC registers from within a Linux driver? I assume I can approach these registers the same way I'm approaching CHIPSIG for the interrupts using ioremap( 0x...,1).

Next to this the code currently in the DSP is the DSP UBL. This code needs to be replaced with my own application. Has anyone here experience with programming the DSP from within Linux. I've already managed to map the memory to userspace.

  • Has anyone experience with parsing the .out (coff) file and programming it into memory?
  • Has anyone an idea how the DSP can be programmed the easy way. I've only thought about parsing the coff file and writing that to the DSP L2PRAM, but maybe there is an easier solution I'm missing.

Thanks in advance,

  • 0
    Prodigy 150 points

    Hello LUKLEM,

    I have written a driver that does exactly this for the OMAPL137. I have solved it by using the existing firmware-framework in the kernel that allows a driver to request firmware from userspace via sysfs. I then load this firmware into a reserved section of the SDRAM, so the whole program is run from SDRAM.

    For this to work you have to modify the linker script and put all sections in the SDRAM, although i guess you could run it from IRAM aswell. Then use another linker script of the following form:

    -b
    -image
    -zero

    ROMS
    {
      SDRAM: org = 0xc3c00000, len=0xFF000
    }

    In combination with the hex6x.exe to convert the coff file into binary. You also need to somehow keep track of the entry point address. I have solved it by storing the .map file on the target and parsing the entry point from the file when loading the driver. Unless you somehow manage to align the entry point on a 4k border you have to install some trampoline code that can jump to the correct entry point. I will see if I can make the source code available somewhere.

  • 0 in reply to Tobias Knutsson
    Intellectual 275 points

    Hello Tobias,

    Ok, that sounds like proper solution. If you have problems publishing the source code I can provide you my e-mail address or ftp server.

    I'm very interested in the starting, stopping and programming the DSP source code to use as reference / example for my own code.

    Best regards

  • 0 in reply to LUKLEM
    Intellectual 275 points

    Hello Tobias,

    I just noticed the "options" tab on the reply page, here you can add attachments to your post.

    Regards,

  • 0 in reply to LUKLEM
    Prodigy 150 points

    Oh right, I missed that one.

    The file had to have a .txt extension for some reason.. Anyway, I hope it will be useful for you!

  • 0 in reply to Tobias Knutsson
    Prodigy 190 points

    Thank you guys!   I am pursuing the same endeavor.    Your chunk of code and well formed question has saved me the trouble of duplicating the effort on my own.

     

    Thank you,

     

    Rob Stoddard

  • 0
    Prodigy 20 points

    Hi LUKLEM,

    I learn to use omap-l137 currently, so I can't understand how to manage to map all DSP memory to userspace and  to trigger and receive interrupts exactly.

    From your article, I know that you have done that perfectly, would you like to share the experience or "map" code with me?

    thanks & best wishes!

    --

    LiBin