Mali-450 support by lima

Ok, i have some lack of experience :slight_smile: :

git push
Username for 'https://github.com': d3adme4t
Password for 'https://[email protected]':
To https://github.com/d3adme4t/BPI-R2.git
 ! [rejected]                  5.8-main -> 5.8-main (non-fast-forward)
error: failed to push some refs to 'https://github.com/d3adme4t/BPI-R2.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

after rebasing.

UPD: done with --force, but looks like i messed up with authors

TODO: fix author.

Do you need the kernel precompiled? :slight_smile:

No i can compile myself…need 2 versions with/without change and it’s easier if i do it bacause after build i upload to tftp :slight_smile:

Author is still root…and please add commit message and signed-off

Sure, right afte i figure it out. (Tommorow it’s 00:37 my local time :slight_smile: )

Ok, thx :slight_smile:

As it is your top-most commit amend is enough (if not rebase is needed for edit-mode)

First add your signed off and add commit-message (describing what you do with commit) below the subject,above signed-off (leave one blank line between message and signed off).

git commit --amend -s

Copy name+email from signed off and use it to set author as it is same format

git commit --amend --author="name <email>"

You need force push again because commit-hash has changed

this is how it should look (example):

running 5.8-main from tftp (no modules) without the patch is 4.4w after stabilization…with regulator it is same…so with dts-node alone there is no more power-consumption, maybe with lima module loaded, but thats also with the other patch from 5.4.

so if lima works now in 5.9 i can send patch to mainline (need to build mesa again…)

For building mesa: Is there anything different to instructions i posted to my wiki https://wiki.fw-web.de/doku.php?id=en:bpi-r2:hdmi#lima ?

@DeadMeat have you seen lima issue again on 5.8? [BPI-R2] Kernel Development

Crosscompile seems to be possible https://sunxi.org/Mali_Open_Source_Driver#Cross_Compiling if that does not work,we can add a chroot like i do for building hostapd

build_hostapd.sh (753 Bytes) buildchroot.sh (1,2 KB) But how to catch the files installed to pack them in tar.gz/deb? Maybe with destdir :smiley:

this is patchfile and build-script…last line have to be changed anyhow to install into other directory for packing mesabuild.sh (662 Bytes) mesa.patch (1017 Bytes) for travis/script-build we need to install depencies first

sudo apt-get build-dep mesa # after enabling source-packages

in 5.9-hdmi i see lima is initialized…

root@bpi-r2:~# dmesg | grep lima                                                
[   10.479118] lima 13040000.gpu: gp - mali450 version major 0 minor 0          
[   10.492463] lima 13040000.gpu: pp0 - mali450 version major 0 minor 0         
[   10.505431] lima 13040000.gpu: pp1 - mali450 version major 0 minor 0         
[   10.518215] lima 13040000.gpu: pp2 - mali450 version major 0 minor 0         
[   10.530953] lima 13040000.gpu: pp3 - mali450 version major 0 minor 0         
[   10.543583] lima 13040000.gpu: l2 cache 8K, 4-way, 64byte cache line, 128bits
[   10.558019] lima 13040000.gpu: l2 cache 128K, 4-way, 64byte cache line, 128bs
[   10.573732] lima 13040000.gpu: bus rate = 500500000                          
[   10.584858] lima 13040000.gpu: mod rate = 500500000                          
[   10.597993] [drm] Initialized lima 1.1.0 20191231 for 13040000.gpu on minor 1
root@bpi-r2:~# 

xserver seems to use the mesa-driver i compiled for 5.4…

[    27.438] (II) xfree86: Adding drm device (/dev/dri/card1)                   
[    27.440] (II) xfree86: Adding drm device (/dev/dri/card0)                   
[    27.460] (II) no primary bus or device found                                
[    27.460]    falling back to /sys/devices/platform/13040000.gpu/drm/card1    
e loaded elsewhere.                                                             
[    27.460] (II) "glx" will be loaded by default.                              
[    27.460] (II) LoadModule: "glx"                                             
[    27.465] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so            
[    27.569] (II) Module glx: vendor="X.Org Foundation"                         
[    27.570]    compiled for 1.20.4, module version = 1.0.0                     
[    27.570]    ABI class: X.Org Server Extension, version 10.0
1 Like

Some power measurments:

Google Photos

I remembered that my usb power-metes supports voltage up to 24V so i measured the routers power comsupltion:

  1. 5.4 kernel, idle, with lima support, and lima module removed:

Google Photos ~4.67W

  1. same kernel idle with lima loaded:

Google Photos ~4.7W

  1. same kernel,Xorg,DE, and glxgears running:

Google Photos ~5.48

  1. same, but extreme tux racer instead of glxgears:

Google Photos ~5.77W

  1. same, DE and xorg are shutted down after previous tests:

Google Photos ~4.75W

So in my measurements max difference between idle and not initialized lima is about 0.1W

P.S. In all tests i’ve usef @frank-w’s latest debian image with it’s kernel and if i remember correctly it enables lima power only on lima init, so removed module prevents GPU from power-on.

P.S. I’ll try to perform same tests with 5.8-main with and without dts-regulators in a coupleof days.

I can test it.

It’s generally the same, but in master branch which i use, you’ll need to replace -Dgallium-drivers=kmsro,lima to -Dgallium-drivers=kmsro,lima,swrast in order to satisfy vulkan dependency, or to explicitly disable vulkan support. It also required meson version > 0.5x which should be installed from sid in debian.

P.S. as for me in git master there are some issues fixed: at-least with blinking buttons/menus in DE, and it’s more stable.

No, after i’ve updated from rc to 5.8-main, but i didn’t used 88x2bu wifi anymore.

I see you already did it :slight_smile:

Which version should we use without the meson depency from unstable? Does it also requre gallium change?

Sorry, didn’t get it, which version of what?

All steps are the same as described before, the only chage is meson version: the latest in debian 10 is 0.49.2, and the minimal required is 0.5x (i dont remember exactly) and the sid’s version is 0.55.1-1. It (0.55) likely shold be moved to buster-backports in some time but idk any dates.

No other changes

P.S. If you meant which version of mesa that is not affected by debian’s meson version - i dont know. We should try latest stable 20.0.x. current git is 20.2.

P.S.S if i got it right - https://gitlab.freedesktop.org/mesa/mesa/-/pipelines/159793

20.0.8 builds with meson v 0.49.2

FIX: current git is 2.3.0 so 2.2.x is probably already released

1 Like

Could you test 5.9-hdmi if lima works with tuxracer or glxgears? If yes i can post patch to mainline (if it is ok for you)

Glxgears Works!

extreme tux racer - works!

supertuxkart - works!

openarena - out of memory

[  590.538090] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-c8.scope,task=ioquake3,pid=2773,uid=1000
[  590.554847] Out of memory: Killed process 2773 (ioquake3) total-vm:1336936kB, anon-rss:161932kB, file-rss:31052kB, shmem-rss:80012kB, UID:1000 pgtables:576kB oom_score_adj:0
[  590.692414] oom_reaper: reaped process 2773 (ioquake3), now anon-rss:0kB, file-rss:0kB, shmem-rss:80168kB

I’m totally fine :slight_smile: , maybe we shoul check regulators name, but i think it’s fine :slight_smile:

UPD. I fonund some instability on DE resolution change - on both 5.4 and 5.9

it makes a lot of output on 5.4 - so i’ve rebooted it. and 5.9 shows:

[  770.437126] lima 13040000.gpu: mmu command 3 timeout
[  770.949376] [drm:lima_sched_timedout_job [lima]] *ERROR* lima job timeout
[  770.956335] lima 13040000.gpu: fail to save task state from Xorg pid 2345: error task list is full
[  770.965373] lima 13040000.gpu: gp task error int_state=0 status=a
[  790.923764] broken atomic modeset userspace detected, disabling atomic

on 5.9

Likely gp task error is a DRM/mesa issue both of which are already in mainline. So it should be ok to send patch to mainline (i don’t have any other mali-powered board to check it’s behavior )

With lima unloaded ewerything is ok.

P.S. only for DE - fullscreen games seems fine.

1 Like

Thanks for testing. I guess oom is not a lima/drm issue. I got oom_reapers also while using git (bare repo in lxc) at the moments git wants to repack. I solved it with a 4g swap-file on ssd…maybe it helps you here too

swapfile=/var/swap.img
if [[ ! -e $swapfile ]];then
  dd if=/dev/zero of=$swapfile bs=1M count=4096
fi
chmod 0600 $swapfile
mkswap $swapfile
swapon $swapfile

No ssd on test board (yet, awaiting for a case) :wink: But i’ve created a swap partition on SD, just need to activate it.

arena with swap:

loading:

Google Photos

started - there are some atrifacts

Google Photos

testing:

and…

:slight_smile:

OOM killer with swap, anyway - not a lima problem :wink:

renamed the regulator to look more than the others and moved mali-node to have alphabetical order:

https://patchwork.kernel.org/patch/11746419/

btw. how big is your swap (partition)?

:+1:

4Gb, but it seems not to be used at all :slight_smile:

Have you mounted it as swap (maybe swapon is also needed)? You can also try my file approach

Sure :slight_smile: it shows 4GB of available swap

No difference.

Anyway it’s out fo topic :slight_smile:

P.S. You can also test it apt-get insall openarena :wink:

Dts is now also merged including lima regulator

https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.9-next/dts32

Only the tdms-patch is now open (ck asked someone from mtk about it).

@dwmw2 for your Patch (i owned because i moved many additional nodes) i got message from Steven Rottwell:

Fixes tag

Fixes: 1f6ed224594 (“arm: dts: mt7623: add Mali-450 device node”)

has these problem(s):

  • SHA1 should be at least 12 digits long Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11 or later) just making sure it is not set (or set to “auto”).

It was only 11 chars but fixed by matthias to 1f6ed2245946 just as note for further Patches :slight_smile: