Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
SoC Design and Simulation blog Getting Up and Running with the ARM Mali-450 MP GPU (Part 3 of 3)
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • carbon
  • fast_models
  • Mali-450
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Getting Up and Running with the ARM Mali-450 MP GPU (Part 3 of 3)

Bill Neifert
Bill Neifert
December 10, 2013
4 minute read time.

Below is a blog post which Varun Subramanian made to Carbon's blog today about using ARM Fast Models together with a Carbonized Mali-450MP

In the previous parts of this blog series, I discussed the procedure of Carbonizing the RTL of an ARM Mali-450 GPU and building an SoC Designer component, followed by the description of a virtual prototype environment that runs cycle-accurate integration tests provided by ARM on the Mali-450 GPU using a Cortex-A15 based system.

This part describes a Linux-based Carbon Performance Analysis Kit (CPAK) containing a Cortex-A15 based system with an ARM Mali-450 GPU. This CPAK enables the user to integrate the Mali GPU drivers into the Linux Kernel and registering the Mali driver while booting Linux on the virtual prototype environment.  We’ll do this by combining the speed of ARM’s Fast Models together with the accuracy of the Carbonized GPU model in the same system.


Partitioning the System

The block diagram in Figure 1 shows the Mali-450 CPAK that we’ve been working with so far.  This system is comprised entirely of 100% accurate models which enable us to see the impact of our IP configuration settings and bare-metal software. As we migrate to higher level tasks such as driver development, we can map portions of the system to more abstract models in order to execute at faster speeds. SoC Designer automatically understands the relationship between Carbonized models of ARM IP and their Fast Model equivalents so all we need to do to is tell the Fast Model Generator tool in SoCDesigner which models we would like to execute accurately, and which ones should be represented as Fast Models.

ARM Mali-450 CPAK Block Diagram

The dotted line indicates the portion of the virtual prototype we’d like to execute as ARM Fast Models. The rest of the system will continue to execute as cycle accurate models. Once we’ve identified the models for each domain, SoCDesigner will automatically build a new virtual prototype representation containing both Fast Models and Carbonized, 100% accurate models. Figure 2 shows a block diagram that describes such a system. All of the necessary transactor logic to map between the abstract models and the accurate models is inserted automatically.

Using the CPAK with ARM Fast Models

Now that we’ve updated the CPAK to ARM Fast Models, let’s put it to use. Since the virtual prototype will run at ARM Fast Model speeds when the accurate models are not being used, we can now use this platform to quickly boot Linux and integrate the Mali device driver.  In order to do this, I integrated the Mali Linux drivers into the Linux kernel that was used as part of the A15 Linux CPAK. The Linux drivers are part of the Mali-450 GPU Linux Driver Development Kit (DDK) provided by ARM. The DDK contains the Mali Linux device drivers and the base drivers. It also provides links to download the OpenGL drivers, specific to Mali-450 GPU. The Integration Guide was used, along with minor modifications specific to the virtual prototyping environment, to integrate the software into the Linux kernel. The integration procedure involved the following steps:

  1. Integrating and building the Mali Linux device driver: The user specifies the macros corresponding to the GPU configuration parameters, along with configuring the Mali GPU memory, the framebuffer memory and power management options. The device driver was built as part of the kernel image, but it can also be built as a kernel module.
  2. Building the OpenGL and GLES libraries and adding them to the root file system.
  3. Building the GPU benchmarks and adding them to the root file system.
  4. Building the kernel image that contains the Mali device drivers, base drivers, the OpenGL drivers and the GPU benchmarks.

This CPAK can prove to be useful to device driver developers who could step through the process of loading the Mali device drivers during boot-up. Figure 3 shows the messages printed by the console while loading the Mali Linux drivers with debug messages turned on. It describes the whole procedure of registering the drivers that starts with initializing the Mali memory system and ends with initializing the platform device, provided all intermediate steps pass. The intermediate steps define the settings for the framebuffer, the dedicated and shared memory. Each of the internal components of the Mali-450 that include the L2 cache, the Graphics Processor, the Pixel Processors and the Dynamic Load Balancing unit are then created and the corresponding base addresses are defined. describe the image


The Results

With the driver ported to Linux, it is now possible to quickly boot the OS in just over two minutes and then start processing frames with 100% accuracy.  The benchmark that uses the Mali base drivers runs test suites on:

  1. GPU memory allocation
  2. Initialization of the Graphics Processor
  3. Initialization of the Pixel Processors
  4. Running vertex shader jobs
  5. Running rendering jobs that draw a simple triangle.

Getting the whole system up and running took me 3 weeks, but all of the work that I’ve done is incorporated into theMali-450 CPAK meaning that you can duplicate the same results within minutes of downloading the package. The package includes an app note that describes the steps that the user would need to take to use pre-built binaries to perform the integration process.

Anonymous
SoC Design and Simulation blog
  • Performance verification with AMBA Viz

    Tony Nip
    Tony Nip
    Run consistent latency and bandwidth checks on CMN interconnects using AMBA Viz’s new performance script—no API expertise needed.
    • June 30, 2025
  • Understanding Scandump: A key silicon debugging technique

    Vincent Yang
    Vincent Yang
    Scandump is highly effective in silicon debugging as it can capture most internal states through scan chains, making it invaluable in diagnosing silicon issues.
    • June 5, 2024
  • Introduction to AMBA Viz

    Tony Nip
    Tony Nip
    AMBA Viz enables faster debug and performance analysis for cycle-accurate simulation and emulation, even for complex interconnects and AMBA bus protocols.
    • May 31, 2024