• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 102 subscribers
  • Views 5137 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Linux/OMAP-L138: Processor SDK: Linux on ARM cannot coexist with McASP Example on DSP

Jeffrey Limbocker
Expert 2360 points
Part Number: OMAP-L138

Tool/software: Linux

Hello,

This is an issue I have had for some time in various permutations, but I had hoped that the new SDK would remedy some of the issues.  As the title suggests, I am attempting to run the McASP example project on TI-RTOS on the DSP while running Linux on the ARM.  Previously (using MCSDK) I had run into problems related to the EDMA, and I am hopeful that the new EDMA driver for Linux will remove those problems.  Currently, the problem I am having is not related to the DMA, but to the LPSC.  If I run the DSP code by itself, the program passes audio in to out.  If I load Linux, then load the DSP through CCS and run the code, the code times out during McASP configuration (McASP_drv.c[4084]).  This appears to be due to the LPSC not being enabled for the McASP.  I verified that the LPSC Status is different between the two scenarios.  When the DSP code runs alone, the LPSC is enabled.  When Linux is active, the LPSC is disabled.  

I suspected that the Linux DTB may have something to do with it, so I have tried two variants of the Device tree for Linux.  In the first, the McASP is "disabled", and in the second the McASP is "okay".  In both cases, the LSPC for the McASP is disabled.  In my kernel configuration, the sound drivers are modules and the modules are not loaded.

The eventual goal will be to have the two programs running with IPC between them, where the DSP is loaded from the ARM.  The documentation on this seems somewhat hard to find for the new SDK, as they tend to refer to other device families (Keystone II).  I was, however, able to run the IPC examples.

Does anyone have any insight on how I might get Linux and RTOS to run simultaneously?  Are there recommended practices for sharing DMA resources?

Where should I look for documentation on starting DSP applications from the Linux userspace?

I am happy to provide more information as needed.

Jeff

  • 0
    TI__Guru**** 161600 points
    Hi Jeff,

    This should be possible. However, I am not sure that you can get this working without IPC.
    From linux point of view, you need to have the IPC communication between DSP & ARM, so that you can configure the MCASP module (clocks, device pads, etc...).

    Does your DSP app contain the LPSC settings? I suspect yes (because the MCASP app can run as bare metal program), I also suspect that it is trying to access lpsc configuration region that is locked by kernel => it times out.

    I am looping the RTOS experts to elaborate.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 2360 points
    That makes good sense. The DSP app does contain all of the necessary configuration for the application to run by itself, McASP, LPSC, etc. In this case, would it be that the ARM would control all configuration of the device and the DSP would simply wait until the ARM communicates that everything is ready? I'm pretty new to IPC in general, so I'm still wrapping my head around the mechanics of it all.

    Jeff
  • 0 in reply to Jeffrey Limbocker
    TI__Guru**** 161600 points
    Hi Jeff,

    In this case, would it be that the ARM would control all configuration of the device and the DSP would simply wait until the ARM communicates that everything is ready?

    Yes, this is one, maybe the easier, option.
    The other option is to leave the whole mcasp initialization in the dsp code & integrate your app as a xe674 binary and load it through remoteproc (the same procedure as loading the DSP firmware).

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 2360 points
    Since the application currently configures all of the hardware, I feel it may be simpler/faster to just remove the steps that are essential to do in Linux (LPSC, etc) and leave the McASP configuration in RTOS. I re-enabled the McASP in the device tree, but the psc has not been enabled. Where in the linux source are the LPSCs set up? It's still unclear to me what exactly is controlled by the device tree. I thought it replaced the board files under arch/arm/mach-davinci and served as the entire description of the hardware for linux.

    Jeff
  • 0 in reply to Jeffrey Limbocker
    Expert 2360 points
    An update:

    After manually configuring the PSC using the memory editing capabilities of the debugger, disabling the Linux audio driver, and manually loading the DSP, I have the audio example running at the same time as Linux. Next I need to get Linux to set up the PSC, and for some reason GPIO isn't working from Linux anymore, so that will need to be fixed.

    Jeff
  • 0 in reply to Jeffrey Limbocker
    Expert 2360 points
    GPIO was due to DSP modifying PINMUX -> Now working.

    Any help getting Linux to set the PSC is appreciated.

    Jeff
  • 0 in reply to Jeffrey Limbocker
    Prodigy 135 points

    Hi Jeff!

    I'm working on similar task. We have the app that runs on DSP and utilizes McASP for sound capturing/playback, along with Linux running in ARM core.

    Our McASP interface was borrowed from sources in PDK, and those drivers use DMA for audio data transfers. We use remoteproc to load the DSP binary from under Linux.

    We use our own code to initialize PSC in DSP part, so McASP is getting powered on from DSP, having audio driver disabled in Linux.

    For the last week I was struggling with IRQ DSP/ARM conflict, which I wasn't able to resolve yet. Seems like the DMA IRQs sharing problem.

    I would be very grateful if you answered some questions, I'm really stuck on this :(

    What sample do you use for working with McASP? Did I understand you right, that you've succeeded to run the McASP example project (which one exactly?), with no DMA problems? How many channels does your McASP example use? We use both input and output channels.

    Have you run into any IRQ problems with your sample project? Do you run Linux from MMC/SD card? The problem is that DMA is used for SD card access in Linux, and it can cause interferences/conflicts when using McASP from DSP and SD card reading/writing from Linux. Did you check these situations?

    Will be very grateful on any hint, since the documentation on these subjects is really scarce or even absent.

  • 0 in reply to Jeffrey Limbocker
    TI__Guru**** 161600 points
    Hi Jeff,

    Your understanding that dts file replaces the board file in older linux kernels is correct. This is exactly what dts is.

    PSC controller is described & controlled with:
    arch/arm/mach-davinci/da850.c
    arch/arm/mach-davinci/psc.c

    Best Regards,
    Yordan
  • 0 in reply to Denis Lukinov
    Expert 2360 points
    Denis,

    Glad to hear I'm not the only one trying this! I had similar problems with the MCSDK. Are you using the MCSDK or the Processor SDK? The EDMA driver for Linux has changed in the new kernel. In the MCSDK, the EDMA driver does not seem to use channel reservation, despite there being a structure in the board file for it. I definitely ran into issues with the DMA between Linux and RTOS. I could start the DSP, but as soon as the Linux kernel loaded the DMA driver, the DSP code would stop receiving interrupts. I never solved this problem - switching to the new kernel/drivers fixed it.

    If you're on the MCSDK (which it seems like you aren't, since you're using remoteproc), I'm not sure I can be much help. If you're on the PSDK, here's my two cents:
    Make sure that your DTS includes the "ti,reserved-slot-ranges" parameter for edma0.
    Make sure the audio driver is not loaded, but that the mcasp is enabled in the DTS.
    You should be able to find which interrupts Linux is using for the DMA in the arch/arm/boot/dts/da850.dtsi file under edma0. In my case, it's using interrupts 11 and 12.
    Make sure that the PSC is actually getting enabled. I've overlooked this more than once. The sample project I used does try to enable LPSC7, but I noticed it was not getting set. To see this, I had to find the MDSTAT register (located at 0x1e2781c) using the memory viewer.

    Can you provide some more information as to how the problem manifests itself? Is some audio passing through, but with dropouts, or is not audio passing?

    As far as my setup, I'm using Processor SDK 4.0. The example project I'm using was generated using the pdkProjectCreate.sh shell script found in the <PDK>/packages/ti directory. The source is located at <PDK>/packages/ti/drv/mcasp/example/lcdkOMAPL138. I'm using serializers 7 and 8 to run stereo in and out over IIS. I'm running linux with network boot (TFTP) and NFS, with plans to transition over to
    NAND flash, so no MMC/SD is running (though it's not disabled). I only experienced problems with audio dropouts when the Linux audio driver was loaded. Apart from that, I have been passing bit-perfect audio in to out with no trouble (after manually enabling the LPSC). That said, I'm not heavily taxing the ARM processor, so that may change...

    Here are some links to forum posts regarding my struggles with the MCSDK version:
    e2e.ti.com/.../2188196
    e2e.ti.com/.../2176997

    I have to agree with you that there's no easy place to find the documentation for all of this. I've heard this is something TI is working on. It's been useful for me to keep a text document with links and descriptions to useful things as I find them.

    I hope this helps. This forum has been good to me thus far and I'm glad to return the favor!

    Jeff
  • 0 in reply to Yordan Kovachev
    Expert 2360 points
    Yordan,

    Thank you for the info. I'll try this and report back with my findings.

    Jeff
  • 0 in reply to Yordan Kovachev
    Expert 2360 points
    The PSC is now enabled on boot. To enable it, I added the flag CLK_PSC to the mcasp_clk structure in da850.c.

    Thank you for you help!
  • 0 in reply to Jeffrey Limbocker
    Prodigy 135 points

    Hi Jeff!

    Thanks a lot for a quick response! I do appreciate your help.

    We started trying IPC since MCSDK, but came across the same restrictions/conflicts with DMA. The way we went is much alike yours, with same pitfalls and difficulties. But it was not DMA that stopped us then. It was IPC/SysLink, which seemed to have not enough support for L138 board on those SW versions.

    So now we're using the PSDK v4, and IPC situation is much much better here. At least it's not a pain anymore to build and load the slave app for running on DSP.

    Now for your hints:

    1. DTS has been modified, we've added "ti,edma-reserved-slot-ranges" statement to &edma0 device, reserving the first two slots: <0 2>. BTW, the syntax is exactly "ti,edma-reserved-slot-ranges", while your variant has "edma-" prefix skipped. Also I did some modifications to linux kernel to output some debugging info from edma driver, to check if the reservations are properly done.

    2. The latest problem I encountered is as follows: Once the application starts the recording from McASP, the following message gets displayed by Linux:

    edma 1c00000.edma: dma_ccerr_handler: Error interrupt without error event!

    And DSP app freezes. Seems like the DSP doesn't handle the error IRQ itself.

    As far as I see, there are two major differences in our setups:

    - The Linux boot source;

    - The IPC and the DSP loading method.

    Also we have slightly modified version of LCDK board, with removed Ethernet chip and some other hardware on SPI bus.

    Different HW setups we have seem to be the cause of different behavior. If you by any chance could check how the example works with read/write access to a SD card from Linux, it would be magnificent. 

    Regards, Denis