I suggest you to build those stuff in Debian environment.
1 Like
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.
- There is mediatek-related code in this repo which, propably, should be used too.
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
Ok - it worked successfully for off-screen rendering - but to render directly to the screen requires modifications to mesa - specifically a DRI shim for the mediatek HDMI output (basically allows rendering on Lima (/dev/dri/card1) but with the final output written to an area of graphics memory using dmabuf.
After discussions on #dri-devel and #lima on freenode IRC - I have successfully written the shim and the R2 can now render directly to the screen
I’m cleaning up my code now - making sure everything is compliant and any uneeded testing is reverted.
Then I’ll be updating my repositories with both the 4.20 kernel driver and the modified mesa with the Mediatek DRI shim driver - I’ll keep you posted.
2 Likes
How far are you with code-cleaning? We want to see how lima works
Should be tomorrow sorry for the delay - been busy, might have a surprise addition too
any news here? can you please upload to your github and make a pull request?