• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1113 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.

DM3730 Linux Real Time Extensions

Mark Ackerson
Genius 10190 points
Other Parts Discussed in Thread: DM3730

Customer is seeing significant variability in DM3730 FFT execution time from call to result.  The customer is pretty convinced that the variability is not due to delays in the DSP, but due to the Linux Kernel taking a break from user tasks to do Kernel tasks.  They have whittled down the Kernel a great deal and in doing so have minimized the problem, effectively cutting the deltas in half, but this is still an enormous delay.  I think the solution may require running the Linux Real-time patch.  I have looked for the patch to Linux version 2.6.37 and I am not able to find it.  Are you aware of a real-time Linux version that works with TI's DSP tools?  What can you tell me about a real time Linux version and the TI tools?

 

Thanks,

Mark

  • 0
    TI__Guru*** 125430 points
    Maybe they should try something like "cat /proc/interrupts" to get an idea of what "stuff" is happening at least at the hardware level. The other main thing that comes to mind is the file system. Are they booting from an SD card? A really simple test (which I'm not sure if it will make any difference) is to see if they turn on the read-only switch of the card if that makes any impact on things. Another thought is to try with NFS root file system. Perhaps most difficult would be to setup a minimal RAM disk.
  • 0 in reply to Brad Griffis
    TI__Genius 10190 points
    They are running this system via the NFS root file system. Here are the interrupts. Can any of these be safely disabled?

    dm37x-evm login: root
    root@dm37x-evm:~# cat /proc/interrupts
    CPU0
    7: 0 INTC TWL4030-PIH
    11: 0 INTC prcm
    12: 4 INTC DMA
    20: 0 INTC gpmc
    24: 0 INTC omap-iommu.0
    25: 2 INTC OMAP DSS
    37: 830 INTC gp timer
    56: 303 INTC omap_i2c
    57: 0 INTC omap_i2c
    61: 0 INTC omap_i2c
    72: 234 INTC serial idle, OMAP UART0
    73: 0 INTC serial idle
    74: 0 INTC serial idle
    80: 0 INTC serial idle
    83: 42 INTC mmc0
    86: 13 INTC mmc1
    336: 2980 GPIO eth0
    369: 0 twl4030 twl4030_keypad
    376: 0 twl4030 twl4030_pwrbutton
    379: 0 twl4030 rtc0
    384: 0 twl4030 mmc0
    Err: 0
  • 0 in reply to Mark Ackerson
    TI__Guru*** 125430 points

    It looks like by FAR the biggest number of interrupts comes from "GPIO eth0".  Since DM3730 doesn't have an integrated ethernet MAC that means all the ethernet is implemented with an external MAC-PHY connected to the GPMC as well as a GPIO.  Perhaps they should try a local file system via SD card to see if that impacts things.

    The GP timer is expected.  The I2C might be worth a touch more investigation.  It's a pretty small number of interrupts (303).  Could they perhaps check that number before and after their test?  I'm trying to understand if that's all initialization related or if there is significant run-time activity on the I2C.  That *might* be related.  One thought that comes to mind is whether there is any kind of CPU frequency scaling going on.  Can you have them check which governor is being used?  The command should be something like this:

    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  • 0 in reply to Brad Griffis
    TI__Genius 10190 points
    Hi Brad,

    Thanks for the suggestions. The customer found the issue based on your advice. See details below.
    I continued to monitor /proc/interrupts and I noticed that after I ran my application the timer interrupts went up dramatically. I had been initializing the PCRM as I had been when I was working on the bare metal system – I’m not sure exactly what in my initialization caused the problem, but I suspect I increased the rate of one of the timers that that was being used by Linux and as a result spent a LOT more time in the timer ISR than is typical. I have since stopped that initialization and both the variability and the total duration of my test procedure have come down significantly. I now have a reliable and efficient system on which I am building my application.

    Regards,
    Mark