Posts by Synerworks

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

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

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.

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.

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.

Quote from Synerworks

Martin has posted a recent AMLMX branch GitHub - xdarklight/linux at meson-mx-integration-6.7-20231221, with several changes, however, the display initialization at boot still fails without the fix to the latest 6.7.0-rcx branch. The compatible targets appear to include AMLGX devices but has left the Meson8x out as specified in their DTS. Perhaps, if you plan to generate a future cut of LibreElec for Amlogic S8xx boxes, check the patch to bring up the display.

Martin's bloodhound work has identified the HDMI initialization issue that impacted previous AMLMX builds, GitHub - xdarklight/linux at meson-mx-integration-6.8-20240310, works once again without resorting to the previous kludge. Therefore, any recent builds for LibreElec AMLMX against this branch should at least come up to the KODI target. Checking into it now that Armbian is operating as previously on the S8xx boxes. Results to follow. Not LibreElec but getting there.

Quote from Synerworks

Since you do not overwrite the contents of the EMMC when booting from the SD card, you will not need to do a backup of the existing dated firmware, as illustrated in your log posting. To launch LibreELEC or Armbian from the SD card, you will need to follow the toothpick method discussed in these forums, once you have any image put on a SD card. You can obtain Christian Hewitt's LibreELEC images using his AMLMX builds, Gabor Dee's excellent legacy LibreELEC build, found in these forums, or grab SLAzurin's build of S8xx Armbian from GitHub, which also has a sample image for download that can be used. Once you have something coming up, I can go at length into getting things up to the latest 2024 releases.

Going through your log, you seemed to be looking for development tools, however, since LibreELEC has just enough OS for KODI, you will not find anything more than a fantastic media box. If you want, you can see Christian's bleeding edge version of LibreELEC, specifically the AMLMX box image. Other than that, if you plan on using it as an engineering platform, the SLAzurin's Armbian build is a good start, just configure it to use the supplied MXIII DTB.

While it is possible to bring up a full GUI desktop environment on your S802 box, your device may not cut the mustard since the current footprint on an existing 2GB box takes some 45%+ of the memory resources just to have a basic terminal session running, therefore sticking with a CLI would still be the way to go, it leaves enough headroom to build your applications including legacy and next generation LibreELEC images, short of adding external storage for swap.

Quote from Thefinaldoom

Thanks to everyone for your replies dtech   Synerworks   chewitt

dtech, from what I read in the link.

This means that I must use the original kernel, or I can try to boot with the upstream images?

I will try with an upstream image, and edit the script as you suggest and if I succeed I will keep you posted.

-------------------------------

From what I understand my TV BOX is quite strange.
CPU is S802-B, wifi doesn't match what I saw (ap6210), 1GB RAM, anyway, it's pretty fluid and that's why I want to rescue it with any other OS (KitkKat 4.4.2 is already obsolete). My intentions are to find an OS as stable as possible, and eventually install it on the system memory.

I have access to it by UART, now I'm trying to copy the original boot loader to a USB.
At the moment I am following these steps.
https://www.synacktiv.com/publications/i-hack-u-boot
I don't have a clear procedure for amlogic, I understand that if I can extract the original content, I could check the original files and from there see what corrections to make to the precompiled images, if anyone can contribute, I would appreciate it.

Display More

You are going over and above what is required to attempting to boot any image at this point. The preliminary step was to get any type of failure on booting any image whatsoever to get to roadmap on what works and what does not. Whether all equipment on the box works at the moment was not important, so it has an AP6210 wifi, the AP6330 version of LibreELEC will support it. Anyhow, if something were to boot up and or burn up on boot, the next step would have been to get the correct DTB to match your box profile. Dtechs builds just have the 'dtb.img' on the SD image as a reference to what the 'kernel.img' build included. The strategy was to rip open the 'kernel.img' with Android Image Kitchen and replace the existing DTB with your Android specific one or simply to modify the existing DTB memory configuration to match yours and repackage it. This process is only valid for his 3.10.x kernels since the DTB structure is compatible.

The effort is not to burden Dtech with every flavour of M8 box out there and cut images specifically to each one. By the way, your box seems to be equivalent to the MyGica ATV582 based on the board images you provided. Once your box begins to work, you may need to modify your remote configuration to match your controller for your box. Use a USB keyboard for the time being to access the box.

Quote from chewitt

dtech I think the idea was to get the box booting any non-Android OS first, and work forwards from there.

Just taking steps to launch any image and then modifying the DTB by patching or replacing it with the existing board file to match the actual system profile, knowing that the 2GB memory configuration in the latest builds will most likely cause it to fail to boot.

Quote from Thefinaldoom

I tried the 2 images and there is no way to get it to boot. I have no button behind the audio connector. I do have an update button under the board. When I press and hold it and connect the power cable it leaves me in Android Recovery, but it doesn't go beyond that. I think I have to change the boot.img to allow me to load any other image from the MicroSD.

I don't know what I'm doing wrong.

Pressing the button on the board instead of pushing the toothpick through the audio port is the same thing. The SD card with the image that you want to boot should already be inserted in the slot, with the power cord disconnected, press and hold the button, plug the power in, the boot logo should flicker once and then you should immediately release the button and let the boot proceed. Holding it too long will force the Android recovery mode to come up instead of launching the image from the SD card. The u-boot date code is not antiquated to the point where image loads from the SD card are not available, as far as I am concerned.

Quote from Thefinaldoom

Thank you very much for your reply.
From what I understand, the toothpick method is to boot the TV BOX in "Android Recovery" mode, is that correct?
I can do that, but I can't find a way to create a MICRO SD which will boot.
Which model is more compatible with that CPU.
The backup is in case I need to copy some firmware from the device to add it to an image.

Start with the details posted on Dtech's site, GitHub - dtechsrv/LibreELEC-AML: 'Just enough OS' for Kodi for some Amlogic TV boxes.

The platform that matches the closest to your box would be found at Index of /images/3rdParty/ (dtech.hu), the image name specifically https://libreelec.dtech.hu/images/3rdPart…9.2.8.12.img.gz or https://libreelec.dtech.hu/images/3rdPart…9.2.8.12.img.gz but modifying the DTB to limit the actual memory to 1GB instead of 2GB. Another option would be to pull the actual DTB from your Android box using 'Android Image Kitchen' application to extract and use as the 'dtb.img' when booting either of these images.

Quote from Thefinaldoom

Hi, I am trying to boot any ROM or linux image on this TV BOX. I can't get it to take the MicroSD. The CPU is an Amlogic S802-B.
I understand it is 32bits.

RME0924V116800001G(S802-B EMMC)
GENIATECH RM0924 VER1.16
2015-07-01

UBUT: 20150701
SYSTEM: 20151103
161110-03721

I have access to the UART and this is what I got from the output of the ttyUSB0.

Any hints?
How do I bakup this system?

Display More

Since you do not overwrite the contents of the EMMC when booting from the SD card, you will not need to do a backup of the existing dated firmware, as illustrated in your log posting. To launch LibreELEC or Armbian from the SD card, you will need to follow the toothpick method discussed in these forums, once you have any image put on a SD card. You can obtain Christian Hewitt's LibreELEC images using his AMLMX builds, Gabor Dee's excellent legacy LibreELEC build, found in these forums, or grab SLAzurin's build of S8xx Armbian from GitHub, which also has a sample image for download that can be used. Once you have something coming up, I can go at length into getting things up to the latest 2024 releases.

Quote from chewitt

Martin pushed an updated kernel branch: https://github.com/xdarklight/lin…n-6.7-20231203/ - I'm not seeing anything obviously new in terms of commits, but it's an excuse to do a rebase for AMLGX sometime soon.

Martin has posted a recent AMLMX branch GitHub - xdarklight/linux at meson-mx-integration-6.7-20231221, with several changes, however, the display initialization at boot still fails without the fix to the latest 6.7.0-rcx branch. The compatible targets appear to include AMLGX devices but has left the Meson8x out as specified in their DTS. Perhaps, if you plan to generate a future cut of LibreElec for Amlogic S8xx boxes, check the patch to bring up the display.

fixes.patch.txt

Quote from chewitt

Martin pushed an updated kernel branch: https://github.com/xdarklight/lin…n-6.7-20231203/ - I'm not seeing anything obviously new in terms of commits, but it's an excuse to do a rebase for AMLGX sometime soon.

Have been actively back and forward porting Martin's work for some time now to keep Armbian working on the S8x2 (Matricom) boxes to facilitate native 'armhf' builds of tools and applications instead of using cross-compilations on a slow ASUS x64 tablet. As a note, some fixes may need to be considered since the recent change that used to work in initialization due to the the 'composite-connector' quirk being present in the DTB within the "meson_drm" module has changed and left out the references to some S8x2 boards for the HDMI initialization. While Martin had been notified about it, not sure if you will work with this specified drop or whatever comes next. Your January 11 build of the AMLMX package had generated lima errors thus failing to start KODI, as a number of forum members had also reported.

Some tidbits for reference.

dmesg.jan11.txt

s8x2.logs.txt

s8x2.patch.txt

The 'dtb.img' used to be in the legacy releases as a means of illustrating on which architecture the kernel was booting, the DTB is appended to the kernel image when built. With Android Image Kitchen you can break the kernel components apart and see that the second image is in fact the actual DTB identical to the one in the file list as built for that box. Have had success in substituting the DTB in the kernel image using AIK to get the device booting and working with common core components, mind you the add-ons specific to the unique box did not always work unless they were already built into a compatible kernel and the modules were present in the SYSTEM blob. If the kernel was already built to support the specific hardware, adding the kernel modules to the SYSTEM blob (squashfs) and updating the kernel with the 'dtb.img' for your box or fixing it by using DTC to decompile and then recompiling these changes, LibreELEC would work for that target.

While it is certainly easier to build from source, however, when those sources were not clearly known based on the patches and revisions being added adhoc to the amlogic baseline sources, liken it to when you operate a junk yard as a mechanic, you make do with what parts you have when putting things together to make it work.

Kudos to dtech for keeping the legacy LibreELEC alive and kicking on the boxes that still have plenty of life and the capabilities for media applications without the bloat rendering them EOL.

So far operations have been stable, does not seem like much has changed from the previous "test" release other than some subtle fixes ...

Simply replaced the already substituted firmware from the previously fixed "SYSTEM" file and using it on all the patched LE9 images ...

Will also check on previous LE7, LE8, and LE10 releases, but I do not anticipate any variances from the last round of testing.

For those that are looking for the latest firmware for the Pi Zero2 or have encountered the documented issue:

Updated 43436P firmware for Zero 2 W · RPi-Distro/firmware-nonfree@fdaf74c

The shipping firmware for the SYN43436P does not support 4-way handshake offloading. This new firmware (version string "Version: 9.88.4.77 CRC: 143f9f15…

github.com

the image can be obtained from:

firmware-nonfree/brcmfmac43436-sdio.bin at fdaf74c780ca7a29b12d62e5b0d37c38c2321e20 · RPi-Distro/firmware-nonfree

Contribute to RPi-Distro/firmware-nonfree development by creating an account on GitHub.

github.com

Unsure yet if other issues crop up, will investigate and report findings.

Quote from HiassofT

Would be great if you could give that a try, I don't have any RTCs for RPi4 here.

Currently using the DS3231, your build addresses the problem, clipped from 'dmesg':

[ 5.774298] rtc-ds1307 1-0068: registered as rtc0

[ 5.774481] rtc-ds1307 1-0068: setting system clock to 2022-03-27T20:33:32 UTC (1648413212)

Yesterdays build only showed that the device was registered.