Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Mobile, Graphics, and Gaming blog Using DS-5 Streamline with Mali on Google Nexus 10
  • 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
  • ds-5
  • nexus10
  • Mali
  • Mali-T604
  • Streamline
  • exynos
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Using DS-5 Streamline with Mali on Google Nexus 10

Michael McGeagh
Michael McGeagh
April 15, 2014
5 minute read time.

ABSTRACT

This guide will show how to get ARM® DS-5™ Streamline™ support working on a production Google Nexus 10 device, with minimal modifications.

The resulting files generated will be a gatord, gator.ko and a boot.img file.

This guide is written with both Android version 4.3 (JellyBean MR2) and 4.4.2 (KitKat MR1) in mind.

PREREQUISITE

Device Requirements

It is required that the Nexus 10 device has root access.

This is required in order to install gator and to insert the kernel module.

You will also be flashing and/or booting a custom kernel.

Software Requirements

ARM DS-5 software is required to be installed. This is required in order to do any capturing of data and also contains the source code for gator.

The community edition of DS-5 can be obtained for free from the ds5 website.

This guide has been tested with DS-5 version 5.17 on Linux.

In addition, you will need the Android SDK (for adb and fastboot) and Android NDK (for building gator daemon).

Finally, you will need abootimg or equivalent scripts to modify the boot.img.

KERNEL

Toolchain

The toolchain to be used for building the kernel can be obtained from the following public git repository:

git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/















In order to setup your build environment to use this toolchain, and to target cross compilation, do the following:

export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
export ARCH=arm
export SUBARCH=arm
















Source Code

The kernel source code can be obtained from the following public git repository:

git clone https://android.googlesource.com/kernel/exynos kernel
cd kernel














Either checkout jb-mr2 (Android 4.3) or kitkat-mr1 (Android 4.4.2) branch depending on what version of Android your device is running:

git checkout android-exynos-manta-3.4-jb-mr2
git checkout android-exynos-manta-3.4-kitkat-mr1








Building

To build the kernel, do the following:

make manta_defconfig
make














In order to build the gator driver however, you will need to make modifications to the kernel.

make menuconfig

[*] Enable loadable module support -->

[*] Forced module loading

[*] Module unloading

[*]   Forced module unloading


General setup -->

[*] Profiling support


Device Drivers -->

Graphics Support -->

ARM GPU Configuration -->

Mali-T6XX support -->

[*] Streamline Debug support

If you are targeting Android 4.3, you will need to make the following modifications before you can successfully build:

diff --git a/drivers/gpu/arm/t6xx/kbase/src/Kbuild b/drivers/gpu/arm/t6xx/kbase/src/Kbuild
index 584d5f2..e6eadd6 100644
--- a/drivers/gpu/arm/t6xx/kbase/src/Kbuild
+++ b/drivers/gpu/arm/t6xx/kbase/src/Kbuild
@@ -41,7 +41,7 @@ DEFINES = \
        -DMALI_ERROR_INJECT_ON=$(MALI_ERROR_INJECT_ON) \
        -DMALI_MOCK_TEST=$(MALI_MOCK_TEST) \
        -DMALI_COVERAGE=$(MALI_COVERAGE) \
-       -DMALI_KBASE_SRC_LINUX_PATH=$(src)/linux \
+       -DMALI_KBASE_SRC_LINUX_PATH=../../$(src)/linux \
        -DMALI_KBASE_THIRDPARTY_PATH=../../$(src)/platform/$(CONFIG_MALI_PLATFORM_THIRDPARTY_NAME) \
        -DMALI_INSTRUMENTATION_LEVEL=$(MALI_INSTRUMENTATION_LEVEL) \
        -DMALI_RELEASE_NAME=\"$(MALI_RELEASE_NAME)\"
diff --git a/drivers/gpu/arm/t6xx/kbase/src/platform/manta/mali_kbase_platform.c b/drivers/gpu/arm/t6xx/kbase/src/p
index 6140252..ad4adfe 100644
--- a/drivers/gpu/arm/t6xx/kbase/src/platform/manta/mali_kbase_platform.c
+++ b/drivers/gpu/arm/t6xx/kbase/src/platform/manta/mali_kbase_platform.c
@@ -220,7 +220,7 @@ int kbase_platform_cmu_pmu_control(struct kbase_device *kbdev, int control)
        spin_lock_irqsave(&platform->cmu_pmu_lock, flags);


#ifdef CONFIG_MALI_GATOR_SUPPORT
-       kbase_trace_mali_timeline_event(GATOR_MAKE_EVENT(ACTIVITY_RTPM_CHANGED, ACTIVITY_RTPM) | control);
+//     kbase_trace_mali_timeline_event(GATOR_MAKE_EVENT(ACTIVITY_RTPM_CHANGED, ACTIVITY_RTPM) | control);
#endif
        /* off */
        if (control == 0) {



You can now build the kernel with make.



BOOT IMAGE

In order to get this modified kernel onto the device, you need to modify a boot.img file.

A boot image file consists (mainly) of a kernel and a ramdisk.

boot.img

You can easily download this from google’s website:

https://developers.google.com/android/nexus/images#mantaray

Extract the files for either 4.3 or 4.4.2, and obtain the boot.img file.

In order to generate a new boot.img with your newly built kernel, do the following:

abootimg -u boot.img -k kernel/arch/arm/boot/zImage













Alternative scripts method:

./unpackbootimg -i boot.img
./mkbootimg --kernel kernel/arch/arm/boot/zImage --ramdisk boot.img-ramdisk.gz -o boot.img







Booting

At this stage, you can either flash the new boot image over the original stock boot image, or you can boot the image directly without flashing. With the latter option, after a reboot of the device, the original boot image will be used instead. This is useful for testing purposes.

In order to do either, you first need to boot the device into bootloader mode. This is easily done via adb:

adb reboot bootloader

To just boot directly, do:

fastboot boot boot.img

To flash the image, do:

fastboot flash boot boot.img

Your device should now boot using the custom kernel.

This can be tested by looking at Settings -> About tablet -> Kernel version

GATOR

You can obtain the driver and daemon source files from your DS-5 installation directory:

<DS-5 Installation Directory>/arm/gator/

Driver

Build the driver by doing the following, from within the gator-driver directory:

GATOR_WITH_MALI_SUPPORT=MALI_T6xx make -C <path_to>/kernel M=`pwd` modules

You should now have gator.ko.

Daemon

First, you will need to modify the structure of the gator-daemon directory in order to build for Android.

Create a folder called jni inside gator-daemon and move all files and folder to this location:

mkdir jni
mv * jni/













Then, build the daemon by doing the following, from within the gator-daemon directory:

ndk-build

You should now have gatord.

Device Setup

Unfortunately you cannot simply push these two gator files directly into the system directory on the device, due to permission issues with a secure adb device.

The way around this is to do the following. First, remount the system partition as read/write access:

adb shell su -c 'mount -o remount /system'

Next, push the files to the sdcard:

adb push gator.ko /sdcard/
adb push gatord /sdcard/













Then copy these files from the sdcard to the system directory:

adb shell su -c 'cp /sdcard/gator* /system/bin/'

Finally, give full permissions to the daemon:

adb shell su -c 'chmod 777 /system/bin/gatord'

You are now ready to use the device with Streamline support.

Using Gator

The normal procedure for using gator is as follows – and is required to be done each time the device restarts:

adb shell su -c 'mount -o remount /system'

Setup forwarding through usb instead of network (optional):

adb forward tcp:8080 tcp:8080

Launch the daemon from within an adb shell:

adb shell su -c 'gatord &'

Launch DS-5, and enter localhost (or the ip address if you didn’t do the forward command) in the connection box.

Select the counters you are interested in capturing, and you are now ready to begin capturing.

ds517_n10_ss2.png
Anonymous
  • Michael McGeagh
    Michael McGeagh over 10 years ago

    Hi Pietro,

    Unfortunately I am not aware of any development boards that have this setup preconfigured. All I would recommend is choosing a board that you have the schematics available for, and where power is accessible, so you can add your own shunts.

    Sorry I cant be of more help.

    Michael McGeagh

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
  • Pietro
    Pietro over 10 years ago

    Hello Micheal,

    Sorry for hammering.

    I am having a look to the  Odroid-XU3 you mentioned, I would like to monitor the power consumption of the device using the Energy Probe  which comes with the DS-5, as far as you can tell me, are there any boards which come with the right headers already in it ?

    As mentioned in the ARM guide I would need :

    * A target that has 2-pin IDC 0.1" power measurement headers. The target also requires a shunt resistor with a supply voltage less than 15V and rated at least 0.5W. The shunt resistor needs a 1-pin IDC ground terminal and must not drop more than 165mV.*

    Thanks,

    Pietro

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
  • Pietro
    Pietro over 10 years ago

    Thanks for your time.

    Pietro

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
  • Michael McGeagh
    Michael McGeagh over 10 years ago

    For the Nexus 10, the SoC is completely controlled by Samsung. ARM simply license IP blocks to companies such as Samsung, we did not design the SoC. As such, we do not have any SoC documentation to give out. This really is a matter to ask Samsung for advice on.

    Regarding other compatible devices, I have had much success using Hard Kernel's development devices, such as the Odroid-XU3 for the Midgard series GPU. Note these are not production devices, but development platforms.

    I hope that helps,

    Kind Regards,

    Michael McGeagh

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
  • Pietro
    Pietro over 10 years ago

    Hi Micheal,

    thank a lot for your quick answer, it makes sense. I was wondering, can we write that register bit from kernel space, I have tried to use this

    https://github.com/prabindh/peemuperf

    But since I am not sure about the SoC I am using (but I am sure it differs from the one the module is trying to configure) the result does not surprise me: it reboots

    Do you think we can manage to do it having access to the SoC docs (if available somewhere), my hope is that we should just write some registers values but I could completely wrong, I am judging by my little experience and

    viewing the souce code of that project (peemuperf).

    As alternative could you give me some hints about a widely used android device fully functional with DS5 Streamline ?

    Thanks in advance,

    Pietro

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
>
Mobile, Graphics, and Gaming blog
  • What is Arm Performance Studio?

    Jai Schrem
    Jai Schrem
    Arm Performance Studio gives developers free tools to analyze performance, debug graphics, and optimize apps on Arm platforms.
    • August 27, 2025
  • How Neural Super Sampling works: Architecture, training, and inference

    Liam O'Neil
    Liam O'Neil
    A deep dive into a practical, ML-powered approach to temporal super sampling.
    • August 12, 2025
  • Start experimenting with Neural Super Sampling for mobile graphics today

    Sergio Alapont Granero
    Sergio Alapont Granero
    Laying the foundation for neural upscaling to enable sharper, smoother, AI-powered gaming on next-generation Arm GPUs.
    • August 12, 2025