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.

DM6446 -> DM355 LoadModules issue

Hello,

I've had the demos running successfully with a DM6446 EVM, and am now trying to get a DM355 EVM working.  I am re-using the same linux host running redhat with a TFTP server and NFS configuration.  I have not installed any of the software from the DM355 as I understand it is the same.  Both are running u-boot 1.2.0.  Both are running a pre-built linux image from the same location, dvsdk_1_30_01_41/PSP_01_20_00_014/bin/dmXXXX/uImage-dmXXXX.  I modified Rules.make to have platform=dm355, and I have done a 'make clean', 'make', 'make install'.  On the DM355, I get the following error at loadmodules:

 

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

root@192.168.0.11:/opt/dvsdk/dm355# ls

cmemk.ko  decode.txt    encode        encodedecode.txt  mapdmaq

data      dm350mmap.ko  encode.txt    interface         thirdpartydemos

decode    dvevmdemo     encodedecode  loadmodules.sh    web

root@192.168.0.11:/opt/dvsdk/dm355# ./loadmodules.sh

cmemk: disagrees about version of symbol class_simple_device_add

cmemk: Unknown symbol class_simple_device_add

cmemk: disagrees about version of symbol class_simple_destroy

cmemk: Unknown symbol class_simple_destroy

cmemk: disagrees about version of symbol class_simple_create

cmemk: Unknown symbol class_simple_create

insmod: error inserting 'cmemk.ko': -1 Unknown symbol in module

insmod: error inserting 'dm350mmap.ko': -1 File exists

root@192.168.0.11:/opt/dvsdk/dm355# lsmod

Module                  Size  Used by

dm350mmap               5204  0

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

 

Any thoughts where I can look?

Thanks in advance!

  • In general these cmem 'disagrees about version of symbol xxxx' type of errors mean that you have some versioning issue, in particular there is probably a version difference between the kernel and cmemk.ko. This being said it may be worth trying to rebuild and boot the kernel over TFTP with the particular DVSDK version you are using (the prebuilt should work but rebuilding it yourself is more certain), I believe the cmemk.ko is copied over fresh from your DVSDK install with the 'make install' command so that should be up to date.

  • Wiley Black said:

    Both are running a pre-built linux image from the same location, dvsdk_1_30_01_41/PSP_01_20_00_014/bin/dmXXXX/uImage-dmXXXX. 

    You mean similar location in under PSP tree correct?  Linux kernel's, although build from the same souce tree (using different options), are different for DM355 and DM6446 respectively.  I have sucessfully ran the demos (and loadmodules.sh) using this dvsdk in both DM355 and DM6446, so I am sure we can help you figure this out.  As Bernie suggested, it is likely a kernel mismatch with cmemk.ko

  • Yes, it is a different linux kernel for each EVM, both copied from the PSP path as:

    dvsdk_1_30_01_41/PSP_01_20_00_014/bin/dm355/uImage-dm355

    And

    dvsdk_1_30_01_41/PSP_01_20_00_014/bin/dm6446/uImage-dm6446

     

    Executing this command:     

    strings cmemk.ko | grep vermagic

    Yields, in the DM355 folder: vermagic=2.6.10_mvl401 preempt ARMv5 gcc-3.4

    And in the DM6446 folder: vermagic=2.6.10_mvl401 preempt ARMv5 gcc-3.4

     

    I had tried building the linux kernel when I was starting on the DM6446 and ran into similar version issues, the fix I found at that time was actually to go to the pre-built linux kernel above.

     

    The linux kernel that my Rules.make points to is under workdir/lsp/ti-davinci, and in that folder the 'localversion' file contains:

    _mvl401

    There is no 'localversion-mvl' file there. When I do a 'locate localversion-mvl', the only path that has it is '/opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci_evm-arm_v5t_le/linux-2.6.10_mvl401'.

    When I try (renaming the old) and copying this folder to the workdir/lsp/ti-davinci and doing a 'make clean', 'make', I get more build errors than I can identify.

     

    When I try to follow the GSG section 4.5, 'Building a New Linux Kernel', I run into two issues:

    1. The GSG has mv_pro_5.0, but I have mv_pro_4.0.1, and 4.0.1 also matches the label on my CDs.

    2. Following the GSG instructions, I get stuck on 'cd ti-davinci/linux-2.6.18_pro500', as I have nothing even vaguely resembling the linux-2.6.18_pro500 folder inside of ti-davinci.

     

    Thanks!

  • Based on your last post, in particular "The GSG has mv_pro_5.0, but I have mv_pro_4.0.1, and 4.0.1 also matches the label on my CDs...", I am guessing you may have a combination of two different software releases and this may be leading to the issues you are seeing.  Where did you get your software (CDs, or which website)?

    The primary path for getting software is for customers to register their EVM (www.ti.com/davinciregistration ) , which will grant them access to our software update site (www.ti.com/davincisoftwareupdates ); the software that comes in the CDs are sometimes quite old (at least that has been our experience so far).  There are other sites where you can get even newer individual software components (sometimes in Early Adoptor status), but we recommend customers stick to the official releases available at www.ti.com/davincisoftwareupdates .  The latest dvsdk you will find there is dvsdk_1_30_01_41 which is based on mv pro 4.0.1 (accompanying GSG should state this as well).

     

     

  • Oops, I was reading the GSG online.  The printed GSG from my devkit does say mv_pro_4.0.1, as does the electronic version that I have installed on the linux host.  All my software came from the same source, the download site you mention (davincisoftwareupdates) about 2 months ago, and are dvsdk_1_30_01_41, mv_pro_4.0.1, and these match the version #'s on my printed GSG.

     

    The instructions lead to the same missing linux-2.6.10_mvl401 folder.  When I do a 'locate linux-2.6.10_mvl401', I find it is under:

    /opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci_evm-arm_v5t_le

    Instead of

    /opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci

     

    As the GSG suggests.  When I copy from the ti-davinci_evm-arm_v5t_le folder instead of ti-davinci to my /lsp/ti-davinci folder and proceed on the GSG Section 4.5 instructions, the following happens:

    host $ make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_evm_defconfig

      HOSTCC    scripts/basic/fixdep

         ...

      HOSTLD     scripts/kconfig/conf

    ***

    ***  Can't find default configuration "arch/arm/configs/davinci_dm355_evm_defconfig"!

    ***

     

    Using 'locate davinci_dm355_evm_defconfig' gives:

    /opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci/arch/arm/configs/davinci_dm355_evm_defconfig

     

    So, apparently, the files I need are somehow in both locations?  I would try copying files from both folders, but they conflict.  I tried copying just the config file, and successully get through, but upon completion of section 4.5, I try to tftp boot with the new file, and as soon as "Uncompressing Linux Kernel..." appears, my (RS-232) terminal goes to gibberish and fails to boot.

  • This is a typo in the GSG, please copy  '/opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci' instead and excute 'host $ make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_evm_defconfig' on this copy.

    [edit] disregard /opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci_evm-arm_v5t_le directory, you do not need this.

  • Leaving out the 'cd' and 'linux_2.6.10_mvl401' folder did the trick, and building the Kernel over using the pre-built kernel did indeed fix the loadmodules.sh / cmemk problems.

    Thanks Juan & Bernie!