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

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

Karthik Hariharakrishnan over 12 years ago

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
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago
Cancel
Vote up 0 Vote down

Cancel
Karthik Hariharakrishnan over 12 years ago

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
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago

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
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago

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
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago
Cancel
Vote up 0 Vote down

Cancel
Peter Harris over 12 years ago

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
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago

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.
Cancel
Vote up 0 Vote down

Cancel
Sangwook Lee over 12 years ago

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.
Cancel
Vote up 0 Vote down

Cancel