• Locked Locked
  • Replies 10 replies
  • Subscribers 136 subscribers
  • Views 10142 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

Debugging Mali driver in 3.4 kernel in Origen

Sangwook Lee
Note: This was originally posted on 26th April 2012 at http://forums.arm.com

Hello

I am trying to make ICS Android (Mali) work in Origen with 3.4 kernel

Now  as using Mali driver, gralloc_ump r2p4-02rel in 3.4 kernel with the following Android branch.
repo init -u git://android.git.linaro.org/platform/manifest.git -b linaro_android_4.0.4 -m tracking-origen.xml

I have the following errors:

*******************************************************************************
[   15.225000] MALI PHYSICAL RANGE VALIDATION ERROR!
[   15.235000] We failed to validate a Mali-Physical range that the user-side wished to map in
[   15.245000] It is likely that the user-side wished to do Direct Rendering, but a suitable
[   15.250000] address range validation mechanism has not been correctly setup
[   15.260000] The range supplied was: phys_base=0x6D900000, size=0x004B0000
[   15.270000] Please refer to the ARM Mali Software Integration Guide for more information.
[   15.275000] *******************************************************************************

In my opinion, it seems that user space library call ioctl command with in-proper argument. 
    ioctl command (MALI_IOC_MEM_MAP_EXT)  with the wrong params: phys_base=0x6D900000, size=0x004B0000

In addition, currently I didn't  add UMP remap call  in  Framebuffer drivers.  Is it possible reason ?


Thanks
Sangwook
  • Note: This was originally posted on 27th April 2012 at http://forums.arm.com

    Hi Sangwook,

      Mali GPU can only write to an address range configured during the build process. If the frambuffer is located outside this address range, then you would get a Physical range validation error as above. To fix this issue, you would need to edit config.h (inside arch-xxx folder) and modify the range to include the framebuffer physical address.

    You should find something like the following,

      {
         .type = MEM_VALIDATION,
         .description = "memory validation",
         .base = MEM_BASE_ADDR,
         .size = MEM_TOTAL_SIZE,
         .flags = _MALI_CPU_WRITEABLE | _MALI_CPU_READABLE | _MALI_PP_READABLE | _MALI_PP_WRITEABLE | _MALI_GP_READABLE | _MALI_GP_WRITEABLE | _MALI_MMU_READABLE | _MALI_MMU_WRITEABLE
    },

    Edit the .base and .size parts of the config to suit your needs.

    Hope it helps.

    Regards
    Karthik
  • Note: This was originally posted on 30th April 2012 at http://forums.arm.com

    Hi Sangwook,

       With just the log messages, I can only guess the obvious. The MMU is not being setup correctly. I am not familiar with the initialization phase of the Mali driver but I think it should also initialize the MMU. Could you check the driver init?  I remember that linaro had a version of Mali (r2p3?) working with an older kernel(3.0?). It might  be worth checking if the same driver works (with new kernel)and try figuring out the differences.

    In the mean time, I will also enquire with more people to see if there is an obvious problem.

    Regards
    Karthik
  • Note: This was originally posted on 30th April 2012 at http://forums.arm.com

    Hi Karthik

    >With just the log messages, I can only guess the obvious. The MMU is not  being setup correctly. I am not familiar with the initialization phase  of the Mali driver but I >think >it should also initialize the MMU. Could  you check the driver init?  I remember that linaro had a version of Mali  (r2p3?) working with an older kernel(3.0?). It >might  be >worth checking  if the same driver works (with new kernel)and try figuring out the  differences.

    Thanks for good advice.

    I compared [1] to [2]
    [1]:  3.0 Kernel + r2p3-01rel 
    I am attaching this log message with "mali_debug_level=7",
    but I can see the same error message even under the normal operation:
        "Core: Schedule: Could not activate MMU. Scheduelling postponed to MMU, checking next"
        So this message might not be critical. With this debug level, there are two many
       debugging message, which overwhelmed me. Are there any more hints ?

       [2]:  3.4 Kernel + r2p3-01rel
      (I posted debug message into this forum)
      Is there anyone to run Mali driver in 3.4 kernel in ARM ?
    I am using Kernel (Android)
            git://git.linaro.org/landing-teams/working/samsung/kernel.git (android-tracking)
     
    Thanks
    Sangwook
  • Note: This was originally posted on 1st May 2012 at http://forums.arm.com

    [Continued]

    I guess that the following function makes Kernel hang up.
    In "mali_osk_irq.c" file,  If queue_work is called, the kernel seems to hang up.
    Please see the line in red.

    -----------------------------------------------------------------------------------
    void _mali_osk_irq_schedulework( _mali_osk_irq_t *irq )
    {
    mali_osk_irq_object_t *irq_object = (mali_osk_irq_object_t *)irq;


    #if MALI_LICENSE_IS_GPL
    if ( irq_object->irqnum == _MALI_OSK_IRQ_NUMBER_PMM )
    {

        MALI_DEBUG_PRINT(2, ("FUNC %s line %d\n", __FUNCTION__, __LINE__));
      queue_work( pmm_wq,&irq_object->work_queue_irq_handle );
    MALI_DEBUG_PRINT(2, ("FUNC %s line %d\n", __FUNCTION__, __LINE__));
    }
    else
    {
    #endif
      MALI_DEBUG_PRINT(2, ("FUNC %s line %d\n", __FUNCTION__, __LINE__));


      schedule_work(&irq_object->work_queue_irq_handle);
    #if MALI_LICENSE_IS_GPL
    }
    #endif
    MALI_DEBUG_PRINT(2, ("FUNC %s line %d\n", __FUNCTION__, __LINE__));
    }
    -------------------------------------------------------------------------------------------------------------

    Thanks
    Sangwook
  • Note: This was originally posted on 1st May 2012 at http://forums.arm.com

    Is the GPU powered up?

    If you poke a register using a debugger what happens? If that hangs check you have turned it on before you poke it.

    Iso
  • Note: This was originally posted on 2nd May 2012 at http://forums.arm.com


    Is the GPU powered up?

    If you poke a register using a debugger what happens? If that hangs check you have turned it on before you poke it.

    Iso


    Thanks for your advice. Please let me check out power status on GPU.
  • Note: This was originally posted on 8th May 2012 at http://forums.arm.com


    Is the GPU powered up?

    If you poke a register using a debugger what happens? If that hangs check you have turned it on before you poke it.

    Iso



    Thanks, sogen74 and KarthiKH

    Your advice is correct.
    When Mali was running, other driver mistakenly believed that it could turn off Mali's power
    because  the power to Mali was not used by anyone.