[Sangwook]

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

[KarthikH]

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

[Sangwook]

Hi Karthik

> 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.

Thanks, it helps a lot. I could get through the previous error.

Now I have kernel another hang up after Mali driver showing
"[ 6.255000] Mali<2>: Core: session_begin: for Mali-400 GP".

I am attaching another Mali log message with "mali_debug_level=4"

The log message with "mali_debug_level=2" is:

----------------------- log message with mali_debug_level =2 ========================
[ 1.725000] Mali<2>: Mali OS memory allocator created with max allocation size of 0x6000000 bytes, cpu_usage_adjust 0x00000000
[ 1.740000] Mali<2>: Memory Validator 'memory validation' installed for Mali physical address base==0x40000000, size==0x40000000, cpu_adjust==0x00000000
[ 1.755000] Mali<2>: Creating Mali L2 cache: Mali-400 L2 cache
[ 1.760000] Mali<1>: Mali memory allocators will be used in this order of preference (lowest numbered first) :
[ 1.775000] Mali<1>: 0: System Memory
[ 1.800000] Mali<2>: Attach mmu: 0xed295e80 to core: Mali-400 PP 0 in subsystem: Mali-400 PP
[ 1.810000] Mali<2>: Attach mmu: 0xed295580 to core: Mali-400 PP 1 in subsystem: Mali-400 PP
[ 1.820000] Mali<2>: Attach mmu: 0xec95b080 to core: Mali-400 PP 2 in subsystem: Mali-400 PP
[ 1.825000] Mali<2>: Attach mmu: 0xec95b380 to core: Mali-400 PP 3 in subsystem: Mali-400 PP
[ 1.835000] Mali<2>: Attach mmu: 0xed295800 to core: Mali-400 GP in subsystem: Mali-400 GP
[ 1.845000] Mali<2>: Mali L2 cache system load complete
[ 1.850000] Mali: Mali device driver loaded
[ 1.855000] UMP: UMP device driver loaded
[ 1.870000] brd: module loaded
[ 1.875000] loop: module loade
[ 6.235000] Mali<2>: MMU session begin
[ 6.235000] Mali<2>: Page directory for session 0xec98a140 placed at physical address 0x6D884000
[ 6.245000] Mali<2>: MMU session begin: success
[ 6.250000] Mali<2>: Core: session_begin: for Mali-400 PP
[ 6.255000] Mali<2>: Core: session_begin: for Mali-400 GP
==============================================================================
And then Kernel died silently.
Do you have any advice on this issue ?
Now I am using CMA (Continous Memory Allocation) in 3.4 kernel. Is it related to this issue ?
Welcome any comments !

Thanks
Sangwook

[Sangwook]

[Continued]

With "mali_debug_level=7", Is it ok with the line in red ?

----------------------------------------------------------------------------------------
[ 23.245000] Mali<4>: Mapping phys 0x41BE5000 length 0x00001000 at offset 0x0003F000 to CPUVA 0xB584D000
[ 23.255000] Mali<6>: Mali map: mapping 0x41BE5000 to Mali address 0x4017F000 length 0x00001000
[ 23.260000] Mali<6>: Allocated 64 pages
[ 23.265000] Mali<6>: 448 out of 24576 pages now allocated
[ 23.270000] Mali<7>: MMAP OK
[ 23.335000] Mali<7>: Ioctl received 0xC0048500 0x100FFB60
[ 23.340000] Mali<5>: MUTEX: GRAB mali_core_subsystem_ioctl_start_job() 796 on Mali-400 GP
[ 23.350000] Mali<5>: MUTEX: GRABBED mali_core_subsystem_ioctl_start_job() 796 on Mali-400 GP
[ 23.355000] Mali<3>: Mali GP: subsystem_maligp_get_new_job_from_user 0x89c150
[ 23.370000] Mali<3>: Mali GP: Job Regs: 0x40004040 0x400040A0, 0x40006040 0x40006118 0x40140000 0x40170000
[ 23.375000] Mali<4>: Mali GP: Job: 0x0089c150 INPUT from user.
[ 23.380000] Mali<5>: Core: session_add_job: for Mali-400 GP
[ 23.385000] Mali<6>: Core: session_add_job job=0xed135800
[ 23.395000] Mali<5>: Core: subsystem_schedule: Mali-400 GP
[ 23.400000] Mali<6>: Core: Schedule: Could not activate MMU. Scheduelling postponed to MMU, checking next.
[ 23.415000] Mali<3>: PMM: sending message
---------------------------------------------------------------------------------------------------------------------------------------------------

Thanks
Sangwook

[KarthikH]

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

[Sangwook]

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

Attached File(s)

•  30MaliDebug7Log.txt (417.08K)
  Number of downloads: 0

[Sangwook]

[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

[Sangwook]

[Continued]

If I unset CONFIG_USING_PMM

--------------------------------------------------------------------------------------------------------------------------------------
22.955000] Mali<7>: Ioctl received 0xC0048500 0x100FFB60
[ 22.960000] Mali<5>: MUTEX: GRAB mali_core_subsystem_ioctl_start_job() 796 on Mali-400 GP
[ 22.970000] Mali<5>: MUTEX: GRABBED mali_core_subsystem_ioctl_start_job() 796 on Mali-400 GP
[ 22.975000] Mali<3>: Mali GP: subsystem_maligp_get_new_job_from_user 0x178d150
[ 22.990000] Mali<3>: Mali GP: Job Regs: 0x40004040 0x400040A0, 0x40006040 0x40006118 0x40140000 0x40170000
[ 22.995000] Mali<4>: Mali GP: Job: 0x0178d150 INPUT from user.
[ 23.000000] Mali<5>: Core: session_add_job: for Mali-400 GP
[ 23.010000] Mali<6>: Core: session_add_job job=0xc1849000
[ 23.015000] Mali<5>: Core: subsystem_schedule: Mali-400 GP
[ 23.030000] Mali<4>: Asked to activate page table for session 0xc1867600 on MMU Mali-400 MMU for GP
[ 23.035000] Mali<5>: Session 0xc1867600 looked up as using memory session 0xc1abc000
[ 23.050000] Mali<7>: Taking locks
[ 23.050000] Mali<4>: MMU idle, activating page directory 0x6D884000 on MMU Mali-400 MMU for GP
[ 23.070000] Mali<7>: FUNC mali_mmu_activate_address_space Line 2268
[ 23.070000] Mali<7>: FUNC mali_mmu_enable_stall Line 1372
[ 23.080000] Mali<6>: mali_mmu_register_write mr: 0xF003C000, addr:0x0008 val:0x00000002
----------------------------------------------------------------------------------------------------------------------------------------
Now mali_mmu_register_write makes Kernel hang up.

Thanks
Sangwook

[isogen74]

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

This post has been edited by isogen74: 01 May 2012 - 06:03 PM

[Sangwook]

isogen74, on 01 May 2012 - 06:02 PM, said:

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.

This post has been edited by Sangwook: 02 May 2012 - 03:45 PM

[Sangwook]

isogen74, on 01 May 2012 - 06:02 PM, said:

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.

This post has been edited by Sangwook: 08 May 2012 - 01:54 PM