ARM Community: Drivers for 400MP on 3.4 - ARM Community

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Drivers for 400MP on 3.4

#1 User is offline   espenfjo 

  • Member
  • Pip
  • Group: Members
  • Posts: 1
  • Joined: 16-April 12

Posted 16 April 2012 - 08:43 PM

Hi,
I am playing around with getting the kernel drivers for Mali 400 to work on Linux 3.4 on an Exynos 4210 board.
It is mostly for fun, but the hope is to get Android running on it.
I am basing the work on the current Linaro sources, but with upgraded Mali sources (no difference with Linaro or new Mali sources).

My issue is that the Mali initialization hangs while booting, and it is logging the following:
Sorry about the output being a bit garbled, there is some issue with the RAM log feature.


<7>[ 0.260000] Mali<2>:
<7>[ 0.260000] Mali<2>: ^Ansertin' Mali v10 device driver.
<7>[ 0.260000] Mali<2>: ComPiled: Apr 16 2012, time: 21:59:01.
<7>[ 0.260000] Mali<2>: Svn revision:
<7>[ 0.260000] Mali<2>: MMU memory system initializing
<7>[ 0.260000] Mali<2>: Renderbore: subsystem global mutex initialized
<7>[ 0.260000] Mali<3>: Mali PP: mali200_subsystem_startup
<7>[ 0.260000] Mali<2> Core: subsystem_init: Mali-400 PP
<7>[ 0.260000] Mali<6>: Mali PP: mali200_subsyrtem_startup
<7>[ 0.260000] Mali<3>: Mali GP: maligp_subsystem[startup
<7>[ 0.260000] Mali<2>: Core: rubsystem_init: Mali-400 GP
<7>[ 0.260000] Mali<6>: Mali GP: maligp_subsySt%m_startup
<7>[ 0.260000] Mali<2>: Ma,i L2 cache system initial)zing
<7>[ 0.260000] Mali<3>: Mali GP: maligp_renderunit_create
<7>[ 0.260000] MAli<5>: Core: renderunit]init: Core:Mali-400 GP
<7>[ 0.260000] Mali<3>: Core: rendepunit_map_begisters: Cora:Mali-400 GP
<7>[ 0.260000] Mali<1:: Success: request_mem_region: ( x13000000 - 0x13000097) Core:Mali-400 GP
<7>[ 0.260000] Malh<6>:EFO: Mapping these: mem_mapiregion reg_base_addr: 0x13000000, core->size: 152
<7>[ 0.260000] Mali<6>: Success: ioremap_nocache: Internal ptr: (0xF681E000 - 0xF681E097) Core:Mali-400 GP
<7>[ 0.260000] Mali<4>: Sucbess: Mapping registers to core: Mali-400 GP
<7>[ 0.260000] Mali<6>:EFO: _mali_osk_mem_ioread32_pre raddr Core:0xF681E000 Addr:0x006C


I have added som more debug logging to the mali_kernel_rendercore.c as you see, prefixed with EFO:

MALI_DEBUG_PRINT(6, ("EFO: Mapping these: mem_mapioregion reg_base_addr: 0x%08X, core->size: %lu\n", core->registers_base_addr, core->size));
core->registers_mapped = _mali_osk_mem_mapioregion( core->registers_base_addr, core->size, core->description );



As you see from the log it hangs at:
common/mali_kernel_GP2.c:353 core->core_version = mali_core_renderunit_register_read(core, MALIGP2_REG_ADDR_MGMT_VERSION)
common/mali_kernel_rendercore.h: 451 read_val = _mali_osk_mem_ioread32(core->registers_mapped, relative_address);

And the _mali_osk_mem_ioread32 is as you now a wrapper for ioread32.


From my extended logging you see that it tries to read from Core:0xF681E000 Addr:0x006C which is well within the values from <7>[ 0.260000] Mali<6>: Success: ioremap_nocache: Internal ptr: (0xF681E000 - 0xF681E097) Core:Mali-400 GP

We have a 3.0.X kernel working, which maps the same values:

<4>[ 0.990775] Mali<1>: Mapping these: mem_mapioregion reg_base_addr: 0x13000000 size: 152
<4>[ 0.990832] Mali<1>: Success: ioremap_nocache: Internal ptr: (0xF28EE000 - 0xF28EE097) Core:Mali-400 GP

I am not sure how to proceed with this, as the memory values seems to be the same in the two kernels.


Help much appreciated.

-
Espen Fjellvær Olsen
0

#2 User is offline   isogen74 

  • Super Contributor
  • PipPipPipPip
  • Group: Members
  • Posts: 1098
  • Joined: 20-March 07

Posted 27 April 2012 - 08:51 AM

I'm not overly familiar with Mali-400, but many of the early messages look like the software initializing and mapping the memory, but not actually touching the GPU itself. Assuming that this is the first access which actually tries to use the hardware the first place to start is to check the GPU is actually powered up.

Iso
When optimizing software, consider that the quickest code to run is the bit you removed from the call path.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic