Summary
Is OpenCL support for the Mali-T628 (for example as found in the Exynos 5420 SoC on the Arndale Octa board) available? If so, how to set it up?
More details
According to the vendor, OpenCL should be supported, but the Arndale Octa Wiki does not state how this can be achieved.
I am using the latest Linaro developer build and installed Mali drivers that contain OpenCL libraries for Mali T604. According to this guide, the driver actually contains references to the Mali T628. So I tried to create the udev rule as specified, which is supposed to solve a permission problem with /dev/mali0, but I found that there is no /dev/mali0 on my installation at all. So my conclusion is that the driver indeed does not support T628.
When I execute a clinfo utility, clGetDeviceInfo returns CL_OUT_OF_HOST_MEMORY for some device properties. Why can I query the GPU for some characteristics, but does this fail for some others? When running a normal application, the same error appears when trying to create an OpenCL Context.
I was surprised to find this topic, where yoshi seems to have OpenCL working and can run benchmarks on his Arndale Octa board. How is this possible if there is no driver available? Or am I just missing something? I hope that you can help me to also establish a working OpenCL development environment.
Hi bramv,
The Mali-T628 GPU supports OpenCL, absolutely, and we support this in the drivers for that GPU which we ship to our silicon customers when they licence the GPU design. The userspace drivers that you have downloaded from malideveloper.arm.com require a kernel driver integration in order to work.
If /dev/mali0 does not exist on your platform then the mali kernel driver that exposes this device has not been integrated with the kernel you are using. I believe Linaro kernels do not currently support Mali so this is expected to not be available on those kernels. You either need to integrate the kernel module with the Linaro kernel, lobby Linaro to support Mali in their kernel (would be a long term solution, don't know why they don't do this currently), or use the Insignal kernel which should support it. Yoshi is almost certainly not using a Linaro kernel, and is using one probably from Insignal which has the mali kernel module integrated.
Hope this helps,
Chris
There is indeed no /dev/mali0 on my platform. I tried compiling and installing this kernel driver to fix it, but this hasn't been successful so far. The same holds for the Insignal kernel, I didn't manage to replace the Linaro kernel with that one. The main problem seems to be that I cannot get uboot to actually boot the freshly compiled kernel.
Hi Chris,
I got the driver from Samsung/Insignal, and able to build the Andorid Image and Run. But we are observing random behavior in OpenCL APIs. Some time clcreateKernel fails and if re-run the app clcreateKernel returns success but clcreatebuffer fails with error code as zero and returned memory pointer as NULL.
Can you give some to hint where to look.
Thanks,
Veeranna
Hi Veeranna,
Can you provide us with a simple reproducer? Also please let me know the driver version you're using, with adb pull /vendor/lib/egl/libGLES_mali.so && strings libGLES_mali.so | grep r[0-9]p[0-9] assuming it's in vendor and not system.
With above said command, I got version as 1.4 Midgard-"r3p0-01bet0. I will try to give simple app to run.
Thank you for help.
Interestingly simple median filter example runs fine(openCL on T628), but our application fails. Our application has many kernels and huge memory bandwidth will it be the reason?
Any suggestion for debugging will be helpful.
Hi veerannah,
I doubt simply having a lot of kernels would in itself be a problem, nor would I expect memory bandwidth to be an issue. Can you confirm whether you are creating all of your kernels up-front before any clEnqueueNDRange commands take place, or do you somewhat interleave kernel compilation and execution? Can you also confirm whether all program objects compile without error prior to the calls to clCreateKernel that consume them?
We create all our kernels first, then we allocate required buffers and then call clEnqueueNDRange. Sometime it fails to create some kernels(some are got created). And sometimes it fails in buffer allocation. It didnt hit clEnqueueNDRange yet.
It's interesting that its not deterministic where it fails. Without a reproducer I'm afraid I'm just guessing at possible causes. Also the driver itself is quite old now, we're currently at r4p0, so it is worth asking them when they plan to provide an up to date version as this could fix it.
I tried the SGEMM sample from the SDK:
root@arndale-octa:~/Mali_OpenCL_SDK_v1.1.0/samples/sgemm# ./sgemm [PLUGIN INFO] Plugin initializing [PLUGIN DEBUG] './override.instr_config' not found, trying to open the process config file [PLUGIN DEBUG] './sgemm.instr_config' not found, trying to open the default config file [PLUGIN ERROR] Couldn't open default config file './default.instr_config'. [PLUGIN INFO] No configuration file found, attempting to use environment [PLUGIN INFO] CINSTR GENERAL: Output directory set to: . [PLUGIN INFO] No instrumentation features requested. ^C[ 384.380000] Mali<ERROR, BASE_MMU>: kbase_mmu_report_fault_and_kill Unhandled Page fault in AS0 at VA 0x00000000B6F0E100 [ 384.380000] raw fault status 0x820003C3 [ 384.380000] decoded fault status: SLAVE FAULT [ 384.380000] exception type 0xC3: TRANSLATION_FAULT [ 384.380000] access type 0x3: WRITE [ 384.380000] source id 0x8200 [ 384.400000] Mali<ERROR, BASE_JM>: kbase_job_done_slot t6xx: GPU fault 0x43 from job slot 1
root@arndale-octa:~/Mali_OpenCL_SDK_v1.1.0/samples/sgemm# ./sgemm
[PLUGIN INFO] Plugin initializing
[PLUGIN DEBUG] './override.instr_config' not found, trying to open the process config file
[PLUGIN DEBUG] './sgemm.instr_config' not found, trying to open the default config file
[PLUGIN ERROR] Couldn't open default config file './default.instr_config'.
[PLUGIN INFO] No configuration file found, attempting to use environment
[PLUGIN INFO] CINSTR GENERAL: Output directory set to: .
[PLUGIN INFO] No instrumentation features requested.
^C[ 384.380000] Mali<ERROR, BASE_MMU>: kbase_mmu_report_fault_and_kill Unhandled Page fault in AS0 at VA 0x00000000B6F0E100
[ 384.380000] raw fault status 0x820003C3
[ 384.380000] decoded fault status: SLAVE FAULT
[ 384.380000] exception type 0xC3: TRANSLATION_FAULT
[ 384.380000] access type 0x3: WRITE
[ 384.380000] source id 0x8200
[ 384.400000] Mali<ERROR, BASE_JM>: kbase_job_done_slot t6xx: GPU fault 0x43 from job slot 1
The program hangs after the [PLUGIN INFO] messages are printed. When I press ctrl+c, the kernel messages appear, indicating that the GPU run into trouble?
That looks like an integration problem to me, it's worth reporting to Linaro, as I believe that's the kernel you're using?
Finally we are able to run our application on T628. But performance numbers are not good. Do we get any improvement if we move r4p0 driver?
Any other suggestions to improve the GPU performance will be helpful.
There are a number of performance improvements present in the r4p0 driver not present in previous releases. Keep in mind that OpenCL is not performance portable, so an application optimized for another platform, or otherwise written with another architecture in mind, may not be performant when run on another platform/architecture. The below materials contain advice and detail some of the differences and considerations when moving from desktop to Mali, so let us know if they helps or if you have any further queries and we'll be happy to help.
There is the Developer Guide: Mali-T600 Series GPU OpenCL Developer Guide « Mali Developer Center
There is also the OpenCL faq: http://malideveloper.arm.com/downloads/OpenCL_FAQ.pdf
And the Laplace case study by timhar01 Technical presentation about ARM Mali-T600 GPU and ARM Mali-T700 GPU Compute - YouTube (although I recommend you watch the whole video)
I managed to get OpenCL working on the Arndale Octa board. I used the latest Linaro hwpack and file system.
then did:
sudo linaro-media-create --image-file test_image.img --dev arndale-octa --hwpack hwpack_linaro-arndale-octa_20140525-654_armhf_supported.tar.gz --binary linaro-trusty-server-20140522-661.tar.gz
to create an image to make a bootable SD card.
I then copied ahbijeet's compiled kernel files board.dtb, uImage, uInitrd from http://livehopper.com/boot.tar over the existing ones in the boot partition of the SD card.
Using the fbdev version of the userspace drivers. I was able to successfully run the sgemm example from the SDK as root, linking with libmali
Not sure exactly what I did that was different than you..
Thanks
Simon
I tried again using the rootfs, hwpack and boot files that you provided and can now also compile and run the samples from the Mali SDK!
WIth some more fiddling I also managed to compile and run my own programs. Performance however is way lower than I expected. I modified the clpeak benchmark so that it runs on the Arndale Octa, and get the following resuls:
While I would have expected to measure around 100 GFLOPS for SP compute using float4 vectors. I will have to look into this, but at least I have OpenCL running and that was the goal of this topic after all.
Thanks a lot to all of you for helping me.
Btw,
When creating this OpenCL environment on the Arndale Octa, I kept track of all commands that I executed and used them to write a brief guide on the Insignal Developer forum.
Hi Bramv,
At the risk of beating a dead horse, by my math the peak throughput of the Mali T628 MP6 in the Arndale Octa is:
17 FLOPS * 2 ALUs per core * 6 cores * 0.533Ghz (i think this is the max frequency for this board?) = 108.732 GFLOPS. But, as those cores are distributed across 2 core groups (4+2) simply using the first device available will mean you're only running on 4 cores, so that comes down to 72.488GFLOPS. That's the peak possible throughput of the A pipes, if you were to just keep pumping instructions through it which perfectly exercise all the functional units. In the real world, where kernels tend not to map perfectly to the hardware, tend to include some LS activity, tends to try and load stuff not in the cache, bandwidth is finite etc, it is not expected that you will actually achieve this in real world use cases. Asking for peak flops is the wrong question if you're really interested in peak real world performance.
I am seeing 33.27 and 33.17 SP GFLOPS for float2 and float4 respectively, or 45% of max theoretical peak (this is very good, considering its probably just using the VMUL and VADD units, havent looked into it yet), without looking at the actual code of the benchmark, which seems to indicate your environment has some issue. I will investigate why this benchmark reports almost identical perf numbers for float2 and float4. I also have to state that I've never seen clpeak before and am in no way vouching for its accuracy or usefulness when comparing GPU products.
Hth,
UPDATE: I've taken a look at the kernels and sure enough apart from right at the end they only touch the VMUL and VADD units. The workload is purely vector add and multiply, and absolutely does not touch the scalar or dot units, so you can take that 17 FLOPS down to 8, and our peak realistic performance becomes:
8 FLOPS * 2 ALUs * 4 cores (in one core group, which is 1 CL device) * 0.533 = 34.112 GFLOPS peak realistic performance.
We're seeing 33.27 GFLOPS, which is 97.5% of peak realistic performance, so not too shabby.
Hi Chris, I am glad that you did reply, you bring up some very interesting topics!
For me only one OpenCL platform containing only one device is found and when I request the number of compute units and clock frequency:
cl::Device device device.getInfo<CL_DEVICE_MAX_COMPUTE_UNITS>(); device.getInfo<CL_DEVICE_MAX_CLOCK_FREQUENCY>()
cl::Device device
device.getInfo<CL_DEVICE_MAX_COMPUTE_UNITS>();
device.getInfo<CL_DEVICE_MAX_CLOCK_FREQUENCY>()
I get 6 and 600 respectively. So I would assume that I am running on all six cores at 600 Mhz. Is there anything I can do to verify which core group is actually used?
Somewhere else mentioned the following formula for peak floating points performance:
16FP x 2 Vec4 x 6 Clusters x 0.600 GHz = 115.2 GFLOPS
Here the number of flops is 16 instead of 17, so I wonder where those numbers come from. Is there any reference document (by Mali?) that lists all important specs, like the number of FLOPS (including the exact number of vector, scalar and dot units per compute unit?
I ran clpeak on another architecture (Nvidia Tesla K40) and the program indeed measured peak performance (of about 4000 GFLOPS), therefore I assumed that I could also use this benchmark to measure peak performance of this Mali GPU. SInce this clearly doesn't work, I wonder how if I we could come up with some kernel that runs at +/- 100 GFLOPS. What benchmark are you using to measure those 33.27 GFLOPS?
You might be wondering why I am so determined to run the GPU at peak performance, but that is to ultimately be able to directly compare the efficiency of this presumably energy-efficient GPU to more common accelerators like the Nvidia Tesla K40, AMD Firepro W9100 and Intel Xeon Phi.
Is there any reference document (by Mali?) that lists all important specs, like the number of FLOPS (including the exact number of vector, scalar and dot units per compute unit?
Here the number of flops is 16 instead of 17
It must be a typo for them, it's definitely 17 max.
Is there anything I can do to verify which core group is actually used?
I normally use http://graphics.stanford.edu/~yoel/notes/clInfo.c to quickly sanity check a platform. Will run this on the chromebook to confirm when I get it running again this afternoon.
What benchmark are you using to measure those 33.27 GFLOPS?
That's with clPeak, it gives me the numbers I would expect for the work that it's doing, i.e. just vector add and multiply, no scalar, no dot product. We have a kernel which exercises all functional units, but it is obviously synthetic and not representive of a real workload. I cannot stress enough that if you are interested in real world performance, you should move away from these synthetic benchmarks and look at actual data for proper use cases. There are some real-world oriented benchmarks out there already, which already have Mali powered devices in their results.
directly compare the efficiency of this presumably energy-efficient GPU...
Do you have a workload in mind? Does clPeak represent the sort of work you will be doing? If not I'd recommend looking into existing benchmarks/applications which represent the sort of work you will be doing and use that as your basis for comparison, rather than synthetic benchmarks like this one. Will your application run on handhend smartphones/tablets, or is it intended to be run in a compute farm somewhere?
On T628 MP[5-8] there will be 2 core groups, so it should not be possible to see one device with 6 cores, they will be exposes as 2 separate devices. It might be an issue with the benchmark? That does explain where your expectation came from however
UPDATE: Have spoken to someone from the driver team, if you're only seeing one device then it must be an old driver, it's worth asking Insignal what their roadmap is for providing updates. On current drivers you will see 2 devices, one with 4 cores and one with 2.
Just to add to what Chris has said about this, this is indeed what we see with older versions of the driver. As you are seeing, with this version it does return 6 cores, though it really will only run on 4 of them. This particular SoC configures the 6 cores into 2 core-groups, 4 + 2. With the driver version you are using you can only target the 4-core group with CL... it is only later drivers that allow access to both core groups, and then it will be as separate devices so you will need to manually split the work if you want to use all the cores. (Graphics works differently and can automatically spread the workload across the entire GPU).
Hope that helps, Tim
I cannot stress enough that if you are interested in real world performance, you should move away from these synthetic benchmarks and look at actual data for proper use cases. There are some real-world oriented benchmarks out there already, which already have Mali powered devices in their results.
I totally agree that synthetic benchmarks are no proper measure for real world performance, but these benchmarks do help to determine whether the environment is set-up properly, which is clearly not (yet) the case.
Have spoken to someone from the driver team, if you're only seeing one device then it must be an old driver, it's worth asking Insignal what their roadmap is for providing updates. On current drivers you will see 2 devices, one with 4 cores and one with 2.
By now the r4p0-02rel0 drivers are available. I tried running the benchmarks using them instead of the r3p0-02rel0 drivers that I used before, however the runtime fails to create an OpenCL context.
Someone opened a topic on the Insignal forum about the latest drivers, it seems that I have to compile my own kernel using the latest kernel driver to get it working.
Hi Bram,
Yes thats correct the old kernel driver will not work with the new userspace driver, the kernel needs recompiling with the new kernel driver.
Are you able use all 6 cores T628?. If you are succeeded can you give complete steps to builds required binaries.
No unfortunately not. I tried to run this image to get it up and running but the board wouldn't boot.
I am now running a linaro image using kernel 3.15.0-1-linaro-arndale-octa. But so far I haven't been able to build a mali kernel driver module myself either: Update: see end of post
root@arndale-octa:~/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard# make -C /lib/modules/`uname -r`/build M=$PWD modules make: Entering directory `/usr/src/linux-headers-3.15.0-1-linaro-arndale-octa' Building modules, stage 2. MODPOST 0 modules make: Leaving directory `/usr/src/linux-headers-3.15.0-1-linaro-arndale-octa'
root@arndale-octa:~/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard# make -C /lib/modules/`uname -r`/build M=$PWD modules
make: Entering directory `/usr/src/linux-headers-3.15.0-1-linaro-arndale-octa'
Building modules, stage 2.
MODPOST 0 modules
make: Leaving directory `/usr/src/linux-headers-3.15.0-1-linaro-arndale-octa'
No ko file is being generated.
The driver includes some scons files, but they do not work for me. First of all, a Sconstruct file is not included. When adding one myself and running scons, the environment is not recognized:
root@arndale-octa:~/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm# scons scons: Reading SConscript files ... scons: *** Import of non-existent variable ''env'' File "/root/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard/sconscript", line 20, in <module>
root@arndale-octa:~/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm# scons
scons: Reading SConscript files ...
scons: *** Import of non-existent variable ''env''
File "/root/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard/sconscript", line 20, in <module>
So I figured, let's fix this by replacing Import('env') by env = Environment(ENV = os.environ) but the dictionary class that scons uses does not handle non-existent keys the way the sconscript expects it:
scons: Reading SConscript files ... KeyError: 'v': File "/root/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/Sconstruct", line 1: SConscript('midgard/sconscript') File "/usr/lib/scons/SCons/Script/SConscript.py", line 609: return method(*args, **kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 546: return _SConscript(self.fs, *files, **subst_kw) File "/usr/lib/scons/SCons/Script/SConscript.py", line 260: exec _file_ in call_stack[-1].globals File "/root/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard/sconscript", line 28: if env['v'] != '1': File "/usr/lib/scons/SCons/Environment.py", line 412: return self._dict[key]
KeyError: 'v':
File "/root/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/Sconstruct", line 1:
SConscript('midgard/sconscript')
File "/usr/lib/scons/SCons/Script/SConscript.py", line 609:
return method(*args, **kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 546:
return _SConscript(self.fs, *files, **subst_kw)
File "/usr/lib/scons/SCons/Script/SConscript.py", line 260:
exec _file_ in call_stack[-1].globals
File "/root/TX011-SW-99002-r4p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard/sconscript", line 28:
if env['v'] != '1':
File "/usr/lib/scons/SCons/Environment.py", line 412:
return self._dict[key]
Any help on compiling this kernel module is highly appreciated!
Update:
I managed to compile the kernel module. It turns out that you don't need the scons files at all and can just use the included Kbuild and Makefile. Compiling mali_kbase.ko is a matter of running:
CONFIG_MALI_MIDGARD=m make
But inserting this module into the kernel does not provide a /dev/mali, neither does lshw detects a GPU. This means that we still cannot run OpenCL on the T628. How can we make the /dev/mali device show up?
/dev/mali should show as soon as you insmod a correctly built Mali kernel module. If /dev/mali is not appearing then the kernel module is not correctly built and configured for the platform. Even if you successfully build and insert a correct kernel module for the platform userspace functionality, such as OpenCL, will not be available without Mali userspace binaries matching the version of the Mali kernel module.
Can you confirm the kernel you are trying to compile with/against and the versions of Mali kernel and userspace you have available to you, as ARM have only currently released the r4p0 userspace binaries, though r4p1 should be available through the malideveloper site in the not too distant future.
Could you also confirm the steps you have taken to configure the Mali kernel source for use with the Arndale Octa board, especially as I can see you are trying to build it out of tree? You need to configure the kernel device tree and add platform specific configuration to the kernel to set up interrupts and memory addresses etc. The easiest way to integrate the latest version of the kernel would be to download the Linaro kernel for Arndale Octa and extract the r4p1 kernel source INTO the kernel source, overwriting the included r4p0 kernel source as this will keep the platform integration files intact. Looking at the kernel source you mentioned in your earlier post "II-arndale-octa" I can see that the platform integration files are present, for example in /drivers/gpu/arm/midgard/platform/5420. You could try extracting the r4p1 kernel source into this kernel tree and building that way.
Rich
Hi Rich,
In fact, I didn't configure anything at all but just ran:
And ended up with this module for the r4p1 kernel driver:
filename: /lib/modules/3.15.0-1-linaro-arndale-octa/kernel/drivers/gpu/arm/midgard/mali_kbase.ko version: r4p1-00rel0 license: GPL srcversion: 29BCA495EB0E26992A9C01E alias: of:N*T*Carm,mali-midgard* alias: of:N*T*Carm,malit6xx* depends: vermagic: 3.15.0-1-linaro-arndale-octa SMP mod_unload ARMv7 p2v8
filename: /lib/modules/3.15.0-1-linaro-arndale-octa/kernel/drivers/gpu/arm/midgard/mali_kbase.ko
version: r4p1-00rel0
license: GPL
srcversion: 29BCA495EB0E26992A9C01E
alias: of:N*T*Carm,mali-midgard*
alias: of:N*T*Carm,malit6xx*
depends:
vermagic: 3.15.0-1-linaro-arndale-octa SMP mod_unload ARMv7 p2v8
And this one for r4p0:
Next I downloaded the following kernel: linux-linaro-3.15-2014.06, because it seems to be the closest match to the running kernel: 3.15.0-1-linaro-arndale-octa. I enabled the Mali options in the kernel configuration:
Enable Mali GPU support in Gator -Mali-400MP or Mali-450MP +Mali-T604 or Mali-T658 Path to Mali driver: drivers/gpu/arm/midgard
Enable Mali GPU support in Gator
-Mali-400MP or Mali-450MP
+Mali-T604 or Mali-T658
Path to Mali driver: drivers/gpu/arm/midgard
To do so I had to enable some timers and performance events options as well. The path points to the r4p0 driver that I copied into the kernel tree. Why does the configuration option only mention T604 and T658, and not T628?
After running "make modules" I had once again a mali_kbase.ko, but the result is the same as for the out-of-tree build: no /dev/mail.
The next step was to build and flash the full kernel. Apparently the kernel I used is not fully compatible since the -arndale-octa postfix is missing. As a result I had to modify some filenames to get the new kernel installed. Unfortunately this didn't work, the board does not boot any more. I have been looking for the proper linaro arndale-octa kernel source so that I can try it again, but haven't found it yet since it appears that only the binary hwpack and rootfs are available. Will be continued.
There is a newer Linaro kernel and full Ubuntu binary images with Mali r4p0-02rel0 driver already integrated for the Arndale board. If you want to run some applications using the Mali-T604 GPU and you just need a working Arndale system, you can download a full Ubuntu binary image from the 14.08 Linaro Releases.
The r4p1 user-side binary drivers will soon be released on our public download page mentioned previously, but in the meantime the latest version you can use is r4p0. If you're interested in rebuilding the Linux kernel for other reasons than upgrading the Mali driver, you can get the Linaro source code from Linaro Git Hosting - gwg/linaro-lsk.git/shortlog. The commit used in the binary release is 14c58eb6 and you'll need to generate the kernel configuration file using a script and the following fragments (see Linaro documentation for more details):
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
Hope this helps!
Best wishes,
Guillaume
Sorry, I mentioned the Arndale board in my previous comment but you're using an Arndale Octa which has a Mali-T628 GPU. You'll need to use a different version of the binary Linaro Releases, which also contain a different user-side Mali driver binary. The kernel source and configuration I mentioned are correct for Arndale Octa.
Hello Guillaume,
These are very useful replies indeed!
I downloaded the linaro-lsk kernel, checked out the lsk-v3.14-lt-mali-r4p0-beta2 branch and configured it using the linaro-base.conf, distribution.conf and arndale_octa.conf fragments that I got from here, using the scripts/kconfig/merge_config.sh script.
I noticed that there are no referenced to gator or mali_kbase in neither modules.buitlin or modules.order, is that correct?
While booting the board, it hangs on initializing DRM:
[ 5.935000] console [ttySAC3] enabled [ 5.935000] [drm] Initialized drm 1.1.0 20060810 [ 5.940000] i2c i2c-2: attached exynos4210-hdmiddc into i2c adapter successfully [ 5.950000] exynos-mixer 14450000.mixer: probe start [ 5.955000] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 5.960000] [drm] No driver support for vblank timestamp query. [ 5.965000] [drm:exynos_drm_connector_get_modes] *ERROR* Panel operation get_edid failed -19
[ 5.935000] console [ttySAC3] enabled
[ 5.935000] [drm] Initialized drm 1.1.0 20060810
[ 5.940000] i2c i2c-2: attached exynos4210-hdmiddc into i2c adapter successfully
[ 5.950000] exynos-mixer 14450000.mixer: probe start
[ 5.955000] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.960000] [drm] No driver support for vblank timestamp query.
[ 5.965000] [drm:exynos_drm_connector_get_modes] *ERROR* Panel operation get_edid failed -19
This is without connecting any display. With display, the error is different:
[ 5.940000] console [ttySAC3] enabled [ 5.945000] [drm] Initialized drm 1.1.0 20060810 [ 5.950000] i2c i2c-2: attached exynos4210-hdmiddc into i2c adapter successfully [ 5.955000] exynos-mixer 14450000.mixer: probe start [ 5.965000] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 5.970000] [drm] No driver support for vblank timestamp query.
[ 5.940000] console [ttySAC3] enabled
[ 5.945000] [drm] Initialized drm 1.1.0 20060810
[ 5.950000] i2c i2c-2: attached exynos4210-hdmiddc into i2c adapter successfully
[ 5.955000] exynos-mixer 14450000.mixer: probe start
[ 5.965000] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.970000] [drm] No driver support for vblank timestamp query.
I have seen that before while trying this kernel.
After retrying for a few times the kernel did finally boot, but here is no sign of mali_kbase. While running the new kernel, I configured mali_kbase to be compiled as module and loaded it. It does not seem to work:
[ 424.745000] mali 11800000.mali: Platform data not specified [ 424.750000] mali: probe of 11800000.mali failed with error -2
[ 424.745000] mali 11800000.mali: Platform data not specified
[ 424.750000] mali: probe of 11800000.mali failed with error -2
So I set MALI_EXPERT=y and CONFIG_MALI_PLATFORM_THIRDPARTY_NAME=arndale_octa, but this gives a warning during compilation:
WARNING: "samsung_cpu_id" [/root/linaro-lsk/drivers/gpu/arm/midgard/mali_kbase.ko] undefined!
And the module fails to load:
[ 2174.100000] mali_kbase: Unknown symbol samsung_cpu_id (err 0)
I have been looking into the source and build files of this module but can not identify the issue. What can I do to properly compile this module?
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.
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"
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?
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?
View all questions in Graphics and Gaming forum