See, http://lists.infradead.org/pipermail/linux-mediatek/2018-April/012824.html
Mali-450 seems like ablely supported by lima on an out-of-tree v4.16-rc5. A reference design can be found at
and the tree can run some basic examples.
Btw, Lima is an open source implementation for mali 450 driver. However, I thought It is not mature as the driver officially ARM provides. But knowing the port to lima should be helpful for us to know how to port to driver and library ARM provided officially.
https://patchwork.kernel.org/patch/10367709/
https://patchwork.kernel.org/patch/10347783/
We add support for lima now ! Please take a look at wiki: https://github.com/yuq/mesa-lima/wiki.
can you give me the steps to include it? i guess i have to apply your patches and include the repo (https://github.com/yuq/mesa-lima) into my kernel-source-Tree.
The last step is not completely clear to me. where should it be included, will it compiled by kenel-makefile or does it need additional make-command
did i need additional kernel-options?
I’ve adopted lima driver from https://github.com/yuq/linux-lima. and patchwork (for now - w/o https://github.com/objelf/linux-lima mediatek patches)
I got this during boot:
pi@bpi-iot-ros-ai:~$ dmesg | grep lima
[ 8.492918] lima 13040000.gpu: bus rate = 500500000
[ 8.492930] lima 13040000.gpu: mod rate = 500500000
[ 8.493292] [TTM] Zone kernel: Available graphics memory: 248738 kiB
[ 8.493298] [TTM] Zone highmem: Available graphics memory: 1030560 kiB
[ 8.493302] [TTM] Initializing pool allocator
[ 8.493324] [TTM] Initializing DMA pool allocator
[ 8.494773] lima 13040000.gpu: gp - mali450 version major 0 minor 0
[ 8.494849] lima 13040000.gpu: pp0 - mali450 version major 0 minor 0
[ 8.494918] lima 13040000.gpu: pp1 - mali450 version major 0 minor 0
[ 8.494980] lima 13040000.gpu: pp2 - mali450 version major 0 minor 0
[ 8.495031] lima 13040000.gpu: l2 cache 8K, 4-way, 64byte cache line, 128bit external bus
[ 8.495040] lima 13040000.gpu: l2 cache 128K, 4-way, 64byte cache line, 128bit external bus
[ 8.505811] [drm] Initialized lima 1.0.0 20170325 for 13040000.gpu on minor 1
And, at least for now, I have no questions about kernel driver.
But during mesa installation (https://gitlab.freedesktop.org/lima/mesa using instruction at https://github.com/yuq/mesa-lima/wiki on make install) i got these errors: log (88,1 kb).
As I’m not familiar with ubuntu/debian distros I can’t resolve this problem by myself 
. I suppose that I’m missing some lib or lib-dev which is nessesary, but I’m not sure.
P.S. I’ve tried to build/install mesa on R2 itself, using ubuntu 2018-03-29-ubuntu-16.04-mate-desktop-bpi-r2-sd-emmc.
P.P.S. Latest chages are in https://github.com/d3adme4t/BPI-R2-4.14/tree/4.16-hdmi+wlan - based on franks 4.16-hdmi+wlan branch.
P.P.P.S. CONFIG_DRM_LIMA sould be configured manually - it’s not in defconf.
I guess it’s a problem similar to that: https://stackoverflow.com/questions/27171594/gcc-arm-linker-error-undefined-reference-to-strcmp (not using linker directly)
I suggest you to build those stuff in Debian environment.
Thank you for Your advice. Looks like it’s ubuntu problem.
I’m going to use Gentoo linux which I’m familiar to. 
I’ve forgot to add new files to git last time. Fixed now.
I’ve finnaly built mesa-lima. And it doesn’t work out of box:
pi@bpi-r2-gentoo ~ $ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
Xorg.0.log (31,6 КБ)
My thoughts:
./configure --with-gallium-drivers=exynos,sun4i,meson,rockchip,lima --with-dri-drivers= \
--with-platforms=drm,x11 --disable-xvmc --disable-vdpau --enable-debug
There are more gallium-drivers than just mesa probably we need another one for mediatek.
if you have mesa-lima, please give a try first with “offscreen” as below or [1] for details to say, at least it can be working for me with these offscreen examples.
But currently, i have no much idea about how to let them work on hdmi, because I don’t know how to have a good setup on xserver allowing two drm devices, gpu and hdmi, can work together and perfectly.
Maybe it requires somebody good to know xserver script can help it out.
[1] https://github.com/yuq/mesa-lima/wiki
Be able to run the following OGL application:
off-screen rendering
simple triangle: https://github.com/yuq/gfx/tree/master/gbm-surface
vertex shader uniform: https://github.com/yuq/gfx/tree/master/gbm-surface-move
multi varying: https://github.com/yuq/gfx/tree/master/gbm-surface-color
multi draw: https://github.com/yuq/gfx/tree/master/gbm-surface-draw
FBO: https://github.com/yuq/gfx/tree/master/gbm-surface-fbo
kmscube: https://github.com/yuq/kmscube
./kmscube -d -D /dev/dri/renderD128
./kmscube -d -D /dev/dri/renderD128 -M rgbaI’ve tried ro run ./kmscube -d -D /dev/dri/renderD128
And it partially works, but hangs. kmscube.log (4,8 КБ) lima-dmesg (4,7 КБ)
Probably it’s a promlem with lima kernel driver backporting drom 4.17 to 4.16
simple triangle hangs on same place
lima_pipe_flush: flags=1
Probably it should work in a way like laptop hybrig graphics - using DRI_PRIME to choose driver (e.g. intel+radeon or intel+nvidia), but i’m not sure if it’s implemented in gpu driver or in Xorg server itself.
P.S. I’m still trying to debug and run offscreen example, but w/o success.
Got attempt to merge latest lima driver (https://gitlab.freedesktop.org/lima/linux/tree/lima-4.19-rc4) to Frank’s 4.19-hdmiv5.
Long story short - it doen’t works:
[ 4.523833] [drm] hdmi-audio-codec driver bound to HDMI
[ 4.529458] lima 13040000.gpu: bus rate = 500500000
[ 4.534348] lima 13040000.gpu: mod rate = 500500000
[ 4.539401] [TTM] Zone kernel: Available graphics memory: 247120 kiB
[ 4.545824] [TTM] Zone highmem: Available graphics memory: 1028942 kiB
[ 4.552317] [TTM] Initializing pool allocator
[ 4.571794] lima 13040000.gpu: mmu gpmmu dte write test fail
[ 4.577470] [TTM] Finalizing pool allocator
[ 4.582308] [TTM] Zone kernel: Used memory at exit: 0 kiB
[ 4.587769] [TTM] Zone highmem: Used memory at exit: 0 kiB
[ 4.593253] lima 13040000.gpu: ttm finalized
[ 4.597504] lima 13040000.gpu: Fatal error during GPU init
[ 4.603098] lima: probe of 13040000.gpu failed with error -5
Now trying to figure out why.
The immediate error is in funcrion
int lima_mmu_init(struct lima_ip *ip)
But i can’t realise how and where it calls, the lastest successfull function on initialisation is
lima_init_ip(ldev, i);
I’ve not found any direct calls of lima_mmu_init, so i’m stuck.
These functions are not chaged much since 4.17, which was backported to my 4.16-lima. But now initialization doesn’t works.
Any help will be appreciated 
My plan is to add more verbode output on init.
P.S. No separate branch because no progress - driver has been simply merged from official source https://gitlab.freedesktop.org/lima/linux/ to Franks hdmiv5 branch. then next patch applied: lima-patch.diff (2,7 КБ)
Mostly init is defined in a struct and is only called if struct matches type (root=platform_device) and compatible of dts-node(s)
Imho you should start here:
https://gitlab.freedesktop.org/lima/linux/blob/lima-4.19-rc4/drivers/gpu/drm/lima/lima_drv.c#L407 and follow the functions and add printks
try to find location of this, why it is displayed and whats done before
debugging by printk 
seems this is here:
drivers/gpu/drm/lima/lima_mmu.c
74 mmu_write(DTE_ADDR, 0xCAFEBABE);
75 if (mmu_read(DTE_ADDR) != 0xCAFEB000) {
76 dev_err(dev->dev, "mmu %s dte write test fail\n", lima_ip_name(ip));
77 return -EIO;
78 }
have not found DTE_ADDR in lima source…only this with different name
it would be better to create a branch in your repo, so i can look over it if i have some time
I can report that using frank’s 4.20.0-hdmiv5 repository as a base, I transfered the lima kernel driver from the lima repository for 4.20.0 and integrated it into the build structure. I also got the gpmmu write test fail.
Then I studied the repository here (https://github.com/objelf/linux-lima)
There were a few things I added to the dtsi file that wern’t already in yours frank, that the changelog showed they added for this purpose. Then I stepped through the source changes and was able to infer their correct intergration into the 4.20.0 lima driver source. Things haven’t changed much, I crossed my fingers.
[ 9.991827] INFO@lima_mediatek_init 117 err = 0
[ 9.996582] lima 13040000.gpu: bus rate = 500500000
[ 10.001477] lima 13040000.gpu: mod rate = 500500000
[ 10.037767] lima 13040000.gpu: gp - mali450 version major 0 minor 0
[ 10.044282] lima 13040000.gpu: pp0 - mali450 version major 0 minor 0
[ 10.050789] lima 13040000.gpu: pp1 - mali450 version major 0 minor 0
[ 10.057314] lima 13040000.gpu: pp2 - mali450 version major 0 minor 0
[ 10.063834] lima 13040000.gpu: l2 cache 8K, 4-way, 64byte cache line, 128bit external bus
[ 10.071997] lima 13040000.gpu: l2 cache 128K, 4-way, 64byte cache line, 128bit external bus
[ 10.120312] [drm] Initialized lima 1.0.0 20170325 for 13040000.gpu on minor 1
I’ve not built lima-mesa yet but I’ve got the build envirionment all setup. I just wanted to share the good news cause now I get to play with it
Can you share your code, in best case fork my repo and include your changes in your repo to make a pull-request later?
That’s my intention yes - I always meant to be working with you on getting the R2 up to spec - just life got in the way all of a sudden. I’m currently compiling mesa so I can test the entire execution path - output from the lima module is exactly as expected - offscreen rendering will most likely work - I presume there are caveats for direct rendering but I’ll be in a better position to understand them with everything else working - I’ll get this working, then create a repo in alignment with yours.
I’m running two R2s, a 1.1 and a 1.2, serial debugging each other etc using your latest debian image - but I’ve switched to the testing/sid apt sources for the system running 4.20 + lima and the cross compile box - I don’t know if 4.20 works well on the R2 yet - it doesn’t seem to power off but I’ve not looked into it properly.
But I figured that lima development isn’t going to see backported features at this stage of development so it was best to setup my build around their current branch dependencies.
if you have it running on 4.20 we can try to port it back to 4.19. Afaik drm has not changed much.
Backporting to 4.14 does not make much sense in my eyes
ok mesa is compiled. meson + ninja cross compile setup seems to work great! I guess I’ll drop the binaries onto the R2 and see what I’ve broken