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

Working with 256MB SDRAM and Codec Engine

Glenn Wainwright
Expert 1605 points
Other Parts Discussed in Thread: DM3730, OMAP3530

I'm on a DM3730 board with 256MB SDRAM instead of the normal 128MB.  

Following the guides, my bootargs are set up as:

setenv bootargs mem=99M@0x80000000 mem=128M@0x88000000 console=ttyS0,115200n8 noinitrd rw ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:on root=/dev/nfs nfsroot=${serverip}:/home/glennw/workdir/filesys,nolock,rsize=1024,wsize=1024 psplash=false vram=10M omapfb.vram=1:10M omapfb.debug=y

... and my CMEM insmod is:

insmod cmemk.ko phys_start=0x86300000 phys_end=0x87200000 pools=1x327680,15x614400,2x1228800,2x128000,3x962560,20x4096 allowOverlap=1

However, when I load the codec server, I get a kernel panic:

 

@2,591,186us: [+2 T:0x4324d490] OP - Processor_create_d> Attaching to DSP PROC...                                                                               
@2,595,001us: [+2 T:0x4324d490] OP - Processor_create_d> Opening MSGQ pool...   
@2,595,275us: [+2 T:0x4324d490] OP - Processor_create_d> Loading cs.x64P on DSP 
(1 args)...                                                                     
Unable to handle kernel paging request at virtual address e2000000              
pgd = cd028000                                                                  
[e2000000] *pgd=00000000                                                        
Internal error: Oops: 5 [#1]                                                    
last sysfs file: /sys/devices/platform/omapdss/overlay0/manager                 
Modules linked in: sdmak lpm_omap3530 dsplinkk cmemk

This does not occur if I stick with mem=99M, but as soon as I have a second mem block above CMEM's space, it panics on me.  What piece of configuration could I be missing to get this working?

Thank you,

Glenn Wainwright

 

  • 0
    TI__Mastermind 18260 points

    Glenn,

    There is more hard-coded DDR memory usage with Codec Engine applications than just CMEM.  Typically the DSP server executable has been hardcoded with DDR2 usage for all code/data, DSPLink areas for pools and shared memory, and heaps, and this is most likely clashing with the 2nd kernel block.

    Take a look at your DSP server's memory map (a .map file is usually produced, or you can look in the configuration), then take the steps needed to avoid clashing with the kernel (which could mean reducing hard-coded usage for CMEM and/or the server and/or DSPLink, but probably easier to just bump the 2nd kernel block's base past all server memory usage).

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1605 points

    Yes, that was my first thought as well, so I tested the bootargs leaving a ridiculously large hole for the DSP etc (mem=99M@0x80000000 mem=32M@0x8E000000).  Unfortunately, that gave me the same result as before.

    One interesting item that seems inconsistent... CMEM seems to think that the kernel memory is contiguous.  For example, in the situation above, CMEM on init spits out:

    CMEM Range Overlaps Kernel Physical - allowing overlap                          
    CMEM phys_start (0x86300000) overlaps kernel (0x80000000 -> 0x88300000)         
    allocated heap buffer 0xd2000000 of size 0x79000     

    Whereas the real kernel memory should be going from 0x8000000 -> 0x8630000 and 0x8E000000 -> 0x90000000.  I don't know if it's just reporting start pos + size without thinking about the real memory locations or if this is some kind of clue.  Probably the former, but I thought I'd mention it.

    In any case, it doesn't seem to be the DSP memory running into my second segment.  Anything else I should be looking at?

    Thanks,

    Glenn Wainwright

  • 0 in reply to Glenn Wainwright
    TI__Mastermind 18260 points

    That's right, CMEM thinks the kernel memory is contiguous, it is a very crude check but hopefully it helps someone find a problem more often than it is misleading.

    Did you find out the DSP memory map?  I realize that you tried an experiment to rule that out, but I would feel more confident in that not being the problem if we can see your actual DSP memory usage.  If it's not that, I don't have any other clues.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1605 points

    Yeah, no problem.  It's pretty much default so no surprises there...

             name             origin     length       used     unused   attr     fill

    ---------------------- --------   ---------   --------   --------   ----   --------

      IRAM                   107f8000   00008000   000055c0   00002a40  RWIX

      CACHE_L2         10800000   00010000   00000000   00010000  RWIX

      CACHE_L1P             10e00000   00008000   00000000   00008000  RWIX

      L1DSRAM               10f04000   00010000   00010000   00000000  RWIX

      CACHE_L1D             10f14000   00004000   00000000   00004000  RWIX

      L4CORE                 48000000   01000000   00000000   01000000  RWIX

      L4PER                 49000000   00100000   00000000   00100000  RWIX

      RESET_VECTOR     87300000   00001000   00000000   00001000  RWIX

      DSPLINKMEM            87301000   000ff000   00000000   000ff000  RWIX

      DDRALGHEAP     87400000   00900000   00900000   00000000  RWIX

      DDR2 87d00000   00300000   002b7191 00048e6f  RWIX