Meson 8* Lives!

Quote from chewitt

You can find a couple of AMLMX test images here: https://chewitt.libreelec.tv/testing/

Code is here: https://github.com/chewitt/LibreELEC.tv/commits/amlogic-mx

Things are super-experimental and you will note from the date/time stamps on those files that I haven't worked up the enthusiasm to rebase anything onto LE12. And since I just started a new job, and accidentally ended up helping to manage the Tvheadend project too, and have a major Triathlon to train for later in the year .. I'm rather time poor these days so I wouldn't hold breath.

AMLMX really needs someone with some of those boxes to take the lead..

The biggest impediment taking on a role of sustaining Amlogic S8xx (AMLMX) releases is being tooled-up with an up-to-date and robust build environment including computing gear and devices to tinker about with for testing, diagnosis, debugging, and generating packages. Getting LibreELEC built and working from a cross-development environment, could take day(s) when generating everything from source. Using alternative approaches, it still took hour(s) by specifically upgrading old target build releases instead. Settled on a more manageable approach to achieve the same results now within minutes. There are several target ARMHF platforms with already generated Armbian releases, which is the quickest to get going.

With the supplied patch archive, integrating Martin's modifications for AMLMX GitHub - xdarklight/linux at meson-mx-integration-6.9-20240323 , it can be used with recent kernels and several LTS ones in order to build LibreELEC and bring Armbian up to scratch by including the latest built DTB corrections for most target platforms.

patch20240915.zip

Even if installing an Armbian minimalistic releases, including XORG and KODI, a similar operating media box environment as LibreELEC is functional. Sure, not a one-stop-shop with a "Just Enough OS" for KODI solution, but still easier to work on. The Armbian development environment can be easily brought up by merging/overlaying the boot and configuration files from the SLAzurin Release Armbian 21.11.0 Linux 5.14-rc2 for AML s8xx Docker enabled · SLAzurin/build-armbian-custom · GitHub build over any recent right at the trunk OneCloud Releases · armbian/os · GitHub, an Amlogic S805 version of Armbian (MESON), or from the archives 'https://dl.armbian.com/onecloud/archive', including a GUI environment, should your box have sufficient memory resources.

After downloading and creating the media images on an SD card, copying the existing boot files from each card into a separate folder for reference, then copying the highlighted missing Amlogic boot files and configuration template to the already created OneCloud SD card boot partition.

Edit the uBoot environment text file "uEnv.txt" settings for your target platform DTB, change the root partition from "ROOTFS" to "armbi_root", since this LABEL has changed from way before. The SD card can now be used to bring up Armbian. Thereafter, the Linux and LibreELEC sources can be retrieved, rebuilt, changed, tested on your target box.

While this should come up on most if not all AMLMX boxes, not all features work since the generated OneCloud Showing results for 'onecloud'. - Armbian Community Forums releases are based on unpatched mainline Linux drivers and older DTS configurations. For the time being, rebuilding and replacing the Linux kernel and initial ramdisk image with the supplied patch file using Martin's fixes gets the job done until the mainline is brought up to speed and this last step will no longer be necessary. With the patched Linux kernel, it can be used as a starting point in integrating Christian's GitHub - chewitt/LibreELEC.tv at amlogic-mx branch for AMLMX.

Seems that Armbian has pulled ARMHF builds for Trixie and Noble from now on 'Remove deprecated fonts from desktop and retire armhf for Trixie and … · armbian/build@6ce5fd9 · GitHub', so only previous legacy images based on Jammy and Bookworm remain available from the 'archive download link – Armbian'. Additional targets continuing to be removed 'https://github.com/armbian/os/com…a0787d8f6dda050'. Progress. Armbian has restored ARMHF builds, 'https://github.com/armbian/build/…30f381f0079ed58', so the details posted previously remain valid. Recently included patches 'https://github.com/armbian/build/…2348cb3397c24f9' are starting to add more of Martin's fixes from the Linux kernel 6.9 branch, so bring-up of LibreELEC-AMLMX is becoming less painful.

Synerworks, thanks, I did try the provided "patch.zip" on plane 6.9-rc6. Kodi is running on 10.88 Libreelec provided by Chewitt and on hexdump0815's bookworm debian image. The main problem is that I get not video acceleration - ok on debian this is expected, but the Libreelec image....

It is offering "drm prime" acceleration, on "direct plane" no picture just distortions, with "EGL" a video with some strange pixel but no video acceleration, cpu load with h264 1920x1080 --> 340%. Do you have video acceleration working ?

BR

Quote from stevie101

Synerworks, thanks, I did try the provided "patch.zip" on plane 6.9-rc6. Kodi is running on 10.88 Libreelec provided by Chewitt and on hexdump0815's bookworm debian image. The main problem is that I get not video acceleration - ok on debian this is expected, but the Libreelec image....

It is offering "drm prime" acceleration, on "direct plane" no picture just distortions, with "EGL" a video with some strange pixel but no video acceleration, cpu load with h264 1920x1080 --> 340%. Do you have video acceleration working ?

BR

The existing issue with the earlier builds did not have acceleration working due to the older unpatched Linux kernel build, the last step still requires that the kernel is rebuilt using the patches supplied to the kernel source and not just including the DTB for LibreELEC to work. Currently doing this in Armbian primarily since debugging builds to KODI are necessary to see what is still broken. Thereafter, applying the fixes to the AMLMX tree, much easier to do when knowing what actually works and what does not.

I guess you misunderstood, 6.9 rc6 is compiled including the patches. This kernel, including a modified initrd, has been applied to a bookworm image. The image is booting fine, GBM is working. From I understand you have done exactly the same with an existing Armbian image.

So the question is what is necessary to get video acceleration ? I am currently trying with mpv and ffmpeg-v4l2request, like

-vo=gpu --gpu-context=drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary

which gives me

[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.
[vo/gpu] No suitable format found on draw plane (tried: GBM_FORMAT_ARGB8888 and GBM_FORMAT_XRGB8888).
[vo/gpu-next] Can't handle VT release - signal already used
[vo/gpu-next/opengl] Failed to set up VT switcher. Terminal switching will be unavailable.
[vo/gpu-next] No suitable format found on draw plane (tried: GBM_FORMAT_ARGB8888 and GBM_FORMAT_XRGB8888).

Therefore my question, do you working video acceleration for h264 ?

chewitt, thanks for the clarification. It is really confusing nowadays with graphic drivers on socs :-). Interestingly ffmpeg-v4lrequest drops the cpu load and makes 1080p videos watchable (around 20fps). Yes, concerning firmware, I did expect a load request for meson_vdec, but there is nothing visible in dmesg.

If anyone is interested, here are the files for chewitt's 10.85/10.88 release booting into kodi. Replace files on fat partition. Working here with tronsmart-s82.dtb. No video acceleration !

chewitt, wow very useful info.

Your first assumptions are all correct.

1. issue missing v4l2 drivers for meson in kernel --> recompiled

2. meson_vdec loaded, but there is no device

meson_vdec: module is from the staging directory, the quality is unknown, you have been warned.
LibreELEC:/dev # v4l2-ctl --all
Cannot open device /dev/video0, exiting.

amlogic-canvas c8006020.video-lut: Endianness is not supported on this SoC --> repeating with "direct plane"

Raining all day here, so I will check the device tree and see if I can do some copy paste, as you suggested.

Thanks again.

chewitt, does not seem to work, but was worth a try:

added to meson8.dtsi:

vdec: video-codec@c8820000 {
compatible = "amlogic,gxbb-vdec", "amlogic,gx-vdec", "amlogic,meson8-vdec";
reg = <0x0 0xc8820000 0x0 0x10000>,
<0x0 0xc110a580 0x0 0xe4>;
reg-names = "dos", "esparser";

interrupts = <GIC_SPI 44 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 32 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "vdec", "esparser";
amlogic,canvas = <&canvas>;
};

dmesg:

[ 4.862672] meson_vdec: module is from the staging directory, the quality is unknown, you have been warned.
[ 4.864183] meson-vdec c8100000.video-codec: can't request region for resource [mem 0xc8100000-0x9091ffff]
[ 4.864209] meson-vdec c8100000.video-codec: probe with driver meson-vdec failed with error -16

This is for somebody with knowledge, I am just fiddling around

BR

One caveat to to using your testing target also as a build platform, getting data from testing while performing rebuilds is a testament in patience. Anyhow, attaching the log files to demonstrate that there is no magic per say, and that the primary objective has been all along to establish some functional parity for LibreELEC-AMLMX against the established development environment using Armbian. Without some baseline, it would be unclear exactly what is broken and what is working and focus attention to areas that warrant it. Eventually all the pieces will be put in place so that Armbian does not need to be used as a crutch for the time being.

dmesg.log

Xorg.0.log

kodi.log

I don't exactly understand the deeper meaning of your post, but I do cross compile and I am not building kernels on the test machine. But the issue is clear v4l2m2m is currently not supported for meson8, maybe Martin will look into that in future.

Quote from stevie101

I don't exactly understand the deeper meaning of your post, but I do cross compile and I am not building kernels on the test machine. But the issue is clear v4l2m2m is currently not supported for meson8, maybe Martin will look into that in future.

Testing LibreELEC.AMLMX 10.88 using your KERNEL and SYSTEM files against the 'channelcheck.mp4' sample video and audio file does not display properly, however the audio track does stutter during playback. Checking the KODI log shows spurious audio errors. The same sample file played back on Armbian is fine and does not exhibit this problem, so some build variance between the two platforms. Need to scan whether the issue lies within the KERNEL or in the KODI builds.

dmesg.log

kodi.log.zip

chewitt Hi, regarding hardware acceleration, with the original Tv Box´´´´ s Android 4.4.2 it works perfectly with the app Airscreen, it plays perfectly at 1080p x265 from UMS on a PC through WIFI 2.4. Maybe this information helps to find a solution.

Using that program I mentioned, it would be interesting if the Chromecast could be ported to the TV Box. I have the first one from 2013 and it still works perfectly with all the streaming apps. Is it possible to do that?

Quote from chewitt

Google provides sources for all the open-source software they use in their Chromecast devices. However, and very intentionally, they provide sources without git history so you cannot easily see what they changed, and they don't provide sources for any of their own-code bits (which remain closed-source). There are also Amlogic kernel sources for older boxes and you can grab the latest AndroidTV or AOSP sources (which are public) so could in-theory create a newer Android release, but mating them into something that boots, runs, and is reliable, will required deep technical skills and several thousand man-hours of effort. Good luck

Thanks for the anwser. 😃

I don't really have any programming knowledge, I was just trying to contribute some ideas to the community. I'm reluctant to throw away an interesting piece of hardware.