Posts by Synerworks

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.

The procedures outlined are still correct and valid, however, the daily builds for LE11 as originally documented have already been superseded, so the latest builds for PI3 from "https://test.libreelec.tv/" should be used instead. As mentioned, the approach was never meant to be a definitive supported means for LibreELEC to work on the Pi Zero 2, just a stop-gap measure to facilitate LE7 to LE9 working on the platform until the official release is available. Plus, Christian Hewitt's test LE10 build at "https://chewitt.libreelec.tv/testing/LibreE…m-10.0.2.img.gz" can also be used as a basis for getting LE9 working instead of using the daily LE11 images.

The firmware version I used appears in my original post containing the 'dmesg' output demonstrating its operation. I would assume that subsequent revisions would function correctly, whereas the drop used was tagged "test", access to the firmware from recent nightly LE11 images may be the way to go in event that unacceptable behaviour is observed. I have applied the same changes to LE7, LE8, and LE9 with the similar results. Have not inspected whether LE10 works since an official instance for the Pi3 has not been released due to progress being focused on LE11. The 'correction' has also been evaluated on legacy RaspiOS builds, early Debian for Pi3, OpenWRT, older PiCore just to confirm the expected results.

Has the country code setting been changed when using the "LibreELEC Configuration" tool for your region? Could explain WAP issues if it is operating in its default mode?

Looking at the differences as attached, nothing related to vcsm is altered other than the details for gpio, spi, i2c, uart, sdio, led, wifi, and so on, you name it. As disclosed in the first post, duplication of the Pi3 DTB is sufficient to get the Pi Zero 2 W to boot and operate without WiFi, the firmware fix simply replaces the BCM43430 instance since the DTB does not specifically define the BCM43436 radio as used on the Pi Zero 2. While the alternate approach suggested was by using all the VCOS boot files from the LE11 nightly builds, which now does include the correct DTB and VCOS and fixes for booting, this is the route to take if you are planning on doing more with the Pi Zero 2 other than with a USB lan interface. Either way, the BCM43436 firmware is loaded whether the DTB defines the correct wifi device since "brcmfmac" sees the sister chip as BCM43430 anyhow.

The only thing I can say is procedural coincidence, and unsure why LE9.2.6 is being referenced since officially the last LE9 for the Pi3 was at 9.2.8, on which this fix is for the Pi Zero 2.

Excellent, but surprised that Dtechs "http://libreelec.dtech.hu/3rdParty/S8X2/…-9.2.8.3.img.gz" nor "http://libreelec.dtech.hu/3rdParty/S8X2/…-9.2.8.3.img.gz" images had not initially worked for you. Enjoy.

Quote from Clumpton

Don't know if it's any help, but I have been fiddling around with a Pi Zero 2 W and have had problems with both wifi and Bluetooth which are very reminiscent with those I have had on the Pi4.
I turned off the in-built Bluetooth and then WiFi worked fine. I have added a cheap BT dongle instead which doesn't seem to interfere.

I would also expect that bluetooth issues would also be encountered, the peripheral is also different than on the PI3. No verification has been done in this area since media based access to the Pi Zero 2 W tends to be over WiFi and controlled via keyboard or USB keyboard/mouse dongle of some sort. While the recommended approach would have been to secure another cut of LE9 officially, the kludge was never meant as a measure to provide a 100% solution instead of taking the correct integration approach for the Pi Zero 2. The study was meant as a measure for the bean counters on preserving investments in existing Pi0 solutions by throwing hardware at the problem of performance since $oftware approach could be problematic.

While testing had been conducted using seven different videos, formats, encodings, playback length, unsure if sufficient media has been thrown at it to affirm viability. Nonetheless, the very fact that the Pi Zero 2 caps out at half the Pi2,3 1GB memory and Pi4 even more, it should not be surprising that the limits are reached. As surely as if you installed Windoze on a 1GB laptop and pulled half the memory sticks out of it, its behaviour would be questionable at best. No difference in this scenario. The only other option is correct tuning of the ARM/GPU memory split, or using the much leaner release of LE8 to give a bit more breathing room.

Stability issues for WiFi will certainly be impacted by revisions to the BCM43436 firmware, so it is entirely possible that unacceptable outcomes may arise from sourcing updates that were not already verified. By the very nature that the only the radio firmware is different between the Pi3 and Pi Zero 2, LE9 should operate pretty much the same on either platform unless hitting the constraint limits.