There are a couple of Meson8b (S805) device-trees. See what works most.

Meson 8* Lives!
- chewitt
- Thread is Unresolved
-
-
Very good. I should have some free days in the next few days.
It will be good fun 😁.
-
I made a first attempt with an old SD card. Did not boot. I don't know if it's dtb, the image or my SD.
My box is an M201c (S805 with 1 GB). What would be the correct dtb?
I'll try again later.
-
Even with a new SD card it didn't start. Who knows in the next update.
-
Hi chewitt
Some testing feedback FYI.
I rebased the pre-pre-Alpha AMLMX image on LE master and Martin's latest kernel branch one month ago and built this image:
https://chewitt.libreelec.tv/t…MX.arm-10.88.0-box.img.gz
It's been boot tested by a couple of people but might need some manual finessing of the u-boot environment to get it booting
You are welcome to report bugs (there will be some) but this is completely unsupported
I wrote the below [11th Jan 2023] img - sha256 a28aaf0be4de01fa080022c1d148f19de042bc3a0c9576c546afe30d55a15992
LibreELEC-AMLMX.arm-10.88.0-box.img.gz 117.6 MiB 2023-Jan-11 05:21 to an SD card and attempted to have it boot in my Minix Neo X8-H Plus Amlogic Meson8 S812-H box.
Without any adjustment, just as-is the SD card kind of booted. this is with the uEnv.ini set as per defaults @@DTB_NAME@@ left . My Sony LCD TV detected 720p and displayed the LibreELEC splash screen [noting it looked normal as compared to some of the next green versions]. Then I was prompted with a "Starting debugging shell for boot" to type exit as it was attempting a mount_sysroot and failing. Error shown for the UUID not being mounted, After entering exit a second time on the next almost identical prompt mount_storage a screen of kernel panics was displayed.
I then attempted to edit the uEnv.ini and specify one of the dtbs.
Firstly I tried - with no screen activity, perhaps a blink of a line before black.
then I tried meson8b-ec100.dtb - a green 1080p very interlaced and spread-out LibreELEC splash screen and the SD card repartitioned to fill the remaining space. On reboot (needed to be unplugged as it was taking a long time and I was impatient) the same green interlaced and spreadout LibreELEC splash screen displayed and a "failed to unmount /flash: Device or resource busy" error displayed top line and next line " systemd-shutdown[1]: Failed to finalise file system, loop devices, ignoring.
next I tried meson8b-mxq.dtb - same green 1080p LibreELEC splash screen and after a wait nothing displayed and no progression.
then I tried meson8b-odroidc1.dtb - same green 1080p splashscreen.
next one was meson8m2-m8s.dtb - same splashscreen in same green stretch / interlaced output.. I was most hopeful for this one as the dtech image LibreELEC-X8H-Plus.arm-9.2.8.8.img.gz (kernel 3.10.108) from http://libreelec.dtech.hu/images/3rdParty/ identifies as Amlogic S812 with (Meson2m2) specifically shown within the Hardware group on the system info page within settings.....
I tried meson8m2-mxiii.dtb and meson8m2-mxiii-plus.dtb all green interlaced splashscreens.
The meson8m2-wetek-core.dtb and meson8-minix-neo-x8.dtb however was detected as a 1080p output but remained blank screen and no display.
Finally meson8-tronsmart-s82.dtb was detected as 1080p and a totally white, (very bright) with some pixels was displayed.
For interests sake - I repeated the above with the slightly newer [3rd Feb 2023] - sha256 583f665c3afb73f5cbe20ff0df166dbcc91d751b24ed34bc0bc10d6e5d6f3bc7
LibreELEC-AMLMX.arm-10.85.0-box.img.gz 113.7 MiB 2022-Feb-03 08:11 same 720p normal looking LibreELEC splash screen on an untouched @@DTB_NAME@@ uEnv.ini and green interlaced 1080p for the others or blank / no display.
-
Testing with no dtb name or dtb's for SoC types that don't match yours (S812 aka meson8m2) is pointless. I would not expect them to work so we can ignore those non-results. And if you're going to report an issue (on the correct SoC type) as a minimum you need to share the URL generated by "pastekodi" after accessing via SSH, or dump the systemd journal and pastebin it somewhere.
-
Understood thanks. None of the DTBs got the Minix Neo X8-H Plus to boot to a point where I could SSH into the unit to run the pastekodi diagnostic commands.
Ill try and get console access and see what I can share or get to boot beyond the splash screen
-
There's only one upstream developer working on Meson8 support (Martin B) and he has a busy day job so output comes and goes depending on when he has some free time (and enthusiasm). I rebased the pre-pre-Alpha AMLMX image on LE master and Martin's latest kernel branch one month ago and built this image:
https://chewitt.libreelec.tv/t…MX.arm-10.88.0-box.img.gz
It's been boot tested by a couple of people but might need some manual finessing of the u-boot environment to get it booting - I one have one Meson8 box (and one board) and vendor u-boot from 2013 is an archaeology experience, so the scripts used to hook and boot into LE aren't finalised.
You are welcome to report bugs (there will be some) but this is completely unsupported
Ah! I can resume playing with my WeTek Core! That's exciting. I've however been quickly stopped in my tracks.
I think in the past, I installed LE with via recovery with the ZIP distribution, but I'm not sure how to get this booted from an IMG.
I extracted/DD'd it to the same SD card as I was using before. I can see the KERNEL and SYSTEM files, as well as the uEnv.ini, which I've edited to use the meson8m2-wetek-core.dtb, and a bunch of others but...
How do I make that boot? I've been looking around for documentation for the last hour, and came up blank
-
How do I make that boot? I've been looking around for documentation for the last hour, and came up blank
Ok, found it.
Quote from dtech
WeTek Core with Amlogic S812-H SoC (2 GB RAM, 8 GB eMMC/NAND):
Working services: Power status LED, CPU temperature sensor, Analog+S/PDIF+HDMI audio output, Gigabit Ethernet, Wireless (2.4+5 GHz), Bluetooth, RF+IR combo remote control (HID+amremote), HDMI-CEC, NAND boot*.
So, it boots to a black screen, not sure how to take it from there. Should it try to get an IP from the network? Should I plug the Ethernet.
-
Wrong quote above. Leaving this for completeness about how to boot the WeTek Core into the SD.
- Boot LibreELEC from your previously prepared bootable media:
If you want to boot the device from your bootable media, you need to perform the toothpick method first:
Disconnect the power plug, insert the prepared boot media, and then press and hold the reset button*. Reconnect the power jack while holding down the reset button, then release it after about 3-5 seconds**.
* The reset button on MXQ and M8S+ is located behind the A/V connector, but on the Mecool and WeTek devices, the reset button is located behind the hole on the bottom of the device.
** If the Android recovery menu appeared, you pressed the button for too long.
- Boot LibreELEC from your previously prepared bootable media:
-
WeTek Core(1) will not boot beyond vendor u-boot into Linux unless you limit the kernel to a single CPU in boot args (at which point the box isn't much use). It's a known issue for that box and something related to the box using OP-TEE (BL32). Other S812 devices will boot normally (not that AMLMX has much support for boot currently).
dtech images are a better option, although K18 is starting to date now.
-
Ah cool. So not quite there yet.
Well, in any case, I have a WeTek Core setup that seems to go as far as it can with the current images, so happy to try out new ones as they come!
-
Some more exciting news coming up for this old champ:
I have ported Batocera Linux RetroGaming Firmware on this soc thanks to Martin Blumenstingl excellent work!
You can try and test it here
batocera-s812-30-20210214.img.gz | by Demetris. for MXQ TV Box
It should be able to boot straight on a MXIII-G/PLUS S812 board for the others you now the drill of renaming the dtb.
Hi Demetris, can you reup the batocera image for s812 board? Thank you!
-
I have tried your image (LibreELEC-AMLMX.arm-10.88.0-box.img) on my old probox x2 (S802) since Kodi 18.9 is getting more and more outdated, unfortunately.
Following status:
it does boot with meson8-tronsmart-s82.dtb. boot screen logo was yellow or green but I guess this is not relevant for now. Kodi is permanently restarting:
Code
Display More############# kodi CRASH LOG ############### ################ SYSTEM INFO ################ Date: Fri Sep 15 08:57:42 UTC 2023 kodi Options: --standalone -fs Arch: armv7l Kernel: Linux 6.2.0-rc1 #1 SMP Wed Jan 11 05:20:55 UTC 2023 Release: LibreELEC 10.88.0 ############## END SYSTEM INFO ############## ############### STACK TRACE ################# =====> Core file: /storage/.cache/cores/core.!usr!lib!kodi!kodi.bin.1694768245.889 ========================================= [New LWP 889] [New LWP 890] [New LWP 892] [New LWP 893] [New LWP 894] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `/usr/lib/kodi/kodi.bin --standalone -fs'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x010a3d44 in KODI::WINDOWING::GBM::CDRMUtils::FindPlanes() () [Current thread is 1 (Thread 0xb2bd3900 (LWP 889))] Thread 5 (Thread 0xacdff280 (LWP 894)): #0 0xb4645ed8 in epoll_wait () from /usr/lib/libc.so.6 #1 0x00576d40 in CLibInputHandler::Process() () #2 0x0085e150 in CThread::Action() () #3 0x010de448 in ?? () #4 0x00858d58 in ?? () #5 0xb443dd24 in ?? () from /usr/lib/libstdc++.so.6 #6 0xb45d3070 in ?? () from /usr/lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 0xad7ff280 (LWP 893)): #0 0xb46333c8 in read () from /usr/lib/libc.so.6 #1 0xb6da497c in lirc_nextcode () from /usr/lib/liblirc_client.so.0 #2 0x00552810 in CLirc::Process() () #3 0x0085e150 in CThread::Action() () #4 0x010de448 in ?? () #5 0x00858d58 in ?? () #6 0xb443dd24 in ?? () from /usr/lib/libstdc++.so.6 #7 0xb45d3070 in ?? () from /usr/lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 3 (Thread 0xae1ff280 (LWP 892)): #0 0xb46399c0 in poll () from /usr/lib/libc.so.6 #1 0xb6b23838 in ?? () from /usr/lib/libpulse.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 0xb2bd0280 (LWP 890)): #0 0xb45cf740 in ?? () from /usr/lib/libc.so.6 #1 0xb45d26f4 in pthread_cond_wait () from /usr/lib/libc.so.6 #2 0x0085d58c in ?? () #3 0x00f77cec in ANNOUNCEMENT::CAnnouncementManager::Process() () #4 0x0085e150 in CThread::Action() () #5 0x010de448 in ?? () #6 0x00858d58 in ?? () #7 0xb443dd24 in ?? () from /usr/lib/libstdc++.so.6 #8 0xb45d3070 in ?? () from /usr/lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 0xb2bd3900 (LWP 889)): #0 0x010a3d44 in KODI::WINDOWING::GBM::CDRMUtils::FindPlanes() () #1 0x010b21b8 in KODI::WINDOWING::GBM::CDRMUtils::InitDrm() () #2 0x010b272c in KODI::WINDOWING::GBM::CDRMAtomic::InitDrm() () #3 0x010aafc8 in KODI::WINDOWING::GBM::CWinSystemGbm::InitWindowSystem() () #4 0x010b58b4 in KODI::WINDOWING::GBM::CWinSystemGbmEGLContext::InitWindowSystemEGL(int, int) () #5 0x010b5bc4 in KODI::WINDOWING::GBM::CWinSystemGbmGLESContext::InitWindowSystem() () #6 0x00a09e24 in CApplication::CreateGUI() () #7 0x008985c0 in XBMC_Run () #8 0x002e52f8 in main () ############# END STACK TRACE ###############
So I have stopped it at boot via autostart.sh.
I believe the root is cause is an issue with the drm kernel driver not being able to set the frequency:
Code
Display More2553.470380] lima d00c0000.gpu: gp - mali450 version major 0 minor 0 [ 2553.470440] lima d00c0000.gpu: pp0 - mali450 version major 0 minor 0 [ 2553.470486] lima d00c0000.gpu: pp1 - mali450 version major 0 minor 0 [ 2553.470530] lima d00c0000.gpu: pp2 - mali450 version major 0 minor 0 [ 2553.470580] lima d00c0000.gpu: pp4 - mali450 version major 0 minor 0 [ 2553.470625] lima d00c0000.gpu: pp5 - mali450 version major 0 minor 0 [ 2553.470669] lima d00c0000.gpu: pp6 - mali450 version major 0 minor 0 [ 2553.470691] lima d00c0000.gpu: l2 cache 8K, 4-way, 64byte cache line, 128bit external bus [ 2553.470703] lima d00c0000.gpu: l2 cache 128K, 4-way, 64byte cache line, 128bit external bus [ 2553.470714] lima d00c0000.gpu: l2 cache 128K, 4-way, 64byte cache line, 128bit external bus [ 2553.471021] lima d00c0000.gpu: bus rate = 141666667 [ 2553.471034] lima d00c0000.gpu: mod rate = 318750000 [ 2553.473924] [drm] Initialized lima 1.1.0 20191231 for d00c0000.gpu on minor 1 [ 2553.528922] lima d00c0000.gpu: _opp_config_clk_single: failed to set clock rate: -16 [ 2553.528960] devfreq d00c0000.gpu: dvfs failed with (-16) error [ 2553.588735] lima d00c0000.gpu: _opp_config_clk_single: failed to set clock rate: -16 [ 2553.588751] devfreq d00c0000.gpu: dvfs failed with (-16) error [ 2553.648728] lima d00c0000.gpu: _opp_config_clk_single: failed to set clock rate: -16 [ 2553.648742] devfreq d00c0000.gpu: dvfs failed with (-16) error [ 2553.708751] lima d00c0000.gpu: _opp_config_clk_single: failed to set clock rate: -16 [ 2553.708767] devfreq d00c0000.gpu: dvfs failed with (-16) error
Perhaps something wrong within the dtbs, not sure.
Other than that, lan is working, bluetooth might be - quite amazing to see kernel 6.2.0-rc1 booting on this old device.
br,
-
I have tried your image (LibreELEC-AMLMX.arm-10.88.0-box.img)
You've done more than me then
Martin seems to be MIA at the moment so the best I can suggest is self-building using my AMLMX branch but with the Linux package update to use his latest kernel source (Linux 6.3 IIRC) to see if anything changed.
-
Martin seems to be MIA at the moment so the best I can suggest is self-building using my AMLMX branch but with the Linux package update to use his latest kernel source (Linux 6.3 IIRC) to see if anything changed.
I did already, cross compiled his version of 6.3 with the config from your kernel version 6.2 and modified your image file with kernel 6.3. It does boot, but the issue is the same. I also believe the frequency issue is not the root cause. I adjusted the dtbs file to use a fixed frequency and ignore the opp table - the error message is gone but still the same issue with kodi.
Next I have tried Armbian with kernel 5.14 to get a bit more control. Xorg refuses to start since no permission to /dev/dri/dri0. Probably something with the driver itself. So it seems there is no access to the Mali 450 device. Strange that it works on S805, I didn't expect it be so much different than the S802.
Br,