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 loading issue

On a custom DM355 board, cmem does not create a device node. insmod command was taken from loadmodules.sh (part of dvsdk demo).

root@custombrd:/media/card# insmod cmemk.ko phys_start=0x86000000 phys_end=0x88000
000 pools=10x829440,1x1529856,1x276,1x4320,1x560,2x344,1x144,1x81920,2x512,1x140
00,1x12960,1x11360,1x4,2x296,1x8192,59x56,4x24,1x1505280,9x1658880,1x2258880CMEM
K module: built on Nov 18 2010 at 12:37:59

  Reference Linux version 2.6.32
  File /home/vmplanet/dvsdk/dvsdk_3_10_00_19/linuxutils_2_25_04_10/packages/ti/s
do/linuxutils/cmem/src/module/cmemk.c
allocated heap buffer 0xca000000 of size 0x45b000
cmemk initialized
root@custombrd:/media/card# ls /dev/
apm_bios   hda        hda2       mmcblk0p1  mtd5       ptmx       tty4
console    hda1       hda3       mmcblk0p2  mtd6       pts        tty5
dm350mmap  hda10      hda4       mmcblk0p3  mtd7       ram0       tty6
event0     hda11      hda5       mmcblk0p4  mtdblock0  ram1       tty7
event1     hda12      hda6       mmcblk0p5  mtdblock1  ram2       tty8
event2     hda13      hda7       mmcblk0p6  mtdblock2  ram3       ttyS0
event3     hda14      hda8       mmcblk0p7  mtdblock3  random     ttySA0
event4     hda15      hda9       mtd0       mtdblock4  tty        urandom
event5     hda16      initctl    mtd1       mtdblock5  tty0       zero
event6     hda17      kmem       mtd2       mtdblock6  tty1
event7     hda18      mem        mtd3       mtdblock7  tty2
fb0        hda19      mmcblk0    mtd4       null       tty3
root@custombrd:/media/card#

What could be the problem?

  • It could be that you are not logged in as "root" when doing the insmod, along with lack of write permission in /dev for non-root user .

    Regards,

    - Rob

  • I am logged in as root and I can create a test node by using: mknod test c 1 1

    root@custombrd:/# whoami
    root
    root@custombrd:/# ls -l
    drwxrwxr-x    2 root     root         1024 Jun 21  2010 bin
    drwxr-xr-x    3 root     root         2048 Jan  1 00:48 dev
    drwxr-xr-x    5 root     root         1024 Nov 17  2010 etc
    drwxrwxr-x    3 root     root         1024 Jun 21  2010 home
    drwxrwxr-x    3 root     root         1024 Jun 21  2010 lib
    lrwxrwxrwx    1 root     root           12 Nov 18  2010 linuxrc -> /bin/busybox
    drwx------    2 root     root        12288 Nov 18  2010 lost+found
    drwxrwxr-x   10 root     root         1024 Jun 21  2010 media
    drwxrwxr-x    2 root     root         1024 Jun 21  2010 mnt
    drwxr-xr-x    3 root     root         1024 Nov 18  2010 opt
    dr-xr-xr-x   33 root     root            0 Jan  1 00:00 proc
    drwxrwxr-x    2 root     root         2048 Jun 21  2010 sbin
    drwxr-xr-x   11 root     root            0 Jan  1 00:00 sys
    drwxrwxrwt    2 root     root         1024 Jun 21  2010 tmp
    drwxrwxr-x    6 root     root         1024 Nov 16  2010 usr
    drwxrwxr-x    7 root     root         1024 Jun 21  2010 var
  • In addition, dm350mmap was loaded without problems.

  • Is USE_UDEV=1 in <linuxutils_root>/ti/sdo/linuxutils/cmem/Rules.make?

    If it's 0, try setting it to 1 and rebuilding cmemk.ko.

    Otherwise, I'm not sure why the /dev/cmem entry isn't getting created during insmod.  You could try something like this after the insmod:
        % mknod /dev/cmem c `awk "/cmem/ {print \\$1}" /proc/devices` 0
    It will create a char device with major number of the insmod'ed cmemk.ko.

    Regards,

    - Rob

  • USE_UDEV is 1 in Rules.make

  • The only other suggestion I have is to rebuild  your cmemk.ko with 'debug' enabled, and observe/report the console output for the insmod command (it might be quite large with that complicated geometry that you're specifying).  To do so, navigate down to the <linuxutils_root>/packages/ti/sdo/linuxutils/cmem/src/module and issue:
        % make debug
    and the resulting cmemk.ko will have debug prints.  If those prints don't come out on the console, you can see them by issuing:
        % dmesg
    .  Hopefully this will show some error from the kernel APIs that are used to create the /dev entry.

    For previous problem reports similar to your's (where the /dev/cmem node is not created, yet the module insmods just fine) it's always been a case of the incorrect permissions for /dev for the issuing user.  Something is amiss here.

    You say that your dm350mmap /dev entry was created successfully.  Does the script that insmods that one contain a manual mknod command?  I'm just probing for clues here, suspecting that your Linux kernel doesn't have the capability of run-time creation of /dev entries from a kernel module.

    Regards,

    - Rob

     

  • You are right regarding dm350mmap module. I did notice it later that the node was added "manually" at the very end of the script (last line; I did not notice it at first).

    If my Linux kenel does not have the runtime node making capability, do you know what feature/configuration turns it on/off?

    I will try your suggestion regarding debug message option.

    I also talked to our linux IT guy here. He is more into the servers and stuff. He suggected that it could also be something with rules defined in udev.

    Thank you.