• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 419 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.

CMEM physical start over laps kernel in DVSDK_4 beta

John Anderson
Genius 5240 points

I'm using the DVSDK 4 beta.  I perform a "make everything", then "make install".  I copy the install directory items to my RFS, which is mounted with NFS on the target h/w.

***BTW***, I found out after much frustration a "make all" does not build the ko drivers and I was continually getting module symbol mismatch errors. Grrrr!  The "make install" kep masking the failure to build by updating the time/date on the files in the install directory.

I get this error when executing /usr/share/ti/dvsdk-demos/loadmodules.sh

CMEM phys_start (0x83c00000) over laps kernel (0x80000000 -> 0x85000000)

0x50000000 = about 83MB and that seems like an extraordinarily large kernel size.  Could someone comment on this?

These are my bootargs from u-boot, if that means anything.  I see a mem=80M which suggests to me that maybe I'm reserving too much memory or that I just need to move cmemk's start address.

bootargs console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=$(nfshost):$(rootpath),nolock mem=80M video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K dm365_imp.oper_mode=0 davinci_capture.device_type=4

Also here's the line installing cmemk...

modprobe cmemk phys_start=0x83C00000 phys_end=0x88000000 pools=2x384,1x16384,1x2688,1x20480,3x74,1x60288,2x28,1x147048,1x10240,1x896,1x65536,1x663552,1x9175376,4x24,1x282624,2x5984,1x58144,1x1024,1x48952,1x464,2x16768,1x1251264,1x30720,1x65792,8x774144,1x173712,1x146,1x98,2x296,50x56,2x86,1x624,1x3328,1x518912,4x62,1x242,4x663552,1x1637824,14x1645056,1x16538976,4x1382400

I'm not really sure how to make an intelligent choice about the start and end location. Plus I don't really know how to choose the size and number of buffers to reserve.  Which is what I think the modprobe is doing.

Any help would be appreciated.  At this time the board (DM368) needs to generate a single D1 resolution H.264 stream.  However in the future I would like to stream four D1 h.264 encodes.  Maybe that will put into perspective the size and types of buffers I need.  No HD at this point.

Thanks, John A.

  • 0
    TI__Expert 5680 points

    John,

    Here i assume that you are using DM365 DVSDK, Actually as per "make help", make all only builds the necessary components required to build other targets. e.g linux - which is needed by many target and other components typically comes prebuilt.

    Available build targets are:

        all                          : Build the components for which a rebuild is necessary to enable all other build targets listed below. You must do this at least once upon installation prior to attempting the other targets.

    And you guys think that adding "kernel module" in make all list will help then we can consider doing this for GA release.

    Dvsdk demo, Gstreamer and other apps loadmodules are configured to use the default bootargs recommended by the dvsdk setup scripts.  In case of DVSDK 4.0, you will notice that it recommends "mem=59M" instead of mem=80M. If you  change the bootargs then you also need to make the necessary changes in loadmodules for cmem start and end address.   The above modprobe is failing because cmem has detected memory overlap between what  you passed in cmem_start with the linux kernel memory.   You can find a bit more information about the cmem here [1] .  

    Even though, the link [2] does not  talk about your exact problem but will give you a bit more understanding on how to compute cmem_start address.

    [1] http://processors.wiki.ti.com/index.php/CMEM_Overview.

    [2] http://processors.wiki.ti.com/index.php/HOWTO_Change_the_Linux_Kernel_Start_Address#Updating_CMEM_Memory_Region 

    Hope this helps.

    Thanks

    Brijesh

  • 0
    TI__Expert 3220 points

    Hi John,

    The bootargs don't look like what I have got here, did you run the "setup.sh" script as described in the Software Developer's Guide to set up your development and u-boot environment? If you do, the u-boot environment will line up with the loadmodules.sh scripts in the target filesystem.

    We are looking at how to define the 'make all' vs. 'make everything' targets going forward to make them more intuitive.

    Regards, Niclas

  • 0 in reply to Niclas
    Genius 5240 points

    Niclas, I actually didn't use the setup.sh script, and didn't even know about it.  So thanks.

    The bootargs is from my original development using DVSDK ver 2.  I got sidetracked on other projects and by the time I came back DVSDK 4 beta was out.

    Ultimately I find it more useful to know what the parameters mean, rather than rely on a generic sample.  I plan to capture, encode, and stream 4 D1 h.264 videos, plus support SNMP and a web server in 128MB of dram.  So I may have to cut the buffers to the minimum necessary to do the job.  59MB of ram for the kernel seems like a minimal amount.  If I understand correctly now that is all the memory that Linux sees.  I didn't quite get that in my original post when I said 80MB was a lot.

    I asked our board designer if he could give me 256MB, but he seems to think that is hard to do.  I'm working with our initial prototype board now and not the EVM.

    John A.

  • 0 in reply to Brijesh Singh
    Genius 5240 points

    Brijesh,

    I figured out that "make everything" was what I needed from looking at the makefile.  After just trying "make help" I'd say that it isn't very evident that "make everything" is needed.

    If the file date/time was maintained during the "make install" copy I would have figured out something was wrong much more quickly.  I believe thats the -p option in cp.

    What made it even harder for me was I was building using kernel source in another directory outside the install.  So I started thinking that maybe the DVSDK makefile had a bug in the build script using a different kernel source path.  So then I had to patch the kernel source in .../psp/kernel-source and try building it.  I have a new configuration for our board, so patching was necessary.

    One other question... I see kernel patchs in the DVSDK hierarchy.  Are these patches already applied? Or do they need to be applied.  I suppose I could look for myself, but since we're talking I guess I'll just ask.:)

    John A.

  • 0 in reply to John Anderson
    TI__Expert 5680 points

    John,

    Those patches are already applied on top of PSP 37X releases.

    Thanks

    Brijesh