OpenCL support for Mali-T628 MP6 on Arndale Octa?

Hi bramv,

The Mali kernel-side driver doesn't need to be built as a loadable module, and I believe the Linaro default configuration has it built-in.  To build as a module, some symbols specific to the Exynos architecture need to be exported.  If you don't need to change the Mali driver, then it's easier to leave it built-in.  This should resolve your last error "Unknown symbol samsung_cpu_id".  As long as you see the kernel messages from the driver and /dev/mali* is present then it means it's initialised.

Then the driver needs some platform data, which in this case is part of the driver source code itself.  The "Platform data not specified" error should now be fixed with the "CONFIG_MALI_PLATFORM_THIRDPARTY_NAME=arndale_octa" option, which includes the "drivers/gpu/arm/midgard/platform/arndale_octa" directory.  So I believe it should just work if you make the driver built-in again.  I'm not sure why the platform name wasn't already in the default configuration; I'll try to investigate this.

Also, the kernel is reading some information from the monitor to set the appropriate video mode.  Unless you set a hard-coded mode or there's a reliable fall-back mode, the DRM driver needs the monitor to be present.

Guillaume

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