Posts by Synerworks

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.

Rest assured that the DTB posted was not a mistake, but intended on getting the box to come up at least, no matter what build was tried. After all, a box that does not boot is a box that is certainly hard to fix. I am aware that the S802 and S812 are fundamentally the same with provision for H.265, plus the clone jobber OTT TV box comes in a number of flavours M8, M8N, M8S, you name it. However, at least the Matricom gear with the G-Box series, Q, Q2, Q3 and the likes does not suffer from "internet memory" and access to their firmware is a no-brainer. Without having access to the digital "schematic" DTB from the stock firmware for the OTT TV box, there is no certainty as to what peripherals hang of the SoC, configuration, addressing, whatever, so it is the best guess on the closest box based on vague descriptions. If I had ready access to the actual OTT TV stock firmware, I would have gone with that, plain and simple.

Yes, most, if not all boxes, use the multiple-DTB setups so that a single cut can operate on many platforms put together by manufactures, easier for them to sell one blob than dozens, LibreELEC is built to a specific target without adding the bulk of every driver known and configurations for each of them. There was never any expectation that the Ethernet worked, might be lucky, great, remote works, lights blink, WiFi blazing fast, hyper resolution screen capable, just that the next steps were to troubleshoot the pieces in that black box. Sure the Dtech builds have the correct remote configurations, whereas the Demetris releases the correct "remote.conf" is put on the SD card on boot and it is business as usual. Troubleshooting and preparation can be done with a keyboard, not a remote.

Now that the box comes up and you can use a KEYBOARD, getting the detailed "dmesg" results would go a long way on isolating the Ethernet hangups.

Quote from tico

The back of the box says - OTT TV BOX - Android Player- Model M8N - Made in China -and when it comes on displays M8. I tries the Oleg Ivanov and I get libreelec logo and then reboot over and over again I also tried Demetri "LibreELEC-S802.M8.arm-8.0.RC4.img" with no success. Tanks

I have not located a source for the stock Android firmware for your OTT box, but the specs for it appear identical to the Matricom G-BOX Q, https://matricom.net/product/g-box-q/, that I had worked with, so I have attached a copy of the DTB as pulled using Android Image Kitchen that you can try on either the Demetris or Dtech "kernel.img" images.

kernel.img-second.zip

Any success with the older cuts of the Demetris builds, as referenced previously, say the early LE8? Worked with Matricom S802 boxes before, so I would expect quite a bit of success. How about a picture of the back of your box to know the exact model so that if the Android firmware is available, it can be extracted and inspected?

How about any of the antique builds by Oleg Ivanov, at https://disk.yandex.com/d/CxRZ4LFOuHcJW/Libreelec, the S812 images still boot with the various flavours of ethernet hardware on S802 platforms.

So far it appears that both the Demetris and Dtech releases exhibit the same behaviour with the Ethernet interface. The primary motivation on testing any build with at least a working lan was that the DTB could have been sourced from it and then added to the Dtech build had anything been found. The worst case would be for the DTB being pulled from the Android image for the exact box known to work and checking the variances in configuration when decompiled. What I see so far is that the lan interface comes up, but fails to get a DHCP address, pointing to a configurational issue or caused by one of the existing compatible lan drivers being loaded not specifically geared for the exact hardware on the box and not functioning.

Good, so the matter for attention would be to identify what the dependency is on the specific ethernet hardware and not relating to the build release itself. While the "SYSTEM" rename will allow you to drop to a shell and see the "dmesg" information, the kernel-overlays are embedded within the SYSTEM containing all the relevant supporting hardware drivers. These are loaded dynamically once the SYSTEM is mounted, after which the "dmesg" dump would give the much needed details. The output from "dmesg" can be written to the SD card by remounting the /flash partition as read-write instead of read-only from the command line and copying to /flash already containing the kernel and SYSTEM files. When you reboot and take the SD card out, you can take the file from the card and submit it.

You can also look at what LibreELEC is doing on startup by inspecting the "/init" script file, and performing the respective commands iteratively when trying to identify what the problems may be on startup. When the specific hardware component is found, the driver object can be manually added to the squashfs "SYSTEM" file or added to the build criteria when generating from source.

Quote from dtech

tico  Synerworks

The only problem is that the two dtb files are completely identical (md5sum: b2f8802cdd0cf49256791ac128be79f2), not just the source code, but the binary as well. So this whole operation is a waste of time. The problem will be somewhere else because I ran into this error earlier:

Post

RE: Legacy v9.2 (LTS) builds for Amlogic S805/S8X2, S905/S912 and all WeTek boxes

[…]

I tested the above alternative today

Failed

The error is as follows

rm：cant't remove ‘storage/.please_resize_me':read-only file system

PARTITION RESIZIMG IN PROGRESS

please do not reboot or turn off your libreelec device

yibaogang

June 18, 2021 at 4:02 AM

MIKMXIII

Unfortunately, the wireless connection in these boxes is a joke, because it is not enough for HD content, and live streams (e.g. IPTV) will be constantly sequence faulty due to fluctuating latency. I recommend Ethernet by default.

The intended purpose for identification of problems was to establish at least a known baseline prior to guessing as to what the issues are was by using initially the Demetris build since it was disclosed as to be working. I am aware that the DTB potentially matched, however, had it not, it was a trivial to fix. I know that your release follows his and built upon the same framework with important corrections, therefore saving you precious cycles on chasing an issue that may have been inherent originally in the Demetris build. I already use a "SYSTEM" mod to get the dmesg information in cases where the UART log cannot be obtained from the box for troubleshooting. Chiming in was to help not to add to your burden.

Quote from powiedzmi

Hello,

Got LE 9.2 working on Pi Zero 2 using the method provided by @Synerworks but Kodi crashes every time I try to play a video.

I got the following in dmesg:

Code

vchiq: 0: ignoring ERROR from callback to service 5004

in kodi crash log:

Code

mmal: mmal_component_create_core: could not find component 'vc.ril.video_decode'

in journalctl:

Code

Dec 19 12:28:25 LibreELEC kodi.sh[307]: usrvcsm: [vcsm_malloc_cache]: [315] [mmal_vc_port buffer]: NULL size or invalid device!
Dec 19 12:28:25 LibreELEC kodi.sh[307]: usrvcsm: [vcsm_vc_hdl_from_hdl]: [315]: invalid device or handle!
Dec 19 12:28:25 LibreELEC kodi.sh[307]: usrvcsm: [vcsm_lock]: [315]: invalid device or invalid handle!
Dec 19 12:28:25 LibreELEC kodi.sh[307]: mmal: mmal_vc_shm_alloc: could not allocate 1048576 bytes of shared memory (handle 0)
Dec 19 12:28:25 LibreELEC kodi.sh[307]: mmal: mmal_vc_port_payload_alloc: vc.ril.video_decode:in:0(H264): failed to allocate 1048576 bytes of shared memory
Dec 19 12:28:25 LibreELEC kodi.sh[307]: mmal: mmal_pool_initialise_buffer_headers: failed to allocate payload 0/2
Dec 19 12:28:25 LibreELEC kodi.sh[307]: usrvcsm: [vcsm_malloc_cache]: [315] [CGPUMEM]: NULL size or invalid device!

I also noticed /dev/vcsm is missing. I guess this is why video playback fails but have no idea how to make /dev/vcsm available.

Display More

The classic problem of not having enough shared memory, especially for the Videocore portion. With the Pi Zero 2 capped at 512M, not all usable however, finding the right memory split between the ARM and GPU for things to work would be through trial and error. The alternative would be to drop back to LE8 since it is certainly leaner than LE9 on resource usage, but dated though. Take a look at the KODI forum at: https://forum.kodi.tv/showthread.php?tid=327150

There is a good reason for LibreELEC in leaving the earlier Pis behind, without enough memory, you hit the ceiling and things just no longer work as expected. Just because it can, it does not mean that it is as good.

Once you use the LibreELEC imager tool to create your SD cards with the Demetris releases, you will find the "kernel.img" on the SD card. This is the file to use with AIK to unpack it. There will be a "split_img" folder created with the DTB file being saved as "kernel.img-second". Copy this file somewhere else, fetch the LE9 version of the Demetris build, also create the SD card and redo the previous process with AIK to unpack the new "kernel.img". The saved copy of this previously verified to be working DTB can be copied back into the "split_img" folder in order to change the DTB that it was originally built for. Then repack the "kernel.img" with AIK. Copy the "kernel.img" file back onto the latest SD card so that the modified image can boot in your box.

If you have no trouble with the Demetris builds, then you can do the same for the Dtech builds since they are also based on the legacy Amlogic Linux 3.10.108 kernels.

Just out of curiosity, does: LibreELEC-S8X2.arm-8.2.3-M8.img.gz from his repository at https://androidfilehost.com/?w=files&flid=170774? If so, you may want to take a stab at his last drop at https://androidfilehost.com/?w=files&flid=305958 but use Android Image Kitchen to unpack the "kernel.img" file and substitute the DTB file from the working package with any equivalent image for the S8X2 target and then repack it.

Copy it back onto the SD card and use the toothpick method to start it up. Plus, if you rename the "SYSTEM" file to something else, you will be dropped to a command shell and then you can use "dmesg" to see what happens on boot. While each platform is built for specific architectures and their drivers, most share much of the same components that can enable you to do some of the forensic legwork. When the box comes up, the "LibreELEC Configuration" tool will show the actual platform that it was built for, so you will need to use the ".nocompat" fix incorporating subsequent DTB changes by using Android Image Kitchen to update the "kernel.img" file on the LE9 images containing the drivers for the hardware you are using.

Quote from dherrman

Hello,

really impressiv all the knowledge around in this forum.

Sadly it won't work for me, followed the instructions from Morphy but failed to get Wifi working

Checked with PI light OS, Wifi works, so ensured no issue of the chip.

Is there a way to geht the tweaked Installation for the SD card to run it with the pi zero 2w?

After 8 hours try and error i give up, but kearned mich about Linux commands, even to enable terminal in libreelc

Kind regards

Detlef

Display More

Since wifi works with the RaspiOS, then I suspect that some procedural error may be at fault. While I have supplied the screenshots to show the "actual" work for reference, I expect that some of the files, as documented, for you to obtain for conducting the steps may have been removed or changed. Unfortunately, the test LE11 packages, legacy debian add-on packages, may only stick around for a short period of time and is superseded by more recent builds, but I expect that for the needed VCOS components it should still be valid nonetheless in future daily builds.

This would be another great reason to go with the squashfs "SYSTEM" approach, after it is done once, you can forget about ever having to do it again should your LibreELEC SD cards go bad.

Quote from Morphy

Thanks for that info, I'll consider it if things don't go well with LE9. So far it's running nicely with only 30% memory usage. (100mb/339mb)

Thanks for the explanation! That is indeed another way to get the job done. I was going to suggest fetching the files from the RPi Github but I had an already flashed SD with buster on it so I just used that. Your new method would require a Keyboard being attached as well which not everyone has.

I've just created a base image of the RPi0-2 LE9 with the correct drivers and then I can just replicate that as needed.

Knowing that the path forward on LE9 and earlier has come to an end, you may want to keep the changes persistent as you require. Re-doing the steps every time the cards are trashed, getting media built and setup for others, that are less tech savvy, is just a lot of work not needed every time. The patch to the squashfs "SYSTEM" file is much more easily manageable, without any further mistakes to cause unnecessary grief from manual typos. While it is fairly trivial when you work in a full development environment, with all the resources necessary to do the job, the corrections can be completed in just a few steps.

I will simply have to assume that most people will not have much to work with other than their Pi Zero 2, or any other RPi model for that matter, so the steps needed to take over and above what has been discussed can be reused pretty much to re-cut the "SYSTEM" file.

Any RPi with the "lite" version of RaspiOS can be used to temporarily make these changes. In addition, two components also need to be pre-fetched to add support to RaspiOS in order to work with squashfs, unless it has already been installed, plus, it does not need to be live on the network for any package updates nor additions, unless you want to.

- As usual, RaspiOS can be obtained from: https://www.raspberrypi.com/software/operating-systems/ and should be installed as documented.
- I, in this example, used: https://downloads.raspberrypi.org/raspios_lite_a…-armhf-lite.zip, but the desktop versions will work too, your choice.

Use the imager tool to create the downloaded RaspiOS SD card. The compression library and squashfs-tools debian packages should also be downloaded and put on the RaspiOS SD card as well after it has been built but before booting so that it will be ready for use.

- These packages can be obtained from the debian FTP repo and should be saved directly onto the newly created RaspiOS SD card:

https://ftp.us.debian.org/debian/pool/main/l/lzo2/liblzo2-2_2.10-2_armhf.deb

https://ftp.us.debian.org/debian/pool/main/s/squashfs-tools/squashfs-tools_4.4-2+deb11u1_armhf.deb

Also copy from your LE9 SD card the two previously obtained BCM43436 firmware files renamed to "*43430*" and the "SYSTEM" file that you want modified onto the RaspiOS SD card. With all the pieces in place, boot it and login.

Just a note, all further volatile operations should be done as "root".

- Use the debian package manager to install the LZO compression library and squashfs-tools directly off the RaspiOS SD card.

- Create a temporary folder to mount the squashfs "SYSTEM" file and mount it to extract the contents from it.

- Copy all the read-only squashfs files from the temporary mount onto the storage volume of the RaspiOS SD card.

- The squashFS "SYSTEM" file can then be unmounted and the wireless firmware files copied over.

- Delete the original copy of the "SYSTEM" file from the RaspiOS SD card and then rebuild the squashfs "SYSTEM" file back onto the RaspiOS SD card by using the installed "mksquashfs" command.

Lastly, run "sync" to make sure the RaspiOS SD card is fully written and then reboot. Remove the RaspiOS SD card and copy the updated "SYSTEM" file back onto your LE9 SD card and any further LibreELEC installations that you plan to use on Pi Zero 2s. Don't forget to include the VCOS components which are necessary to boot, as previously discussed.

Quote from metaron

Just managed to follow Synerworks latest post above successfully with one minor addition. I also copied brcmfmac43436-sdio.clm_blob into the /storage/.config/firmware/brcm folder (re-naming it brcmfmac43430-sdio.clm_blob) to remove a dmesg error.

(I had previously associated this missing file with not getting any wireless network adapters detected, but I guess that must have been finger trouble elsewhere)

The clm_blob is not "essential" for getting wireless working, once the regulatory domain is set with the LibreELEC configuration tool, all is good. The correct "FIX" for the Pi Zero 2 would be to add the BCM43436 firmware to the LE9.2.8 build release and update "brcmfmac" to correctly identify it on loading. As I had pointed out, not likely to happen since LibreELEC has long moved on. Without another working cut, the applied approach still enables even the legacy LE7, LE8, and LE9 releases to be tested/used on the Pi Zero 2.

As originally pointed out, I prefer to use the modified squashfs "SYSTEM" file for all legacy releases with the replaced firmware and put a ZIP archive together including the required VCOS components for simplicity. When needing to create the media with the LibreELEC.USB-SD.Creator, just unZIPing the changes to the card takes less than a second, no biggie, so it does not bother me whether a refresh ever occurs or not.

** OK, as suspected, stick with what is at hand ... https://github.com/LibreELEC/LibreELEC.tv/issues/5971

Quote from Morphy

Synerworks that's awesome! Thanks for the guide! I knew someone would've hacked together a working LE build for it. I got as far as the LE logo in my attempts earlier 😄

Does the memory issue cause many problems? I only need it to act as a tvheadend client, so only watching live TV, do you think this will be a problem?

trent

Thanks for confirming the issue! I guess they are new and not exactly ideal for LE due to the lack of memory so there is no rush to get them supported. The pi hut in the UK has them in stock, limited to one per order though. I've got a spare one I'd be willing to donate if any Devs want to play drop me a pm 🙂

Running just the TVheadend client on LE8 would be better choice on the Pi Zero 2, the base in-use memory footprint is less than half that of LE9 so leaving enough to be reasonable. Plus LE11 is almost 1.5x that of LE8, so I would expect that the 512MB ceiling would certainly become a problem.