• Locked Locked
  • Replies 26 replies
  • Subscribers 136 subscribers
  • Views 22476 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How could I make sure the driver work success?

Bor-Yih Chiang
Note: This was originally posted on 3rd November 2011 at http://forums.arm.com

Dear all,

I'm trying to build linux Mali200 driver in arm system.
I build mali.ko and insert it success in linux.
The attachment is log when I insert module.
It always told me "Mali device driver r2p2-03rel0 loaded".

Would you please tell me how could I make sure the driver work success?
Because I try to run the SimpleProject.
It always get the error message "Error: No EGL Display available at src/egl_runtime.c:64"

thanks.

James
  • Note: This was originally posted on 3rd November 2011 at http://forums.arm.com

    Hi James,

    that error is caused because the very first call to EGL, eglGetDisplay() is failing. There are a couple of common reasons for that. Do you have a /dev/mali device node in your filesystem?

    You can check what major device node it should have by doing:

    cat /proc/devices

    And you shoud see in the 1st half of the output a character device for mali, e.g.:

    Character devices:
    252 mali

    In that case, you should also have a corresponding device node:

    # ls -l /dev/mali
    crw-rw----  1 root root 252,  0 Aug 22 08:20 mali

    If the node doesn't exist you can create it with:

    mknod /dev/mali c 252 0

    Substituting whatever major device number you found in /proc/devices

    Can you have a look and let us know what you find?

    Cheers, Pete
  • Note: This was originally posted on 3rd November 2011 at http://forums.arm.com

    Hi Pete,

    Thanks for your reply.

    When I insert mali.ko.

    insmod mali.ko mali_major=250 mali_debug_level=6

    So, I have a /dev/mali character device.

    # ls -l /dev/mali
    crw-rw----    1 root     root      250,   0 Jan  1 00:11 /dev/mali

    # cat /proc/devices | grep "mali"
    250 mali

    # cat /proc/interrupts | grep "mali"
    27:          1  e-ic  mali_core_irq_handlers
    28:          1  e-ic  mali_core_irq_handlers
    29:          1  e-ic  mali_mmu_irq_handlers


    thanks.

    James
  • Note: This was originally posted on 3rd November 2011 at http://forums.arm.com

    Hi James,

    OK that looks good, there are a few other possibilities I think.

    It must be something fundamental to the very early stages of EGL initialization, so how about the framebuffer. Are you targeting the default Linux framebuffer, /dev/fb0?

    If so does that exist? Do you have the environment variable FRAMEBUFFER set to anything? I would try setting it to /dev/fb0 in case.


    # ls -l /dev/fb0
    crw-rw---- 1 root video 29, 0 2011-10-06 12:10 /dev/fb0
    # export FRAMEBUFFER=/dev/fb0


    If that doesn't help, do you know how your userspace libraries are built? Specifically, they can be built monolithic  where all parts of the driver, EGL, GLESv2 are linked into the same .so file, and all necessary .so files are symlinks to one true file. Sometimes this can cause problems with initialization if the symlinks have become copies of the real file (e.g. on a Windows filesystem not supporting symlinks).

    Also, do you know whether you are using the Unified Memory Provider (UMP)? If so you'd also need a /dev/ump. I think if you are using UMP then you'd have to do:

    insmod ump.ko

    before insmod mali.ko so I suspect you're not but worth checking.

    Cheers, Pete
  • Note: This was originally posted on 3rd November 2011 at http://forums.arm.com

    Hi Pete,

    Thanks for your information.

    #cat /proc/devices
    Character devices:
    ...
    29 fb
    ...
    250 mali
    251 ump

    My framebuffer device is /dev/fb.
    So I send the command "export FRAMEBUFFER=/dev/fb" than

    insmod ump.ko ump_major=251; insmod mali.ko mali_major=250 mali_debug_level=6

    And my userspace libraries is in /lib/gles20.

    # ls /lib/gles20/
    libEGL.so         libEGL.so.1.4     libGLESv2.so.2    libMali.so
    libEGL.so.1       libGLESv2.so      libGLESv2.so.2.0  libstdc++.so.6

    But I think it can find userspace libraries. If not it will show above
    # ./main.exe
    ./main.exe: error while loading shared libraries: libEGL.so: cannot open shared object file: No such file or directory

    Thanks.

    James
  • Note: This was originally posted on 3rd November 2011 at http://forums.arm.com

    Hi James,

    can you do:

    ls -l /lib/gles20/

    to check the file sizes and types of all the libraries?

    Also, can you check:


    ls -l /dev/fb
    ls -l /dev/ump


    to be sure they both exist and have the right access permissions?

    Do you know whether the driver libraries you have are the same version as the kernel module? The kernel module reports as r2p2 (which is v8). You can check what version the driver libraries are with something like:


    strings /lib/gles20/libMali.so | grep r2p


    should show the version string for the binary libraries. It should match (i.e. r2p2), if not you may need to contact your silicon supplier for updated driver libraries.

    Cheers, Pete
  • Note: This was originally posted on 9th November 2011 at http://forums.arm.com

    Hi, Pete

    I add the string in config.h than I rebuild it and didn't find the error string in the build log.

    And I think the frame buffer is ok.

    Thanks.

    James
  • Note: This was originally posted on 9th November 2011 at http://forums.arm.com

    Hi James,

    I agree, the framebuffer looks like it is working as expected.

    That's interesting news about the config.h though, I think that means the config.h you are editing is not the one being used by the build system.

    Can you run the following command in the driver kernel module source tree:


    find . -name "config.h"


    to find where all the files named config.h are in the source tree?

    If there are several, perhaps you can add a different  #error string to each, then rebuild (probably do a clean before, as well) to see which file is being used. Then you can make the changes to that config.h file and check the log output from insmod.

    Cheers, Pete
  • Note: This was originally posted on 9th November 2011 at http://forums.arm.com

    Hi, Pete

    Sorry... It's my mistake.

    When I add the error string in config, It will show some error message in build log.



    ./arch/config.h:67:2: error: #error "Checking config.h"
    ./arch/config.h:67:2: error: #error "Checking config.h"
    ./arch/config.h:67:2: error: #error "Checking config.h"
    ./arch/config.h:67:2: error: #error "Checking config.h"


    I think I just have one config.h.



    root@James-VM:/opt/GX910-SW-99002-r2p0-05rel0/driver/src/devicedrv/mali# find . -name "config.h"
    ./arch-pb-virtex5-m200/config.h


    Thanks.

    James
  • Note: This was originally posted on 22nd November 2011 at http://forums.arm.com

    Hi James,

    I haven't forgotten about this question. I've been able to replicate some of your setup here, and hope to have some more information to share with you soon.

    Cheers, Pete
  • Note: This was originally posted on 25th November 2011 at http://forums.arm.com

    Hi James,

    I believe I have got to the bottom of this, and it again comes down to a version mismatch between the binary userspace libraries you have, and the API version of the Mali kernel module you can build.

    I'm afraid the solution is to talk to your silicon provider and request userspace libraries which match the kernel module to which you have access, i.e. r2p0-05rel0 or onwards.

    Sorry I can't be more help, Pete
  • Note: This was originally posted on 8th November 2011 at http://forums.arm.com

    Hi, Karthik

    Thanks for you suggestion about this issue.

    Our chip provider didn't give us sources, so I can't rebuild it in debug mode.

    Do you have any idea for this status ?


    Thanks. ^^

    James
  • Note: This was originally posted on 8th November 2011 at http://forums.arm.com

    Hi James,

    without knowing the specifics of that board I can't be certain, but I suspect the config.h you have is not set up correctly for the board's memory layout. In particular, I think the ZBT memory may be causing problems - I'm not sure it's physically present on your board. Since it's been given a lower number in config.h, the driver will use that memory area first. If doing a malloc() in that memory area is failing that might explain the EGL_BAD_ALLOC error message.

    Please can you try commenting out that section:


    /* removing ZBT
    {
                 .type = MEMORY,
                 .description = "Mali ZBT",
                 .alloc_order = 5,
                 .base = 0x0FE00000,
                 .size = 0x00100000,
                 .flags = _MALI_CPU_WRITEABLE | _MALI_CPU_READABLE | _MALI_PP_READABLE | _MALI_PP_WRITEABLE | _MALI_GP_READABLE | _MALI_GP_WRITEABLE
         },
    */


    The config.h will still give the driver an Operating System (OS) allocation of memory of 0x03000000 (48MB).

    The framebuffer validation area looks OK. Are you certain the hardware base addresses are correct? E.g.:


                 .type = MALI200,
                 .base = 0xC7000000,



      .description = "MALI GP2",
      .base = 0xC7002000,



      .type = MMU,
      .base = 0xC7003000,


    Did you get this information from the chip provider? It looks as though the Mali is being initialized correctly by the kernel driver messages but I wanted to check.

    Thanks, Pete
  • Note: This was originally posted on 8th November 2011 at http://forums.arm.com


    Hi, Pete

    Mali.ko can get the MAIL200 Version register and the setting can work in wince.
    So, I think the setting is correctly.

    I tried to comment Mali ZBT section. But the error message is the same as before.

    Thanks.

    James

  • Note: This was originally posted on 8th November 2011 at http://forums.arm.com

    Hi James,

    thanks for removing the ZBT, I think it should stay removed. I've checked the Driver Development Kit (DDK) documentation and it suggests you should be using the MMU, in which case the OS_MEMORY region flags should be the MMU ones instead - please change the flags from this:


    {
      .type = OS_MEMORY,
      .description = "OS Memory",
      .base = 0x78000000,
      .size = 0x03000000,
      .alloc_order = 10,
      .flags = _MALI_CPU_WRITEABLE | _MALI_CPU_READABLE | _MALI_PP_READABLE | _MALI_PP_WRITEABLE |_MALI_GP_READABLE | _MALI_GP_WRITEABLE,
      .cpu_usage_adjust = 0x00000000
    },


    to this:


      .flags = _MALI_MMU_WRITEABLE | _MALI_MMU_READABLE,


    and check that you are building the kernel module with MMU exanbled (USING_MMU=1). In fact, can you post your current build command?

    I think you have userspace library binaries from your chip provider, but did you also receive a binary mali.ko kernel module? If so it may be possible to check the configuration options used to build it, and use them again for your kernel module.

    Cheers, Pete