OpenCL support for Mali-T628 MP6 on Arndale Octa?

Hi Guillaume,

I also assumed that the driver would be build-in by using the default configuration provided by the fragments. However, there is just no /dev/mali present and the kernel messages do not contain anything about Mali. I also noted that neither modules.order nor modules.builtin contains mali_kbase.ko. That is why I proceeded to build the driver as a module instead. I just retried to compile it build-in and made sure that

CONFIG_MALI_MIDGARD=y

CONFIG_MALI_PLATFORM_THIRDPARTY=y

CONFIG_MALI_PLATFORM_THIRDPARTY_NAME="arndale_octa"

are all set. But still, the driver doesn't seem to be compiled into the kernel.

Could you by any chance send me your .config file so that I can see if some other configuration options are missing?

Hi Guillaume,

I also assumed that the driver would be build-in by using the default configuration provided by the fragments. However, there is just no /dev/mali present and the kernel messages do not contain anything about Mali. I also noted that neither modules.order nor modules.builtin contains mali_kbase.ko. That is why I proceeded to build the driver as a module instead. I just retried to compile it build-in and made sure that

CONFIG_MALI_MIDGARD=y

CONFIG_MALI_PLATFORM_THIRDPARTY=y

CONFIG_MALI_PLATFORM_THIRDPARTY_NAME="arndale_octa"

are all set. But still, the driver doesn't seem to be compiled into the kernel.

Could you by any chance send me your .config file so that I can see if some other configuration options are missing?

Hi bramv,

It seems like you've missed the mali-arndale-octa.conf configuration fragment.  This is the command I run to generate the config file:

./scripts/kconfig/merge_config.sh linaro/configs/linaro-base.conf linaro/configs/arndale_octa.conf linaro/configs/mali-arndale-octa.conf

Could you please try again with this?

Best wishes,

Guillaume

Yes it seems so. I tried again using the command that you specified.

Building the kernel image works just fine, but errors occur when building the modules:

make-j8 modules

  CHK     include/config/kernel.release

  CHK     include/generated/uapi/linux/version.h

  CHK     include/generated/utsrelease.h

make[1]: `include/generated/mach-types.h' is up to date.

  CALL    scripts/checksyscalls.sh

  Building modules, stage 2.

  MODPOST 9 modules

ERROR: "tcp_nuke_addr" [net/ipv6/ipv6.ko] undefined!

I disabled ipv6 altogether using "make xconfig" and compiled everything again. This time all is well, until I reboot. Sometimes it gives me a kernel panic:

[    6.195000] [<c005211f>] (cpu_startup_entry) from [<20008525>] (0x20008525)

[    6.195000] CPU2: stopping

[    6.195000] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.14.7-0-linaro-arndale-octa #26

[    6.195000] [<c00127a5>] (unwind_backtrace) from [<c000fba9>] (show_stack+0x11/0x14)

[    6.195000] [<c000fba9>] (show_stack) from [<c0435655>] (dump_stack+0x61/0x6c)

[    6.195000] [<c0435655>] (dump_stack) from [<c0011903>] (handle_IPI+0x16b/0x184)

[    6.195000] [<c0011903>] (handle_IPI) from [<c000848f>] (gic_handle_irq+0x57/0x58)

[    6.195000] [<c000848f>] (gic_handle_irq) from [<c001045b>] (__irq_svc+0x3b/0x5c)

[    6.195000] Exception stack(0xe611bf50 to 0xe611bf98)

[    6.195000] bf40:                                     e611bf98 00000006 71431ea3 00000001

[    6.195000] bf60: 61755fdc 00000001 e675c368 c06f670c 00000000 00000002 c06f66c0 c06f04e0

[    6.195000] bf80: 00000000 e611bf98 29aaaaab c035e052 60000133 ffffffff

[    6.195000] [<c001045b>] (__irq_svc) from [<c035e052>] (cpuidle_enter_state+0x3a/0xa8)

[    6.195000] [<c035e052>] (cpuidle_enter_state) from [<c035e145>] (cpuidle_idle_call+0x85/0x13c)

[    6.195000] [<c035e145>] (cpuidle_idle_call) from [<c000d7b1>] (arch_cpu_idle+0xd/0x2c)

[    6.195000] [<c000d7b1>] (arch_cpu_idle) from [<c005211f>] (cpu_startup_entry+0x10f/0x148)

[    6.195000] [<c005211f>] (cpu_startup_entry) from [<20008525>] (0x20008525)

[    6.195000] drm_kms_helper: panic occurred, switching back to text console

And sometimes it fails on mounting the root file system:

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.

[    8.360000] usb 5-1.4: new high-speed USB device number 3 using exynos-ehci

[    8.460000] usb 5-1.4: New USB device found, idVendor=0b95, idProduct=772a

[    8.470000] usb 5-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[    8.480000] usb 5-1.4: Product: AX88772

[    8.485000] usb 5-1.4: Manufacturer: ASIX Elec. Corp.

[    8.490000] usb 5-1.4: SerialNumber: 000001

[    8.810000] asix 5-1.4:1.0 eth0: register 'asix' at usb-12110000.usb-1.4, ASIX AX88772 USB 2.0 Ethernet, 02:0d:ce:dd:fc:24

chvt: can't open console

Gave up waiting for root device.  Common problems:

- Boot args (cat /proc/cmdline)

   - Check rootdelay= (did the system wait long enough?)

   - Check root= (did the system wait for the right device?)

- Missing modules (cat /proc/modules; ls /dev)

chvt: can't open console

ALERT!  /dev/disk/by-uuid/126fc49e-6766-4491-93c4-4580bb0fab91 does not exist.  Dropping to a shell!

Couldn't get a file descriptor referring to the console

I found that the second error might be caused by the CONFIG_DEVTMPFS option being not set. I tried again using CONFIG_DEVTMPFS=y but the errors persist.

Hi bramv,

After some more investigation, we've found that you need to use even more configuration fragments:

./scripts/kconfig/merge_config.sh linaro/configs/linaro-base.conf linaro/configs/distribution.conf linaro/configs/arndale_octa.conf linaro/configs/lt-arndale_octa.conf linaro/configs/mali-arndale-octa.conf

Then if you use this build command:

make zreladdr-y=0x20008000 uImage modules dtbs -j8

it should create a arch/arm/boot/uImage file which you can replace on the 14.08 Linaro binary image, on the boot partition.

If you see build errors related to Gator, then a quick fix is to disable CONFIG_GATOR in .config (make menuconfig...).  I hope this helps.  Please note that this kernel contains the r4p0-02rel0 kernel-side Mali driver, so only the user-side driver with the exact same version should be used.  This is not compatible with r4p1-00rel0 unless the kernel-side driver is upgraded.

Best wishes,

Guillaume

Hi bramv,

bramv wrote:

Why does the kernel identify the GPU as r0p1?

This is the GPU hardware revision, and is unrelated to the revision of the kernel or userspace driver.

Hth,

Chris

Hi bramv,

It's probably worth someone at our end testing this out as well, but as a quick sanity check can you ensure that the CPU and GPU DVFS are disabled/otherwise pinned (set CPU DVFS to performance and frequency to something high like 1.7GHz) before running the benchmark? These SoCs have a tendency to take the busfreq down with the CPUfreq when the CPU is idle, and as these GPU benchmarks tend not to stress the CPU too much, this has the effect that the bus clocks down to v/fmin and severely throttles the GPU's memory bandwidth.

Hth,

Chris

Hi Rich,

Good to know the difference between X11 and fbdev. I have one follow-up question on this. So far I have linked my OpenCL programs to libmali.so from the userspace binary package instead of using the libOpenCL.so, since libOpenCL.so gives me lots of undefined reference errors whilst using libmali.so, compilation progresses without any errors. I also noticed that libmali.so is the only substantial file in the package:

# ll ../fbdev/

total 21056

drwxr-xr-x  2 root  root      4096 Jan  1  2000 ./

drwx------ 11 root  root      4096 Jan  1  2000 ../

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libEGL.so*

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libGLESv1_CM.so*

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libGLESv2.so*

-rwxr-x---  1 16580 16580     4806 Jul 23 14:44 libOpenCL.so*

-rwxr-x---  1 16580 16580 21518354 Jul 23 14:44 libmali.so*

Is using libmali.so to lik against the correct way to go?

Regarding DVFS, the /device/dvfs file is not present on my system:

# tree /sys/class/misc/mali0

/sys/class/misc/mali0

├── dev

├── device -> ../../../11800000.mali

├── power

│   ├── autosuspend_delay_ms

│   ├── control

│   ├── runtime_active_time

│   ├── runtime_status

│   └── runtime_suspended_time

├── subsystem -> ../../../../class/misc

└── uevent

3 directories, 7 files

And your command results in a permission denied error, even though I am using a root shell:

# echo off > /sys/class/misc/mali0/device/dvfs

-bash: /sys/class/misc/mali0/device/dvfs: Permission denied

I am looking forward to seeing your clpeak results!

Hi bramv,

"libOpenCL.so" is the spec defined library name that OpenCL should be exposed as on the platform. In our case we implement this (and the GLES libs) as shims which pass through to the libmali.so binary, which is why that's the largest one there. For development purposes you can link against either, but obviously you wouldn't want to do this for a release, you'd want to link against libOpenCL.so for portability.

That said, it SHOULD work, so if you are having issues linking against libOpenCL.so feel free to share them here and we will take a look. I can't think of a good reason why one should work and the other fail.

Thanks,

Chris

All the errors are undefined reference errors at link time, the symbols should be there so offhand not sure why that's happening, but in any case linking against libmali.so is working

In your above output, ldd a.out is reporting /usr/lib/libmali.so on the first line, so thats working as expected.

Hth,

Chris

Hi Chris,

I put all files from the binary userspace driver in the /usr/lib/ directory and compiled just using: "g++ program.cpp -lOpenCL". This gives the same result as compiling like this: "g++ program.cpp /usr/lib/libOpenCL.so". The output is too long to show here.

Compiling using "g++ clpeak-arndale-octa.cpp /usr/lib/libmali.so" works just fine: But now that I am further looking into the compilation, I noticed the following:

# ldd a.out

  /usr/lib/libmali.so (0xb5e03000)

  libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb5d4a000)

  libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb5cde000)

  libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb5cbd000)

  libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb5bd6000)

  /lib/ld-linux-armhf.so.3 (0xb6f6d000)

  librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb5bc8000)

  libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb5bac000)

  libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb5ba1000)

The resulting binary does not contain any reference to a OpenCL or Mali library. Does this mean that the program runs on the CPU instead of GPU? But then, why does it report the two Mali-T628 devices? I am confused.