• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 281 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.

c6Run MMU error

ljiljan86
Prodigy 60 points
Other Parts Discussed in Thread: OMAP3530, OMAP-L138

My understanding is that c6run project is suppose to cover DSPlink and not let you worry about specifics of it. I seccessfully compiled all the examples and when running them on the DSP get the MMU fault error. Followed all the instructions in C6.  I already read the about the where the error comes from but the examples should be ready to run as they are in C6 without changing anything. Not sure what to do....

 

Running OMAP3530 on Gumstix Overo

 

Boot settings:

mmc init

fatload mmc 0 0x80000000 uImage

setenv bootargs console=${console} vram=${vram} mem=120M omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=${defaultdisplay} root=/dev/mmcblk0p2 rw

rootfstype=ext3 

bootm 0x80000000

 

Load the CMEM module here:

 

DSP_REGION_START_ADDR="0x8c800000"

DSP_REGION_END_ADDR="0x8E500000"

 

insmod cmemk.ko phys_start=0x87800000 phys_end=0x89500000,pools=20x4096,10x13107,2x1048576 

 

 

 

# Insert DSP/BIOS Link driver

if [ -e ./dsplinkk.ko ]; then

  insmod ./dsplinkk.ko

else

  modprobe dsplinkk

fi

 

# make /dev/dsplink

rm -f /dev/dsplink

mknod /dev/dsplink c `awk "\\$2==\"dsplink\" {print \\$1}" /proc/devices` 0

 

# Insert LPM driver

if [ -e ./lpm_omap3530.ko ]; then

  insmod ./lpm_omap3530.ko

else

  modprobe lpm_omap3530

fi

 

# make /dev/lpm0

rm -f /dev/lpm0

mknod /dev/lpm0 c `awk "/lpm/ {print \\$1}" /proc/devices` 0

 

  • 0
    TI__Genius 17355 points

    I would recommend trying the latest version of the C6Run package.  You can get it here.

     

    Also, it looks like the parameters being used for the memory map are not quite right. Please make sure you are following step 6 of these instructions.  If you specify the memory region for the DSP as per that step, the loadmodules.sh script in "<C6Run_Install_Dir>/platforms/<platform_name>/" will be modified with the correct settings and can be used to do the module loading on the target system without any further edits.

     

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 60 points

    Thanks for the reply  Daniel. I got the example codes to run successfully.  Doing that I noticed that the same code, like bench example, runs faster on the ARM than the DSP. 

     

     

    N=16, nTimes=100: Dot with C code         => time:0 s

    N=16, nTimes=100: Distance with C code    => time:0.002 s

    N=32, nTimes=100: Dot with C code         => time:0.001001 s

    N=32, nTimes=100: Distance with C code    => time:0.003 s

    N=64, nTimes=100: Dot with C code         => time:0.002 s

    N=64, nTimes=100: Distance with C code    => time:0.004 s

    N=128, nTimes=100: Dot with C code         => time:0.003 s

    N=128, nTimes=100: Distance with C code    => time:0.007 s

    N=256, nTimes=100: Dot with C code         => time:0.006 s

    N=256, nTimes=100: Distance with C code    => time:0.014 s

    N=512, nTimes=100: Dot with C code         => time:0.01 s

    N=512, nTimes=100: Distance with C code    => time:0.028 s

    N=1024, nTimes=100: Dot with C code         => time:0.021 s

    N=1024, nTimes=100: Distance with C code    => time:0.056 s

    N=2048, nTimes=100: Dot with C code         => time:0.042 s

    N=2048, nTimes=100: Distance with C code    => time:0.111 s

    N=4096, nTimes=100: Dot with C code         => time:0.085 s

    N=4096, nTimes=100: Distance with C code    => time:0.221 s

    N=8192, nTimes=100: Dot with C code         => time:0.168999 s

    N=8192, nTimes=100: Distance with C code    => time:0.441 s

    N=16384, nTimes=100: Dot with C code         => time:0.341 s

    N=16384, nTimes=100: Distance with C code    => time:0.884 s

    root@overo:/c6/examples/c6runapp/emqbit# ./bench_arm

    N=16, nTimes=100: Dot with C code         => time:0.000122 s

    N=16, nTimes=100: Distance with C code    => time:0.000428 s

    N=32, nTimes=100: Dot with C code         => time:0.000244 s

    N=32, nTimes=100: Distance with C code    => time:0.000671 s

    N=64, nTimes=100: Dot with C code         => time:0.000397 s

    N=64, nTimes=100: Distance with C code    => time:0.001281 s

    N=128, nTimes=100: Dot with C code         => time:0.000793 s

    N=128, nTimes=100: Distance with C code    => time:0.002594 s

    N=256, nTimes=100: Dot with C code         => time:0.001709 s

    N=256, nTimes=100: Distance with C code    => time:0.005066 s

    N=512, nTimes=100: Dot with C code         => time:0.003479 s

    N=512, nTimes=100: Distance with C code    => time:0.01001 s

    N=1024, nTimes=100: Dot with C code         => time:0.006287 s

    N=1024, nTimes=100: Distance with C code    => time:0.019928 s

    N=2048, nTimes=100: Dot with C code         => time:0.012634 s

    N=2048, nTimes=100: Distance with C code    => time:0.042755 s

    N=4096, nTimes=100: Dot with C code         => time:0.024781 s

    N=4096, nTimes=100: Distance with C code    => time:0.079315 s

    N=8192, nTimes=100: Dot with C code         => time:0.05014 s

    N=8192, nTimes=100: Distance with C code    => time:0.159057 s

    N=16384, nTimes=100: Dot with C code         => time:0.099914 s

    N=16384, nTimes=100: Distance with C code    => time:0.319275 s

     

     

    Any clue as to why this is? Is it the way the code was written or my mem allocation? 
    This is what did when laoding the cmem module.
    insmod cmemk.ko phys_start=0x87800000 phys_end=0x89500000,pools=20x4096,10x13107,2x1048576 
    Thank You.

  • 0 in reply to ljiljan86
    TI__Genius 17355 points

    This benchmark code was originally used on an OMAP-L138 part, which is an ARM926 and C674x fixed- and floating-point DSP, so the code shows the advantage of executing floating point code on the DSP of that part.  The OMAP35x part is a Cortex A8 and C64x+ fixed-point DSP.  Therefore, I would expect the ARM to perform better than the DSP on floating point code, since in this case the ARM core has floating point hardware, and the DSP does not. 

    We need to update the package to include many more fixed-point benchmarks and examples so that we can better showcase the power of the DSP on the OMAP3 platforms. Note that TI's DSP roadmap going forward is for fixed- and floating-point DSPs in all devices containing a C6000 core (no more fixed-point only).

    Regards, Daniel