chromebook_peach: research: Improving Support

[TheNathan0]

Hello!

From my understanding, the images provided for Peach-Pit aka the XE503C12 should have Mali hardware acceleration straight out of the box. From my testing of both the Debian and Xubuntu images released for Peach-Pit (XE503C12), it appears that hardware acceleration does not work in any capacity, the desktop runs okay but sluggish most of the time.

At times performance is somewhat poor and sometimes acceptable. Somewhere I did read that Xorg performance would be poor (while being accelerated).

One of the last things I attempted to confirm that hardware acceleration was not present was by running 'es2gears -info' and 'es2_info' both and after a bit, I was able to determine that hardware acceleration was not present; it appears that llvmpipe is being utilized in everything I tried.

For example: I attempted on Debian image 'es2gears -info' and it did not display that it was using any Mali drivers (then with a message that libEGL failed to authenticate) and it instead saying it was using LLVMPIPE provided by VMware (when comparing my results to an Asus Tinkerboard that also has a Midgard GPU on its premade Debian image by Asus, es2gears will report the driver being used with its vendor being Mali).

Afterwards I tried to see if the older Xubuntu image provided could potentially work, trying the old release provided alongside the new one did not help. The same issue is still present regardless. On the older build, I found an armsoc install script which ended up working without issue but despite that, I rebooted and still got nothing. Still no hardware acceleration at all.

Not sure why none of the images have any kind of working Mali hardware acceleration.

[hexdump0815]

hello,

there is no really good gpu accel (it is important to note that on most arm systems gpu acceleration and video acceleration are two different things) for exynos54xx - the kernel has a driver for the legacy mali blob and there should be a script in /scripts to install the mali blob and one to install gl4es and with both it is possible to somehow to get opengl somewhat working by pointing LD_LIBRARY_PATH to gl4es and the fbdev mali blob and use the LIBGL_FB=3 option for gl4es but it will still be slow as all the content is copied around quite a bit in memory. not sure, but it might be possible to use the armsoc xorg driver together with the normal (i.e. not fbdev) mali blob to get somewhat better acceleration, but it will need quite a bit of trying and it might even fail. in the end if you really need gpu accel then this system is maybe the wrong one. sadly this old midgard gpu is not yet supported by the open source panfrost driver (and most probably never will be).

[TheNathan0]

hello,

there is no really good gpu accel (it is important to note that on most arm systems gpu acceleration and video acceleration are two different things) for exynos54xx - the kernel has a driver for the legacy mali blob and there should be a script in /scripts to install the mali blob and one to install gl4es and with both it is possible to somehow to get opengl somewhat working by pointing LD_LIBRARY_PATH to gl4es and the fbdev mali blob and use the LIBGL_FB=3 option for gl4es but it will still be slow as all the content is copied around quite a bit in memory. not sure, but it might be possible to use the armsoc xorg driver together with the normal (i.e. not fbdev) mali blob to get somewhat better acceleration, but it will need quite a bit of trying and it might even fail. in the end if you really need gpu accel then this system is maybe the wrong one. sadly this old midgard gpu is not yet supported by the open source panfrost driver (and most probably never will be).

Are you sure that hardware acceleration is not achievable currently? I've seen somewhat modern Ubuntu images with working hardware acceleration for the Odroid XU3 and XU4 that have the exact same GPU as the ChromeBook XE503C12 (Peach-Pit) which is the Mali T628 MP6.

https://www.hardkernel.com/blog-2/ubuntu-18-04-for-odroid-xu4

Most people do not expect OpenGL to run but OpenGL ES (and I've seen someone recompile KDE I believe to run on OpenGL ES).

[hexdump0815]

it might work, but some experimenting is required - maybe look at how they did it there and try to do it the same way - if it works for the xu4 the chance is good that it will also work for the paech pit ... please post an update here in case you get anything working ... the key starting points are: the armsoc xorg driver as described here (should work for exynos too and requires "armsoc" instead of "modesetting" in the xorg.conf): https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.av7-mali-rk3288#L15-L22 and either this https://github.com/hexdump0815/linux-mainline-and-mali-exynos5422-kernel/blob/master/misc.e54/opt-mali-exynos5422-armv7l.tar.gz or this https://github.com/hexdump0815/linux-mainline-and-mali-exynos5422-kernel/blob/master/misc.e54/opt-mali-exynos5422-r5p1-armv7l.tar.gz mali blob

good luck!

[TheNathan0]

it might work, but some experimenting is required - maybe look at how they did it there and try to do it the same way - if it works for the xu4 the chance is good that it will also work for the paech pit ... please post an update here in case you get anything working ... the key starting points are: the armsoc xorg driver as described here (should work for exynos too and requires "armsoc" instead of "modesetting" in the xorg.conf): https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.av7-mali-rk3288#L15-L22 and either this https://github.com/hexdump0815/linux-mainline-and-mali-exynos5422-kernel/blob/master/misc.e54/opt-mali-exynos5422-armv7l.tar.gz or this https://github.com/hexdump0815/linux-mainline-and-mali-exynos5422-kernel/blob/master/misc.e54/opt-mali-exynos5422-r5p1-armv7l.tar.gz mali blob

good luck!

Here are some notes and observations I've made. The main point will be listed at the bottom stating from the bold and italicized part of the text.

I checked around. I'm not sure where to go about exactly. The Odroid XU4 apparently even has Ubuntu Focal support as well with full GPU acceleration with the same Mali GPU. They won't exactly explain how they did it. They interpreted into what is known as "hardkernel" which is made for Odroid devices. They did a lot of patch work apparently.

I'd like to get hold of the team responsible for that Ubuntu Focal image. It looks like it may not even need that much work after all.

The script to install the xserver armsoc driver seems have no changes at all. I forgot what I did but I installed a package made for Exoynos which was some kind of ARMSOC driver. That didn't help.

I managed to get that X11 T62x package that's in Ubuntu Focal to install BUT when I tried to run es2gears, I actually got something about it expecting some Mail device on some driver number but it couldn't find it. I forgot the exact error. It expected a driver version that failed to load. It was like version 0 but the lowest Mali offers is version 4? Something like this.

Someone managed to achieve hardware acceleration I believe on Peach-Pit and was trying to get Panfrost working. This person seems to have not done really anything since 2019 and briefly mentioned what they did and rather went on about their attempts at getting Panfrost working. This person was on Debian SID. That thread got closed however.

What we may want to do about this:

Hardware acceleration and video acceleration both are indeed possible when you look at the XU4 Ubuntu 20 and 18 image. The question is that we have to somehow obtain documentation of the patches utilized and how they were implemented into the hardkernel. If we can do the exact same thing that was done for the Odroid image, we could get it to run.

The version 18 build of Ubuntu uses the older 4.14.37 LTS kernel. Version 20 is running on the 5.4.87 LTS kernel.

https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_5.4/mate/20210113

https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_4.14/20180501

Does anyone know how to get ahold of the Odroid guys? I think it would be of great help if they could provide us some information to replicate what they did.

[smcavoy]

For the kernel: In the odroid wiki I found a link to the 5.4.x kernel used.

This should allow a kernel to be compiled for snow/peachpit assuming the kernel config options are enabled.

There is an existing 5.10.xx config file for snow/peach. Comparing this to the odroid kernel config default you should be able to figure out odroid/exynos specific options needed.

Of course if there is a list of mainline kernel config options needed for snow/peach this would allow for simply enabling them on the odroid 5.4.x kernel. @hexdump0815 Does such a list exist?

For libraries: I do not see any thing obvious as to patches needed to make use of the kernel (Mali) drivers..

Getting a hold of hardkernel/odroid: I would suggest their kernel GitHub page and/or the odroid forums

[hexdump0815]

all the kernel bits at least for the gpu are in there already (its the code from odroid actually) - you just have to build the xorg armsoc driver as described in the link above and put the libs from the mali blob from the link above somewhere, so that the linker can find them (LD_LIBRARY_PATH might be good for testing) and then it should work or fail ... i might hava a look at it myself, but its not high priority for me, so it might take some time until i get there

video acceleration is most probably done in userland by heavily patching certain libraries, so changing the basic ubuntu/debian system quite a bit - i would say this is not really worth the trouble as peach pit should be fast enough to decode video in software as well up to maybe 720 i guess

[TheNathan0]

More note taking and more observation work I have just made.

It looks like a lot of patching has been done for the Ubuntu images. I think if I were to flash their image to an SD card and then flash the kernel from your Focal image, I think might give off some good results I'd imagine. It looks like someone on the Odroid forums also had issue with the latest Focal build with upgrading their system libraries and all of that fun stuff that you normally do ended up breaking the Mali hardware acceleration (but it did end up getting fixed).

There's a high chance that this idea with the SD card having the Odroid image + your Focal kernel partition would actually work. The XU3 and XU4 both have nearly identical CPUs in the same line of Exynos CPUs with that Mali T628 MP6 that we're trying to get acceleration working with. Since you've stated the kernel bits for the GPU are already there and it being from Odroid, I'd imagine without much work done could we get an Odroid image up and running. I may would want to just flash your Focal image first, then focus on Odroid's Focal image afterwards (specifically the root partition).

This would be good for experimentation purposes and if GPU acceleration ends up working by this route, then I think that would be a great start. This would be the quickest and most easiest way to get hardware acceleration to test and play around with.

I'm guessing that the Odroid XU4/XU3 builds of Ubuntu Focal (20LTS) as well have custom repos in the sources.list; the wording from the Bionic Beaver (18LTS) with "Mali GPU access could be blocked by a recent Canonical's EGL package. In that case, you need to install our Mali driver manually."

It does state "our Mali driver manually" followed with the "sudo apt-get install mali-x11 --reinstall" would only lead me to believe that a lot of their patched libraries are in their repositories. I don't know if this helps confirm this suspicion but I'm pretty sure I saw on some Linux forum somewhere or was it the Odroid forum that someone tried to use the Odroid XU3/XU4 Ubuntu images (don't remember if it was Bionic Beaver or Focal) as like a base to examine to get their Debian installation hardware accelerated? (I think it was Armbian). Someone commented with something along the lines of not to mix Ubuntu repos with Debian? Something like this.

I can't vouch to say that mixing Ubuntu and Debian repos together is good idea but I think I've seen the Asus Tinkerboard use a few Ubuntu repos already (sometimes Debian and Ubuntu packages do get along). Could Odroid's repos be Ubuntu specific? It may not actually be Ubuntu specific but also meant for Debian as well.

Also side note I noticed here is how Asus is managing to release Debian Stretch images for their Midgard (the more newer line of Midgard) machines such as the Tinkerboard (I have the original version of the Tinkerboard). I'd wonder a motive for Asus staying on Stretch is for compatibility with Midgard? I was able to test es2gears on the Tinkerboard and it did indeed work with telling me the info I needed to confirm it was being done by the GPU.

In the middle of writing this, I found someone who actually posted a Debian Stretch image for the Odroid XU3 and XU4

https://forum.odroid.com/viewtopic.php?t=30552

There's a screenshot that shows OpenGL ES working with hardware acceleration on the Mali T628 MP6 Debian Bullseye? Currently looking for a build with hardware acceleration to also examine. The solution may realistically be as simple as doing a sources.list swap. I wonder if that Debian image is using Odroid's repos.

I remember trying to use older Debian repos to get their T62x driver to install (because Bullseye became the first version to not have it in their repos). That did not help, it refused to install. There might be a potential compatibility issue that doesn't seem worth it for some to patch out and fix at least on Debian that it's been left on Debian Stretch (my best guess). Interestingly the Tinkerboard which is also Mali Midgard based also is stuck on Debian Stretch.

There's a Fedora image that I see that seems to offer GPU acceleration as well. https://forum.odroid.com/viewtopic.php?f=96&t=39163 I'd definitely like to see the repos being used for the Fedora image and see what they're using. Audio seems to be broken due to the Fedora build using Pipewire.

I think this is all good progress.

EDIT: Armbian Buster? https://forum.odroid.com/viewtopic.php?f=96&t=24309 Never mind, maybe Debian support was not of many people's concerns when it came to people using their Odroid device with hardware acceleration. Looks like Chromium hardware acceleration is also doable (this link is coming from someone showing how it's done for Armbian) https://forum.armbian.com/topic/6576-odroid-xu4-webgl/

Buster I believe is the last version of Debian before they quit giving non-free Mali Midgard drivers out (which didn't really seem to work anyways when you tried the ones Ubuntu provided with the Focal image so I'd only guess the Debian ones wouldn't be that useful either even on the Bullseye image). Maybe someone will get Bullseye running with hardware acceleration in the not too distant future.

If Panfrost picks up support for the Mali T628 MP6, that would be great news and that would save a lot of hassle and troubleshooting work.

@hexdump0815, what do you think about the Odroid SD card kernel partition related method?

[TheNathan0]

@hexdump0815, I got some good and bad news about getting it to run. After several attempts at getting the SD card to have the rootFS of the Odroid Ubuntu image and failing, I just gave up and modified a file and made a third option in the boot picker and had a flash drive handle.

EDIT: Go all the way to the bottom to see exactly where I'm at with this in the bold text.

Yes, it boots up but now I get this underscore on the top left corner just blinking and it will not go away. I wonder if this is a kernel issue now all things considered. This is a very similar (if not, likely the exact same) result I got when trying to use the Odroid repo and some of its files and the Odroid Ubuntu Focal's files in your Xubuntu Focal build.

I speculate that it's a kernel related thing we are looking at here.

I can try Fedora next or an older Ubuntu release for the XU3/XU4 to see if it makes a difference since I figured out how to make it boot into USB flash drives using the SD card to find the root label I set in one of the boot config files. EDIT: Did not manage to get Fedora working

EDIT: I was able to switch to another tty with the CTRL + ALT combination and I do get a CLI with the well known 'odroid' alongside with the tty and its number. Xorg is not playing nicely though (with 20LTS), even though this build was preconfigured with everything needed.

- EDIT AGAIN 7:25PM CT: Much much later today, @hexdump0815 and we have some more progress!

I managed to successfully boot the version 18 LTS version of Ubuntu Mate for the XU4, and I noticed it gives this message about failing on loading kernel modules BUT it boots.

There's that weird underscore issue again but however we get passed it by simply opening a new tty with CTRL + ALT + F-key, then you tell it to launch xorg with startx and viola! It gets to the Mate desktop! but here's the issue. Still no working hardware acceleration!

Also the login manager isn't playing nicely probably because of the failure to load kernel modules or something related to this setup. Looking at the XORG log, it seems like it encounters very little issues when starting up and appears to almost totally work just fine.

You can start the Mate desktop without the login manager in the way with "startx" and at some point Xorg didn't want to launch and gave me an error with loading the Exynos kernel module but I haven't been able to reproduce it really since.

I did some research and that message from start is very very significant and from research, apparently this error with kernel module loading stems from using the wrong kernel.

The kernel here is under 4.x (wiki specifies specifically); the Xorg log also reports that some of the features that it looks for is already built into the kernel so it sees some patches done to the 5.x kernel from the Focal image that I've been using the whole time.

From looking around the internet, it seems more on kernel issue of somekind and that would especially make sense.

What @smcavoy said previously sounds like the most reasonable approach and it seems like a simple solution is to compile the EXACT same Odroid hardkernel and EXACT same version number being utilized on the Odroid Ubuntu Mate build for Peach-Pit straight from the hardkernel source.

This would then ask this question he asked earlier which he brought up earlier, "Of course if there is a list of mainline kernel config options needed for snow/peach this would allow for simply enabling them on the odroid 5.4.x kernel. @hexdump0815 Does such a list exist?"

If we can obtain this information to get the hardkernel over for peach-pit, that would be a great step forward.

If this works, then this confirms that my attempts at the Xubuntu Focal image you built may have been down to a kernel related issue since the Focal image built by you is slightly different than the one Odroid uses when it comes to the kernel from what I see.

What makes this a little interesting is that there are two folders for two different versions of the 4.x kernel within the system, I believe it was for modules? I'm not quite sure why that is but it really isn't a big deal. I'm not aiming for the older 18 LTS build at the moment, I'm aiming to get both the Xubuntu Focal and the Odroid Ubuntu Mate Focal running with GPU acceleration. Getting the Odroid Ubuntu Mate Focal image running even if it's stuck in command-line at the moment is definitely helpful.

[TheNathan0]

I have looked through the kernel configuration file and the Odroid kernel configuration file and noticed a few things that may be important for Mali so I simply changed the few things I needed to change. I was able to figure out on compiling the kernel and I managed to get the dtb files together for the CPU and the 5.4.x Odroid kernel file. The cross-compile ended up being successful which is great news.

Now I need to figure out an initrd image file and I'm clueless on how to do this because I have never done this before. I tried to boot what I had without an initrd file and it got pasted the "starting kernel" screen and went to a black screen. I tried the newer initrd file from the 5.10.x kernel and got the same result.

According to the Odroid Wiki, an initrd file is indeed necessary!

[smcavoy]

@TheNathan0 if you have a working armhf system you should be able to mount the filesystem image (rootfs+boot) and then chroot into the file system and run update-initramfs -k [kernel-version] where kernel version matches the name of the directory of your custom kernel in /lib/modules.

initrd file are specific to the kernel, update-initramfs gathers the kernel modules, specific initramfs init scripts and adds them to a startup archive (then compresses them with gzip). On boot the kernel unpacks the archive, loads modules and starts to then mount the root file system. The OS then begins to start the regular boot process (systemd takes over).

[TheNathan0]

@TheNathan0 if you have a working armhf system you should be able to mount the filesystem image (rootfs+boot) and then chroot into the file system and run update-initramfs -k [kernel-version] where kernel version matches the name of the directory of your custom kernel in /lib/modules.

initrd file are specific to the kernel, update-initramfs gathers the kernel modules, specific initramfs init scripts and adds them to a startup archive (then compresses them with gzip). On boot the kernel unpacks the archive, loads modules and starts to then mount the root file system. The OS then begins to start the regular boot process (systemd takes over).

I only managed to get the 5.10.x kernel by hexdump booting both the Odroid Ubuntu Bionic and Mate images with kernel modules failing to load since both Odroid Ubuntu builds use older kernel versions (Bionic at 4.x and Focal at 5.4.x).

The Odroid Ubuntu Focal build has the modules for 5.4.x obviously and they understandably don't load because of me booting an incompatible kernel.

Is it possible to just boot the Odroid Ubuntu Mate Focal build with the 5.10.x kernel as I did previously and get an initrd image for the custom Odroid 5.4.x kernel using the 5.4.x modules from the Odroid build that way?

I'm very inexperienced with chrooting into a system, I've only done it once for installing Arch on a MacBook.

[TheNathan0]

@smcavoy update: I managed to get an initrd image, it gets to a black screen right after "starting kernel" but I notice that message lasts longer than it does with the 5.10.x kernel. It gets to a black screen and never gets anywhere. I don't really know why it's like that. I know someone reported an issue with an ARM Samsung ChromeBook on Arch apparently it was a kernel related issue. Not sure what I did wrong with my kernel here.

[smcavoy]

what kernel config did you use to compile your custom kernel?

[TheNathan0]

I used the config you provided that goes to the one hexdump has in the GitHub that for peach-pit but I changed a few things in relation Mali and Fbdev. Not much was changed.

In the meantime, I'm going to compile the hardkernel unmodified with hexdump's config file with a newer GCC (his config says 7.5.0).

https://pastebin.com/U1e4MaSR

EDIT: compiling it with that 5.10.x config failed. make: *** [Makefile:1052 drivers] Error 2

[smcavoy]

it would be best to generate an initrd from the modules for that kernel

If you get a working armhf system (armhf being odroid/chromebook snow, x86_64 being a PC) you can copy over your compiled kernel. You need the kernel, .dtb files and modules:

• kernel found in the kernel source dir arch/arm/boot/zImage installed in /boot/[vmlinuz-kernelname]

• .dtbs found in kernel source dir arch/arm/boot/dts/exynos5250-snow.dtb these are usually installed in something like /boot/dtbs/kernel-name/[file]

• modules install the modules on the system you built them on: INSTALL_MOD_PATH=/tmp/chromebook-kernel/ make modules_install the contents of INSTALL_MOD_PATH/lib/modules/kernel-version] would be installed on the working chromebook at /lib/modules/[kernel-version]

after the modules have been installed on the working chromebook you can run update-initramfs -k [kernel-version] to create the initrd file in /boot

you can then update /boot/extlinux.conf and setup a new entry for your new kernel, making sure to specify the correct kernel/dtb/initrd and the append line basically identical to the working kernel

note: I use kernel-name for the same type over kernel, in this case something like chromebook or exynos. kernel-version is specific to the version of the kernel, something like 5.4.167-236

[smcavoy]

I quickly compiled a 5.10.x config (based on hexdump's) against the odroid GitHub kernel

It compiles, not sure that the modules you are looking for are included in the odroid kernel repo but it does compile. Is the expectation that the odroid kernel contains a patched driver for acceleration? I am guessing that would be the lima driver which does compile / included.

[TheNathan0]

Maybe there's something we can't easily see that they did.

I notice the config you linked is my modified one (or looks similar that I can't tell much difference). For some reason trying to compile that forced me to restart configuration of it and it begins asking me a bunch of configuration questions before compiling.

I'm able to compile the Odroid kernel using the config that is provided by Odroid without any issues but I'm unable to use the 5.10.X config by hexdump or my modified for some reason without getting this "restart configuration" thing either. The unmodified 5.10.X config by hexdump just gives me that weird error above (and that is using his GCC toolchain version). I don't really know why it isn't working for me.

[TheNathan0]

Sorry if this bothers anyone or causes any inconveniences but shouldn't /dev/mali0 exist since the Mali drivers are in the kernel? @hexdump0815

I figured out a number of methods to attempt on your Ubuntu Focal build for peach-pit and I noticed after trying on your build that /dev/mali0 does not appear to exist but a fb one does (I tried your xorg arm soc and the gl4es scripts both prior and again after trying).

Browsing online and doing some research, I found that someone was able to confirm after trying to get Midgard acceleration that if /dev/mali0 doesn't exist that it means that the Mali kernel modules aren't loaded at all or that they aren't loading correctly. This individual claims that the Mali userspace drivers will flat out not work if you cannot get /dev/mali0 (which means there is an issue with the kernel drivers in the first place).

I found a useful guide on having an alias type deal for Mali Midgard userspace drivers. It too referenced /dev/mali0 node as well as covered that a chmod command was needed to be done on /dev/mali0

[hexdump0815]

there is always an archive with the mali modules next to my kernel builds like here (that version i did not yet test on the peach): https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/5.15.12-stb-cbp%2B ... you should run update-initramfs to rebuild the initrd (can't be wrong) and maybe mali needs to be modprobed and there is some udev rule required https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_veyron/extra-files/etc/udev/rules.d/50-mali.rules (looks like this is still missing for peach and snow, but it should also work without it as it just takes care of some permissions i think) ... in theory all of this should be in my peach images actually

[TheNathan0]

there is always an archive with the mali modules next to my kernel builds like here (that version i did not yet test on the peach): https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/5.15.12-stb-cbp%2B ... you should run update-initramfs to rebuild the initrd (can't be wrong) and maybe mali needs to be modprobed and there is some udev rule required https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_veyron/extra-files/etc/udev/rules.d/50-mali.rules (looks like this is still missing for peach and snow, but it should also work without it as it just takes care of some permissions i think) ... in theory all of this should be in my peach images actually

Modprobe fails to find mail when you tell it to modprobe "mali"

The latest kernel for Exynos 5420 that you have (which is version 5.15.x) has the lib files. I just copied the kernel modules folder to /lib/modules

Now that I've done that, I was able to run update-initramfs

The problem is that even though it generates MOST of the files for booting, it's missing some that you need that are set by extconf

Why would this be? I can see a mali module in the "extra" folder for the kernel modules in question (from /lib/modules/kernel-version/extra/mali_kbase.ko)

Maybe I didn't run update-initramfs correctly? I'm not sure.

[hexdump0815]

it could be than a "depmod -a" is required to make it awayre of the mali module and the modprobe required would be "modprobe mali_kbase" ... the kernel tar.gz should contain everything required (doing an update-initramfs is always a good idea though)

[TheNathan0]

More desktops are switching to Wayland. If we see XFCE go to Wayland just as MATE did, could we see perhaps the non-free Mali Wayland driver in action?

[jenneron]

It's now possible to use mesa on Mali T628, there are 2 parts needed:

• patched kernel, see 22 and 32-38 patches in https://gitlab.com/postmarketOS/pmaports/-/tree/master/device/testing/linux-postmarketos-exynos5
• patched mesa, see https://wiki.postmarketos.org/wiki/3D_Acceleration#Mali_T628

We ship kernel with needed patches in postmarketOS for peach-pit and peach-pi chromebooks, but users still have to build mesa themselves.

As i understand, @hexdump0815 should not have issues with shipping patched mesa (i can see it's done for other devices) in this project, except putting efforts, of course

[hexdump0815]

hi @jenneron - thanks for the info - i actually have this on my radar already :) ... as xorg seems to still be quite broken with it and the images default to xorg my plan is to enable panfrost support in the kernel and add the allowlist for t62x to my mesa builds but ship the images with an xorg.conf which disables gpu accel - this way functionality is there for whoever wants to use it (maybe with wayland etc.) and the default xorg based images will still work ...

as i'm currently mostly offline for a few more days i'll have a look at it afterwards and it will take quite some time until it ends up in new images after all the changes are in

please keep me up to date in case the xorg problems get resolved somehow, as then i could even enable xorg gpu accel by default

thanks once more and best wishes - hexdump

[TheNathan0]

It's now possible to use mesa on Mali T628, there are 2 parts needed:

• patched kernel, see 22 and 32-38 patches in https://gitlab.com/postmarketOS/pmaports/-/tree/master/device/testing/linux-postmarketos-exynos5

• patched mesa, see https://wiki.postmarketos.org/wiki/3D_Acceleration#Mali_T628

We ship kernel with needed patches in postmarketOS for peach-pit and peach-pi chromebooks, but users still have to build mesa themselves.

As i understand, @hexdump0815 should not have issues with shipping patched mesa (i can see it's done for other devices) in this project, except putting efforts, of course

This is awesome stuff! Thank you! This is definitely good progress.

I can't find much information about compiling for Alpine or Alpine based distros (as pmOS is Alpine based).

Do you happen to know where I can find documentation/info about compiling for such case? I'm interested in trying this out. Thanks!

[jenneron]

Do you happen to know where I can find documentation/info about compiling for such case? I'm interested in trying this out. Thanks!

I will write an instruction

[jenneron]

@TheNathan0 Here you go. For installing: https://wiki.postmarketos.org/wiki/Chrome_OS_devices For building mesa: https://wiki.postmarketos.org/wiki/3D_Acceleration#Mali_T628

If you have questions, better join matrix (e.g. #main:postmarketos.org) and ping me there, see https://wiki.postmarketos.org/wiki/Matrix_and_IRC

[TheNathan0]

@TheNathan0 Here you go.

For installing: https://wiki.postmarketos.org/wiki/Chrome_OS_devices

For building mesa: https://wiki.postmarketos.org/wiki/3D_Acceleration#Mali_T628

If you have questions, better join matrix (e.g. #main:postmarketos.org) and ping me there, see https://wiki.postmarketos.org/wiki/Matrix_and_IRC

Alright! I have a question so I got on it and pinged you there, thanks!

[jenneron]

@hexdump0815 hi, i've finally got access to the hardware.

I've been reported about broken xorg too, but, so far, i see only x2 less performance than in wayland and blinking cursor, but it's typical xorg behaviour as well as tearing

[hexdump0815]

@jenneron - thanks a lot for the update ... please let me know whenever you find out more ... i'll have a look at it when i find some time, if it really works well i'll long term switch peach to panfrost then - now only the mali in snow needs to get panfrost support :) - but i gues this has a rather low chance due to a lot of hardware bugs iirc from irc ...

[TheNathan0]

I did try pmOS on Peach Pit prior at some point; KDE on Wayland worked wonderfully but sometimes it would crash and require an SDDM restart. Xorg is a little more stable on KDE but buggy. I think Gnome on Wayland is more stable than KDE.

Firefox has an issue with WebRender (no hardware acceleration works on Xorg/Wayland. Software acceleration only). Have yet to try Chromium.

Currently, the Panfrost status with T628 is very good at this current stage.

[TheNathan0]

@jenneron - thanks a lot for the update ... please let me know whenever you find out more ... i'll have a look at it when i find some time, if it really works well i'll long term switch peach to panfrost then - now only the mali in snow needs to get panfrost support :) - but i gues this has a rather low chance due to a lot of hardware bugs iirc from irc ...

https://github.com/quarkscript/linux-armv7-xe303c12-only

It's been done already for awhile. I spoke with the maintainer of this repository back before development halted. Seems like it uses the same approach.

Quarkscript has a video showing his build in action for Snow. It seems to work very well.

[jenneron]

@TheNathan0

Firefox has an issue with WebRender (no hardware acceleration works on Xorg/Wayland. Software acceleration only). Have yet to try Chromium.

I'm afraid it needs OpenGL 3 and Mali T720 and lower in panfrost don't use it because of hardware issues which have to be workarounded in mesa and no one wants to work on it

Speaking of chromium, unfortunately, it's not enabled for armv7 in Alpine, but it should be fine in debian

[jenneron]

https://github.com/quarkscript/linux-armv7-xe303c12-only

It's been done already for awhile. I spoke with the maintainer of this repository back before development halted. Seems like it uses the same approach.

Quarkscript has a video showing his build in action for Snow. It seems to work very well.

That's interesting, i will try that\

UPD: I don't see what fixes it.. There is a https://github.com/quarkscript/linux-armv7-xe303c12-only/blob/master/archlinuxarm/some_forked_apps/mesa/fix.patch, but it's already in upstream mesa

[hexdump0815]

i only remember alyssa an robmur01 on irc saying that the old mali on snow has quite a few hardware errata which would need heavy workarounds in the kernel and so far nobody capable had yet interest in looking at that as there are not that many people using this old mali really nowadays, i.e. the effort to result ratio being quite low for them ...

[jenneron]

i only remember alyssa an robmur01 on irc saying that the old mali on snow has quite a few hardware errata which would need heavy workarounds in the kernel and so far nobody capable had yet interest in looking at that as there are not that many people using this old mali really nowadays, i.e. the effort to result ratio being quite low for them ...

If i understand this correctly, it's a similar situation to T628, but most of these errata are on OpenGL ES 3.0, and OpenGL ES 2.0 is mostly unaffected, so we still can have gles 2.0 with much less efforts

[hexdump0815]

@jenneron - oh that sounds interesting, that would be something one could live with :)

[TheNathan0]

Here to update for people who are wondering about browser hardware acceleration on older Mali:

Firefox not working correctly with acceleration might be in part of potential OpenGL related change(s) in the newer version(s) of the browser. Not sure if it's the case.

Tested an officially supported Mali device for that supports OpenGL ES 3.1 (Mali T760) on Panfrost that used work flawlessly with Firefox hardware acceleration (no video encode and decode though?) and it too no longer appears to be working and fails to detect the GPU even.

Chromium acceleration (not including video encode and decode) seems partial and slow (tested on officially supported Panfrost supported device). Disabling Skia renderer doesn't really help either. A lot of the acceleration ends up at reduced performance as indicated when seeing chrome://gpu

Maybe an older Firefox release would be the main way to regain acceleration for a mainstream web browser.

[TheNathan0]

Hi, @jenneron has anything changed with Panfrost and Mali T628 since it was last spoken about? I noticed the information about getting the Mali T628 GPU working has been removed from the pmOS device wiki for Peach-Pit. Status on acceleration for its GPU now no longer reads as only partially working. Does the kernel (for non-pmOS) and MESA still need patching?

Thanks!

[jenneron]

@TheNathan0, I have sent a patch to upstream mesa to enable T620 (which also means T628), so T628 now works with upstream mesa. It still needs kernel hacks, but we already ship them in pmOS, so there are no actions needed from users anymore, therefore no instructions needed. Keep on mind that it will be available only since next mesa release and landing it to Alpine

[TheNathan0]

I figured it was in Mesa, because mesa3d.org now has it in their table of GPUs: https://docs.mesa3d.org/drivers/panfrost.html

I did a bit of reading, apparently the T268 will only work on 4 cores, not 6; not a super big deal.

UPDATE: Found the kernel patches

As for non-Chromium based browsers go, Firefox sounds like a no-go for Midgard v4 due it needing a newer OpenGL ES.

I wouldn't advise building Waterfox Classic since security might be a bit lacking (from what I understand) and maybe even lack of functionality reasons (some webpages apparently don't work well on it?). I'm not sure if it still has the old Firefox rendering method available for use.

I wonder if it's possible to build Firefox for OpenGL ES 2 rather than 3. Might be a lot of work though.

[jenneron]

Yeah, firefox now requires OpenGL ES 3.0. chromium still supports 2.0, but Alpine doesn't package it for armv7 because of segfault. Someone should try to build recent versions

[jenneron]

Speaking of kernel, just use v5.18.5-exynos5 tag of https://gitlab.com/exynos5-mainline/linux and this config https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/testing/linux-postmarketos-exynos5/config-postmarketos-exynos5.armv7

[TheNathan0]

Thank you. This will be really helpful.

I found that Waterfox Classic uses the old rendering method and it's used by default; Webrender can be turned on, but it's optional it seems. The old renderer has WebGL 2 though still, which I think still needs ES 3.0. It does have WebGL 1 though.

[TheNathan0]

Speaking of kernel, just use v5.18.5-exynos5 tag of https://gitlab.com/exynos5-mainline/linux and this config

https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/testing/linux-postmarketos-exynos5/config-postmarketos-exynos5.armv7 arch/arm/boot/dts/exynos5250-smdk5250.dts:10:10: fatal error: dt-bindings/clock/maxim,max77686.h: No such file or directory 10 | #include <dt-bindings/clock/maxim,max77686.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm/boot/dts/exynos5250-arndale.dts:10:10: fatal error: dt-bindings/gpio/gpio.h: No such file or directory 10 | #include <dt-bindings/gpio/gpio.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. compilation terminated. DTC arch/arm/boot/dts/exynos5420-klimt-wifi.dtb In file included from arch/arm/boot/dts/exynos5250-snow-rev5.dts:11: arch/arm/boot/dts/exynos5250-snow-common.dtsi:8:10: fatal error: dt-bindings/gpio/gpio.h: No such file or directory 8 | #include <dt-bindings/gpio/gpio.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. DTC arch/arm/boot/dts/exynos5422-odroidhc1.dtb arch/arm/boot/dts/exynos5250-spring.dts:10:10: fatal error: dt-bindings/clock/samsung,s2mps11.h: No such file or directory 10 | #include <dt-bindings/clock/samsung,s2mps11.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. DTC arch/arm/boot/dts/exynos5422-odroidxu3.dtb make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5250-smdk5250.dtb] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5250-snow-rev5.dtb] Error 1 In file included from arch/arm/boot/dts/exynos5250-snow.dts:9: arch/arm/boot/dts/exynos5250-snow-common.dtsi:8:10: fatal error: dt-bindings/gpio/gpio.h: No such file or directory 8 | #include <dt-bindings/gpio/gpio.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5250-spring.dtb] Error 1 DTC arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb In file included from arch/arm/boot/dts/exynos5260-xyref5260.dts:10: arch/arm/boot/dts/exynos5260.dtsi:9:10: fatal error: dt-bindings/clock/exynos5260-clk.h: No such file or directory 9 | #include <dt-bindings/clock/exynos5260-clk.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5250-snow.dtb] Error 1 In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5410.dtsi:13, from arch/arm/boot/dts/exynos5410-smdk5410.dts:10: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. DTC arch/arm/boot/dts/exynos5800-peach-pi.dtb DTC arch/arm/boot/dts/exynos5422-odroidxu4.dtb make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5260-xyref5260.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5410-smdk5410.dtb] Error 1 In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5410.dtsi:13, from arch/arm/boot/dts/exynos5410-odroidxu.dts:11: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5420.dtsi:13, from arch/arm/boot/dts/exynos5420-galaxy-tab-common.dtsi:11, from arch/arm/boot/dts/exynos5420-klimt-lte.dts:11: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5420.dtsi:13, from arch/arm/boot/dts/exynos5420-smdk5420.dts:10: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5420.dtsi:13, from arch/arm/boot/dts/exynos5420-arndale-octa.dts:10: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5420.dtsi:13, from arch/arm/boot/dts/exynos5420-galaxy-tab-common.dtsi:11, from arch/arm/boot/dts/exynos5420-klimt-wifi.dts:11: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. arch/arm/boot/dts/exynos5420-peach-pit.dts:9:10: fatal error: dt-bindings/input/input.h: No such file or directory 9 | #include <dt-bindings/input/input.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5420-klimt-lte.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5410-odroidxu.dtb] Error 1 In file included from arch/arm/boot/dts/exynos5422-odroidhc1.dts:11: arch/arm/boot/dts/exynos5422-odroid-core.dtsi:10:10: fatal error: dt-bindings/clock/samsung,s2mps11.h: No such file or directory 10 | #include <dt-bindings/clock/samsung,s2mps11.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5420-smdk5420.dtb] Error 1 In file included from arch/arm/boot/dts/exynos54xx.dtsi:14, from arch/arm/boot/dts/exynos5420.dtsi:13, from arch/arm/boot/dts/exynos5420-galaxy-tab-common.dtsi:11, from arch/arm/boot/dts/exynos5420-chagall-wifi.dts:11: arch/arm/boot/dts/exynos5.dtsi:13:10: fatal error: dt-bindings/interrupt-controller/arm-gic.h: No such file or directory 13 | #include <dt-bindings/interrupt-controller/arm-gic.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5420-klimt-wifi.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 1 In file included from arch/arm/boot/dts/exynos5422-odroidxu3.dts:11: arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi:12:10: fatal error: dt-bindings/input/input.h: No such file or directory 12 | #include <dt-bindings/input/input.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5420-peach-pit.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5422-odroidhc1.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5420-chagall-wifi.dtb] Error 1 In file included from arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts:12: arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi:12:10: fatal error: dt-bindings/input/input.h: No such file or directory 12 | #include <dt-bindings/input/input.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5422-odroidxu3.dtb] Error 1 arch/arm/boot/dts/exynos5800-peach-pi.dts:9:10: fatal error: dt-bindings/input/input.h: No such file or directory 9 | #include <dt-bindings/input/input.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. arch/arm/boot/dts/exynos5422-odroidxu4.dts:12:10: fatal error: dt-bindings/sound/samsung-i2s.h: No such file or directory 12 | #include <dt-bindings/sound/samsung-i2s.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5422-odroidxu3-lite.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5800-peach-pi.dtb] Error 1 make[1]: *** [scripts/Makefile.lib:364: arch/arm/boot/dts/exynos5422-odroidxu4.dtb] Error 1 make: *** [Makefile:1373: dtbs] Error 2 make: *** Waiting for unfinished jobs....

This is what I got when trying to compile it.

[jenneron]

@TheNathan0 It's something on your side I suppose

[TheNathan0]

@jenneron What do you think I should try first? I'm not familiar with handling something like this.

[jenneron]

@TheNathan0 Make sure you have installed all build dependencies for kernel

[TheNathan0]

I'm not sure what those dependencies are; I built the kernel used by the Cadmium distro (by Maccraft) recently without issue on that machine. That was for ARM. Is there a list of build dependencies that I'm not aware of?

[jenneron]

@TheNathan0 I don't know. It's not necessary dependencies problem. It can also be corrupted sources. Try https://gitlab.com/exynos5-mainline/linux/-/archive/v5.18.5-exynos5/linux-v5.18.5-exynos5.tar.gz