Mali-450 support by lima

[LeXa2 (Alexey Loukianov)]

Hey @frank-w, what is the current status of lima patches for your repos? Which branches are up to date to use if I would have a chance to give this a test?

What’s about the DTB regulator vs. board specific function in drm driver story conclusion? Am I correct that neither you nor other people in this thread were able to find how to power on/off GPU using DTB-only approach?

Also I’ve seen report from @DeadMeat that module initialization depends on the HDMI port being connected to some powered on device. Is it really the case? Had it been reproduced by other users? I’m thinking about trying to move from serial console to netconsole in u-boot and EFI grub2 plus normal HDMI console in linux - it will be easier to maintain boards in production with setup like this.

Ah, and yet another question: am I correct that to get text console working I need to have fbcon enabled, kmsconsole fb emulation enabled and working drm driver (lima in our case)? I’m wondering if it possible to have linux console working for BPi-R2 with some other driver than lima.

And while we’re at it - have anyone had any luck with using proprietary driver from ARM for utgard GPUs?

[frank-w]

Afair 5.4 is latest kernel i added lima changes…it needs a modified mesa library. And we have only the power on/off via code…no dts only version.

Hdmi console needs no lima…it works also without lima…framebuffer config options (+hdmi driver of course)

[DeadMeat (Alex R.)]

Hdmi console needs no lima…it works also without lima…framebuffer config options (+hdmi driver of course)

Thats correct. Just in case - full kernel oftion is CONFIG_DRM_MEDIATEK_HDMI

@LeXa2, just wondering, is there an EFI implementation for bpi-r2? If so where can i learn about it?

[frank-w]

just wondering, is there an EFI implementation for bpi-r2? If so where can i learn about it?

Afaik @ray created efi environment with uboot

BPI-R2 EFI FreeBSD boot

Hi guys! So, after some pause I returned to work on BPI-R2. A bit late, but work contain generic things every one will like. So now, U-Boot can run system (not kernel) from SD, MMC and connected hard drives (via AHCI). Even additional PCI-E card of class PCI_CLASS_STORAGE_SATA_AHCI works. More, it boot system using modern U-Boot’s support of EFI specs.

[LeXa2 (Alexey Loukianov)]

is there an EFI implementation for bpi-r2?

Yes and no. U-boot has the bare minimum support for EFI boot and open bootloader specification but some changes are required to work properly on R2. I had implemented these changes and use all my R2s with EFI grub2 instead of u-boot to boot operating systems. I hadn’t pushed my changes yet to my github u-boot repo though as hadn’t seen much interest for this from other people. If you’re interested in it I can try to clean up the code and push it in near future.

[DeadMeat (Alex R.)]

Lima userspace drivers: Xorg/mesa/tools/etc for BPI-R2

We can define it in bananapi.dts disabled so you to enable it only in your overlay I see you have also code changes in the mentioned commit… You can rebase needed changes on my 5.9-hdmi, then i can include it in my repo in future

Lima userspace drivers: Xorg/mesa/tools/etc for BPI-R2

We can define it in bananapi.dts disabled so you to enable it only in your overlay

I see you have also code changes in the mentioned commit…

You can rebase needed changes on my 5.9-hdmi, then i can include it in my repo in future

I’ve applied dts patch to 5.8-main and got success:

Lima related dts regulators

Following research showed that it’s likely the proper way to use lima:

examples:

d3adme4t/BPI-R2/blob/5.8-main/arch/arm/boot/dts/exynos5250-snow-common.dtsi#L397

d3adme4t/BPI-R2/blob/5.8-main/arch/arm/boot/dts/exynos5250-snow-common.dtsi#L533

and many others mali boards - please search for “mali-supply” in dts files.

So IMHO overlay is not nesessery, and we should ude dts regulator.

@frank-w, i’ve created the pull-request for your 5.8-main branch, please check it out.

5.9-branch WIP - i’ll commit it as soon as it’s done.

P.S. it’s likely applicable for 5.5 (tested in my 5.5 branch), 5.6, and 5.7, but not tested.

5.4 changes is up to you, current patches works great.

[frank-w]

If there is no more power consumption we can leave it enabled

[DeadMeat (Alex R.)]

If i remember correctly - you have an AC power meter? I don’t have it

[frank-w]

Ok, i compare with and without regulator if i find some time just squash the 2 commits add commit message (and update subject to follow mainline convensions “arm: dts: Add lima related…”) and add your signed-off (btw. You’ve committed as root) so that we can post to mainline later

[DeadMeat (Alex R.)]

squash the 2 commits

Do you mean rebase? Ok

(and update subject to follow mainline convensions “arm: dts: Add lima related…”)

Ok, can you provide some link(s) to example(s)?

[frank-w]

can you provide some link(s) to example(s)?

git log arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts

Or any other dts or my hdmi series: https://patchwork.kernel.org/project/linux-mediatek/list/?series=335017

If you git is setup right (and using as user) signed off can be added by

git commit --amend -s

author can be set with --author="…"

[DeadMeat (Alex R.)]

Ok, i have some lack of experience :

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.

[DeadMeat (Alex R.)]

Ok, i compare with and without regulator if i find some time

Do you need the kernel precompiled?

[frank-w]

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

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

[DeadMeat (Alex R.)]

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 )

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

Ok, thx

[frank-w]

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):

arm: dts: mt7623: add lima related regulator

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

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

[DeadMeat (Alex R.)]

Some power measurments:

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:

~4.67W

2. same kernel idle with lima loaded:

~4.7W

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

~5.48

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

~5.77W

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

~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.

[DeadMeat (Alex R.)]

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

I can test it.

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 ?

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.

[DeadMeat (Alex R.)]

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

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

I can test it.

in 5.9-hdmi i see lima is initialized…

I see you already did it

[frank-w]

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