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.

./loadmodules.sh

After having alot of problems running loadmodules.sh while using Ubuntu as my linux program I have now restarted using Redhat fedora.

A complete restart, loaded all latest software in accordance to the getting started manual.

Completed the hello.c code which compiled correctly is ran from EVM.

Now wanted to run demos.

Running throught the minicom terminal window in "Redhat Fedora" the EVM boots fine using the PC as the NFS host.

I have gone to the directory again still through the EVM terminal link.

Gone to DVSDK_1_30_01_41/demos/dm355 then ran ./loadmodules.sh

To which a number of errors occour including cannot find's etc..

I suspect this is due to PATH's incorreclty set. Could any one send me their path settings for running the loadmodules.sh.  ?

 

 

 

 

 

 

 

 

 

  • #cat dvsdk/loadmodules.sh
    #!/bin/sh
    # 12MB
    insmod cmemk.ko phys_start=0x87400000 phys_end=0x88000000 pools=1x2097152,2x1529856,7x829440,1x524288,1x108680,1x81920,2x8192,6x4096
    ./mapdmaq
    insmod dm350mmap.ko
    rm -f /dev/dm350mmap
    mknod /dev/dm350mmap c `awk "\\$2==\"dm350mmap\" {print \\$1}" /proc/devices` 0

    If you use original Montavista distributiv script loadmodule start auto.

    If use another, as I, you need start script manual from /opt directory or inserted command for autostart in start scripts, e.g. rcS.

    Output after normal run loadmodule.sh:

    # ./loadmodules.sh
    ioremap_nocache(0x87400000, 12582912)=0xc7880000
    allocated heap buffer 0xc7880000 of size 0xce000
    cmem initialized 8 pools between 0x87400000 and 0x88000000

  • I am confused by how you have your environment setup, you say you are on the board through the minicom terminal but you go to a DVSDK directory which would not normally be mounted by the board unless you copied it into the NFS mounted directory, I assume you copied it into where you are NFS mounting?

    If the loadmodules.sh is giving errors regarding missing files it probably means that it cannot find cmemk.ko and/or dm350mmap.ko, so if you grab these files (dvsdk_1_30_00_xx\kernel_binaries\dm355 should have them) and put them in the same directory you run loadmodules.sh from you should be good to go. I believe the default filesystem and demo installer will end up with you having both the loadmodules.sh and the proper kernel modules within workdir\filesys\opt\dvsdk.

  • Hi Folks,

    I've got it to compile before I read these messages. I just grabbed the files from around the system and copied to the correct places in demos.

    One big thing from this I've learn't is never use Ubuntu for this device.

    I now have all the demos running via the minicom terminal commands.

    I have the DVSDK loaded to /opt of my working directory so I can access this from the board.

    All I have to do now is start writing the code.

    Cheers guys. for any help and most of the faults have been down to some thing else.

     

  • It sounds like you are off to the races, which is great.

    However, your comment about not using Ubuntu is interesting to me.  Are you referring to the Linux distribution that is running on your host machine?  If so, I have an Ubuntu Linux server which I have the DM355 Linux kernel, toolchain and NFS target filesystem on.
    I don't specifically recall any headaches, but it was a while ago.

  • Brandon is right, I have known several folks to use a Ubuntu host just fine for development, though it is not used in validation testing on the DVSDK, it should still work, how was Ubuntu causing you trouble?

  • I am use a Debian as host machine and don't any problems. I don't think what Ubuntu, or any another Linux can make problem in works.