dreamlayers

What does that mean? Panfrost is the GPU driver, for the Mali-T820 GPU. I have hardware acceleration for 3D graphics and video playback, in Armbian.

I have an x92 box with Amlogic Meson GXM (S912). The SOC has a Mali-T820 GPU, and the box has 2 GB of RAM and 16 GB of eMMC. I'm running Armbian 25.11.2 noble on it. While using the Wayfire Wayland GUI, there is a lot of kernel output like this, constantly repeating: panfrost d00c0000.gpu: shader power transition timeout panfrost d00c0000.gpu: tiler power transition timeout panfrost d00c0000.gpu: l2 power transition timeout The GUI works, and hardware 3D acceleration works. But it would be nice to get this spam out of the logs, and I also wonder if there is really some problem. Like, maybe the kernel doesn't know how to change GPU voltages. Maybe it is related to this at boot, maybe due to an issue with the device tree. kernel: panfrost d00c0000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found The only other sign of something being possibly wrong is that SOC temperature goes surprisingly high when playing hardware accelerated video. That ought to be energy efficient. I'm running Mopidy and Firefox at 53°C and just playing a video can get it to 70°C. It is possible to make these errors go away via: echo on | sudo tee /sys/bus/platform/devices/d00c0000.gpu/power/control I don't know if changing that from auto to on will increase power consumption. Alternatively I tried to add a dummy regulator to the device tree and set mali-supply of the GPU to that regulator. Adding the dummy regulator only removes this single error at boot time: panfrost d00c0000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found The power domain picture of the S912 datasheet shows a VDD_EE (Everything Else) input to the chip from an external PMIC, and then 3 components in the GPU, each with individual switches to VDD_EE. The 3 components are: GP0+L2C_0, PP0+L2C_1 and PP1. I suppose they correspond to the 3 types of power timeout errors, though I'm not sure which is which. This seems to show that there is no possibility for voltage scaling for individual GPU parts or even the whole GPU, without actually changing VDD_EE and everything else it powers. So, probably all the GPU driver needs to know is how to flip those three switches.

I installed Waydroid on an Amlogic Meson GXM (S912) TV box. The SOC has a Mali-T820 GPU, and the box has 2 GB of RAM and 16 GB of eMMC. This was easy to do and Waydroid worked, but it was very slow, even before it heated the SOC to 80°C, which is probably its throttling limit. I removed Waydroid because it was too slow. I wasn't trying anything demanding. Even navigating Android Settings was ridiculously slow. This is a bit surprising because the hardware was designed for running Android. I was not running much else, just Wayfire and one or two Alacritty consoles. I don't think I was running out of memory. Is it possible to get decent Waydroid performance on other arm64 hardware?

Is any PPA or other repository with ffmpeg libraries built with v4l2 hardware decoding enabled? I mean something like how Raspbian installs its own libraries with --enable-v4l2-request --enable-vout-drm instead of the Debian ones without that. On Amlogic S905X and S912 I first had to build a kernel with dma-buf heaps enabled to make Kodi DRM PRIME work. Then I used some libraries from LibreELEC with Armbian Kodi to enable hardware decoding. More details are at: https://forum.armbian.com/topic/34880-hardware-video-decoding-on-s905x/#findComment-209271 Now the proper fix is rebuilding FFmpeg. Maybe only --enable-v4l2_m2m needs to be added.

Thank you. Since then I have found https://github.com/7Ji/ampart, which can show the Amlogic and DTB partition table information, tell you which parts can be written to, and even rearrange some partitions so you can use more space.

https://github.com/7Ji/ampart/ can tell you what parts of the eMMC can be used. It can also be used to rearrange Amlogic eMMC partitions so that more space is usable. Note that these partitions are separate from the ordinary partitions you see with generic partitioning tools like GParted. You won't see them at all in those tools, and those tools will overwrite them if you're not careful to avoid them.

Later I installed an Ubuntu Noble 24.04 image. There, hardware decoding definitely works in mpv, via v4l2m2m-copy. There is a huge decrease in CPU usage. Though, frames are still dropped even though there is plenty of CPU time. That decoder can also be used from ffplay, also with dropped frames. This problem exists at the console, in Wayland and in X. I figured out why Kodi DRM PRIME wasn't working. PRIME uses the dma-buf subsystem of the kernel, and that was turned off in the kernel configuration file. After enabling CONFIG_UDMABUF=y CONFIG_DMABUF_HEAPS=y CONFIG_DMABUF_HEAPS_SYSTEM=y CONFIG_DMABUF_HEAPS_CMA=y and recompiling the kernel, I could use DRM PRIME, both on the S905X ABOX-A1 and on a S912 based X92. The S912 had corruption in the video when rendering to EGL, so there DRM PRIME was only usable outside of Wayland, using Direct to Plane. There was no such problem on the S905X. (As mentioned earlier, hardware decoding also needs vdec firmware: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/meson/vdec ) Even after all this, Kodi still uses software decoding for some reason. Pressing o during playback, I see that it is indeed using PRIME, but software decoding. I don't know why. Generally, this is a nightmare to troubleshoot, because there is often a lack of clear log or error messages that describe the problem. Edit: I downloaded LibreELEC-AMLGX.aarch64-12.0.1-box.img.gz. In the root directory of the FAT32 boot partition of the image is the SYSTEM file, a squashfs of the whole LibreELEC system. (There is nothing in the second partition.) I used unsquashfs to extract the SYSTEM file, and then mount --bind to make /dev, /proc, /sys and a directory with media files accessible inside the extracted squashfs-root. I could then run squashfs-root/usr/lib/kodi/kodi.bin in a chroot, and get hardware acceleration. Though USB input devices need to be replugged to be usable, and there is no way to exit that Kodi, so this is not ideal. Then I copied libavcodec, libavdevice, libavfilter, libavformat, libavutil and libswresample from squashfs-root/usr/lib/ into new directory ffm and started Armbian Kodi via LD_LIBRARY_PATH=ffm kodi. This gave me hardware acceleration in Armbian Kodi. So, it seems that some issue with FFmpeg libraries prevents hardware acceleration in Armbian Kodi. This solution is fine for now, giving smooth hardware accelerated playback with minimal CPU usage.

Why is so much of the eMMC unused at the start? In the old script, the first partition starts at 700M (M = million bytes), and in Armbian 23.11.1, that has been increased to 1000M. These are the parted commands: parted -s "${DEV_EMMC}" mklabel msdos parted -s "${DEV_EMMC}" mkpart primary fat32 1000M 1512M parted -s "${DEV_EMMC}" mkpart primary ext4 1513M 100% BTW The Armbian 23.11.1 version also contains the umount /var/log.hdd fix from the post above.

I connected the ABOX to an 24LC21 I2C EEPROM programmed with the Protron PLTV-26 EDID, also connecting the hot plug detect line to the +5V line. Then I monitored I2C communication using a logic analyser. Here is the I2C activity I observed: Quickly after startup, there is a sequential read of 8 bytes from memory address 0xF8 on I2C address 0x52. That is what https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle is talking about. It is safe. This won't corrupt EDID. (Note that some EEPROMS like the 24LC21 do not care about the lowest order 3 bits of the address and the pins that select the address, and respond to I2C addresses 0x50 through 0x57. Also note that the contents of the EEPROM wrap around, so even a 128 byte EEPROM can be used. A read to memory address 0xF8 on the 24LC21 ends up reading address (0xF8 & 0x7F) == 0x78. So you can put the boot string at address 0x78 through 0x7F on a 128 bit EEPROM.) Then, just under a second later, accesses to I2C address 0x54 start: Two reads from EEPROM address 1. Write 1 to EEPROM address 2. Write 0 to EEPROM address 0x20. Those writes do the corruption. Then 1.5 seconds later the EDID is finally read, using a sequence of individual byte reads from I2C address 0x50. It has already been corrupted by this point, by the two earlier writes. I think this is the firmware reading it, for the initial video mode. About 12 seconds later there are more EDID reads. I think that's the Linux kernel doing it. HDMI 2.0 puts the Status and Control Data Channel (SCDC) at I2C address 0x54. There, at address 2 you have "source version" and at address 0x20 you have "TMDS config". So, the firmware is attempting to write to those things. It is only allowed to access the SCDC if the EDID contains the HF-VSDB structure and the "SCDC present" bit there is set. But it is accessing SCDC without first checking the EDID. Another device, the EZCOO EZ-SW21HA21 HDMI audio extractor switch. also inappropriately accesses this SCDC. Edit: I don't know where is the source for the exact U-Boot found in this box, but https://github.com/endlessm/u-boot-s905x/blob/9149dd46279da8c347f36b7ca3164f660cfd6581/arch/arm/cpu/armv8/gxb/hdmitx20/hdmitx_set.c#L300 shows code which causes this EDID corruption. There, scdc_wr_sink() writes to I2C address 0x54, and in scdc_prepare() it is used to do the two writes that corrupt my EDID.

Where can I find armbian-ddbr? I do have /usr/sbin/ddbr however, and maybe that should be used instead?

I have an OTT TV Box, model ABOX-A1 ( 1G + 8G, S905X ). It is running Armbian 23.11.1 bookworm. How can I have hardware video decoding? Hardware video decoding support seems present in the 6.1.63-current-meson64 kernel. It seems only the V4L2 M2M API is present. Some firmware seems missing. I was getting "meson-vdec c8820000.video-codec: Direct firmware load for meson/vdec/gxl_h264.bin failed with error -2" in dmesg. I don't know what package I need to install. I was thinking maybe firmware-linux-nonfree, but that conflicts with armbian-firmware due to firmware-ralink. The files are available at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/meson/vdec though, and I downloaded gxl_*.bin from there and put them in /lib/firmware/meson/vdec/ . I've tried Kodi, mpv and ffmpeg, in Wayfire and at the text console. Kodi always uses lots of CPU, and mpv crashes whenever I use --hwdec=v4l2m2m-copy. The best result was "ffplay -vcodec h264_v4l2m2m file.mp4" at the console. That at least actually seems to use hardware decoding because I see this output: driver 'meson-vdec' on card 'Amlogic Video Decoder' in mplane mode. But the CPU utilization is actually worse, about 300%, compared to below 200% without -vcodec h264_v4l2m2m. Edit: After installing mpv 0.37.0-1 and its dependencies from trixie (Debian testing), I definitely got hardware acceleration in mpv --hwdec=v4l2m2m-copy. CPU usage was less that 100% on one core. However, there were still problems with dropped frames and audio/video desynchronization, so I don't recommend this. Kodi CPU usage seems decreased too, often below 200% playing the same file, but this is still terrible for playing 720p H.264. It's not worth messing up your packages with a mix from two Debian versions only to get this. Edit: The Kodi 2:20.1+dfsg-1 from Bookworm doesn't have the DRM PRIME options in "Settings > Player > Videos", so I guess it doesn't support acceleration? The Kodi 2:20.4+dfsg-1 from Trixie does have those options, and enabling them makes the video disappear. I've tried setting "PRIME Render Method" to EGL and Direct-To-Plane, and both failed in a similar way.

If you have an image of what was on eMMC before, I think you should be able to boot Linux from SD or USB and then write that image to eMMC from there.

I've attached it again here. s905x-p212_audio_fix.tar.xz

I used a different file name for the fixed dtb: meson-gxl-s905x-p212-sound.dtb. Because of that I don't think it should be overwritten when the kernel is updated. I don't expect updates to remove the entire directory, but even then, surely there is some space on the boot partition where I can put my custom dtb so it doesn't get deleted.

I am using Armbian_23.11.1_Aml-s9xx-box_bookworm_current_6.1.63_minimal.img.xz