Posts by buzzmarshall

    not sure how pertinent this may be but being your playing with older boxes sometimes what i think happens is the actual bootloader in the flash on the box gets buggerd and causes the new install to not properly see the bootdisk your trying to install which is why back in the old days we built boot loaders based on the actual bootloader in the box.

    In that type of setup the bootloader we created actually fully overwrites whats in the flash on the box and as long as the bootloader was built based on a dtb based on that actual box and its hardware.

    every old box has its own picky way of interrupting the flashed boot loader so you need to play a bit to figure what actually gets you in.

    a lot of the older boxes sometimes from the newer methods trying to patch the existing bootloader screw up the existing one causing the corrupted file message and not wanting to run it. sometimes what seems to help is to restore the box to original Android software and let it restore the original flash bootloader and then try what your doing.

    eg: The Eny original M8S boxes used to do that all the time which is why i built a M8S specific boot loader based on its exact hardware and then in the project use that file as the bootloader to flash to the system. For some reason some of the older S8xx and earlier boxes seem to fight being patched and can be a real headache while other boxes seem to be easily pushed into working... Freak tab used to be flooded with threads bout old boxes and boot loader issues.

    All the newer boxes (S9xx) i have coded seem to work with the current methods of handling the bootloader whether its booting off a sd-card or installing internally and its just a matter of having the right dtb to get all the hardware recognized...

    just for informations sake... the way you build the actual bootloader is to restore the manufacturers original firwmware and then setup ssh or serial monitor and log into the running box and then dump out all the required memory areas and parts and then put that together to create your specific bootloader for that box and use that as the bootloader... its not as flexible as the newer patchable method but does give you a proper bootloader for that box so for anyone doing a bunch of the same box its a goof proof method of flashing something other then Android to the box.

    Meson 8 hardware like the S812 has a reasonable future once we bump to mainline kernels. There is a lot of IP in common with the newer GX platform so while it's not as popular for development it inherits a lot of support and has an active kernel maintainer (Martin Blumenstingl). The critical missing software component needed for LE to run mainline kernels on S812 is an HDMI driver, and the active plan is to adapt work done for GX boards once it's more feature complete (the HDMI chip is different but we should be able to reuse the core DRM code). Martin has already done some early poking of code but no "video on screen" eureka moment happened yet. LE plans to drop 3.10 kernel support after LE 9.0 ships so there will be a support gap for S802/805/812 devices until an HDMI driver is ready, but I'm cautiously optimistic that something appears before LE10.0. Support can be added back then - although this probably becomes a community effort more than core team effort. Other 3.10 kernel devices using the 8726MX chip (WeTek Play etc.) have no mainline kernel future ahead as Meson 6 has marginal upstream support and nobody working to improve that.

    buzzmarshall On the topic of S912 having no future due to the lack of mali blob .. we've been working on making a lot people eat their hats :)

    See this video from a few days ago: YouTube

    I agree and its to bad because the old 3.10 could have been migrated up to at least 3.14 years ago if Amlogic would have played ball but they are more intent on letting the hackers do all the hard lifting while they gain the market share... There were a few of us years ago trying to talk to Amlogic about support on linux but the interest went ignored by Amlogic till finally enough reviews in mags and other online places seemed to get them to at least open up a little bit but only to a handful of people so most of us just went back to doing our own thing and ignored whats going on in the public. It was a nice thing to see you guys get going as OpenELEC seemed to stagnate as they became more WeTek oriented, which was a really nice boom and appears to continue on in that direction...


    On a Personal note. Amlogic just infuriates me with their attitude towards outsiders and to be honest as far as the box market goes i really think they are some of the worst coders when it comes to supporting their own products and the proof was really apparent when the forced their downstream manufactures to jump up on the bandwagon with the S912 based boxes that used the a Mali core that they themselves refused to licence the DDK leaving the issues the way they are. Even with the canned Android version provided to them those boxes are not really taking advantage of what those SoC's are capable of... for them it was more important to keep their release

    Meanwhile the public is still struggling and Amlogic will leave all the heavy lifting like updating and unifying onto Linux mainstream up to private coders that eventually figure what ends up and either move onto new play toys or become a dealer and do their own thing. Rockchip guys seem to be much more forth-coming with support and help tho which is nice to see, All winner i can't speak much to as i have never played with one.

    Thanx for the heads up tho about Panfrost and Lima as its been awhile since I have looked around as i now have other interests but they look interesting and hopefully will provide some good outcomes. on another note i am actually a bit surprised that 3.14 or higher on the older S8xx boxes have not become a reality because its been done privately for quite some time now but i quess thats what happened when Amlogic ignored all that interest years ago... i don't think Amlogic coders understand or are decent enough Linux coders so they just stick to the canned versions of Android they buy support for.

    Dont get me wrong theres nothing wrong with Android but putting a touch input based OS on a box like this is just more of a novelty then anything but hey, it lets google track everyone and its free. Linux truly is the answer on the boxes and its projects like LIbreELEC and the spin-offs that prove my point... keep up the good work...

    Sorry been away for a bit... Unfortunately the only builds i have for the older S8xx boxes are very specific to the boards in the boxes i was using back then, The methods pre-date the existence of LibreELEC and involved different methods to remove Android and install a Linux based Kodi build on a box. Things have got much easier these days with places like LibreELEC and CoreELEC and newer methods such as dual booting and how u-boot is currently being used. Currently i just mess with a old Matricom MX2 box I have just to see how well the newest kodi runs on the older dual-core boxes.

    I do agree its a shame that so many older boxes are being pitched while people are forced to buy newer boxes. Personally i am not sure how well the older Dual Core boxes will do going forward because most of them are built with just 1 gig of ram and as Kodi moves forward its always best to have more ram for streaming. But easily I can see a lot of the S812 boxes sticking around for awhile. As a box developer only interested in a installed Linux system I will say that the S812 boxes are still good boxes in most cases out perform any of the S912 boxes I have coded for since their release a few years ago.

    The S912 based boxes are really a total waste of money other then the larger Sram and Flash space when it comes to a Installed Linux system because of Amlogics anal attitude towards supporting Linux as there is no legal way to gain the actual hardware use of the Mali T8xx graphics chipset without the missing low level parts. The S912 only half-assed works graphically because of some Inventive coders that are using Android stubs or migrating to X11 based graphics trying to create a video driver the works. The only way I know of that can remedy the issue is for Amlogic to pony up to the table and pay Arm for the Mali ddk and actually release the missing parts or for people to scour the net to find a bootleg copy of the DDK and produce their own driver but then realize thats not something that can be released to the public. For anyone wanting to run Android on the S912 box then things are different because the canned version of Android that Amlogic provides its downstream vendors as least supports the graphix hardware (tho rather poorly performance wise).

    People are better off just sticking with the S905 based boxes with the older Mali 450's which are well supported.

    I can't say for LibreELEC but i've got the newest CoreELEC (which like pretty much all of them just another derivative of OpenELEC) to work ok on MX2 boxes ok... As said earlier you need to be picky with some of the emulator cores but most work fine. Kodi is at rc2 but needs to be played with as the older dual core Amlogic chips arent quite the same as the newer S9xx based cores. But making the newest releases work on the older dual core amlogics is doable im just not sure its worth the effort in light of the cost of newer boxes and for anyone not well versed with Kodi developement and coding its a stretch... Theres alot of changes in 18 as things move up to python3 and better streaming drivers are developed and implimented. but it does work.

    On another note i find i don't use the newer methods of installing on the older S8xx and older boxes, i always install straight to the box and totally remove Android and use my own low level bootloader thats based on the actual box your messing with. that way whatever hardware is in that particular box is always right from the git go. The newer methods such as flash or dual boot based are great for the new S9xx bases Soc's but i find can be real hit and miss on the older boxes as theres so many clones and crap boxes that swap out chipset stuff making things not worth the effort.

    Hm... i can't say for 18.10 but i updated all my build machines (8) up from either 15.04 and 16.04 back at the end of the summer to 18.04 xubuntu and have had no issues other then with kodi when it comes to building for any of the Amlogic boxes or for X86_64 Pc's...

    The only issues i have ever run into usually stem from kodi being bumped up from the betas to the release candidates and usually the issue is tied back to the changes made requiring ninja now to build kodi...

    18.04 has automake 1.15.1 not sure if that would help or not. i know ubuntu can be a pain with its packages and i am constantly breaking things by trying to update certain packages and building them from sources but i know just the other day i built the S912 and migrated a S812 project of my own into a fresh 18.04 install onto another build machine and the current le9 (master) git pull built just fine other then Kodi rc2 giving me a couple of issues with ninja and the JsonSchemaBuilder package..

    Ive been using linux since its original release but i feel your pain as i know how tempermental ubuntu can be when messing with its packages/versions. i refuse to use virtual building or docker crap but sometimes its just easier but can say that 18.04 builds fine whether you use the stripped down server install or the xfce desktop.

    thats a good one... obsolescence before a product is even properly developed... lol...

    i've been developing xbmp/xbmc since frodo released the sources back around 2003 and it wasn't till Xbmc/Kodi was released on Android that companies like Amlogic emerged from the tablet industry to take advantage of Open Source like Kodi to drive a much smaller Tvbox market into whats it grown into...

    They don't seem to have a problem making use of Open Source products like Kodi to drive a huge increase in their SoC products for years they never seem to follow through on promises of proper linux support... instead they push out their SoC's to factories that sell products with inferior firmware as they have become used to relying on 3rd party sites like here to create any real working software for buyers with boxes that perform poorly..

    Probably well over half the people buying Android boxes are doing so to run Kodi or game emulators and a simple fact is both of those applications run more reliably and stable on Linux... thats not to say Androids bad but wasting a ton of hardware resources on the Android OS is a waste of the little resources these embedded boxes have...

    I get Amlogics rights to control their product but then they should stay away from open source developments like Kodi and create the own products like some of the other proprietary boxes do... This idea of them NOT having the DDK required for the Mali userspace is just another excuse to try and hinder the linux developers while dumping the problems onto the great group of online programmers that are driven by their own purposed to create solutions for the public that cost them nothing...

    Think about how many less boxes would be sold if projects like Here or OpenELEC did not exist as end users would forever be stuck running the crappy Android solutions they help the factories provide... Almost everyone that comes to me does so because of bad Android experiences on boxes they've bought and given up trying to get working...

    Under the circumstances i don't think its Unreasonable to expect Amlogic to provide the required software support... Its more like Amlogic figures the publics stupid and people will just keep buying different boxes till hopefully they end up with something someone can make work for them...

    As and example... Currently i know a couple of dealers that sunk their money into S912's because the factories they buy from assured them they were solid boxes and the S812's were being phased out, between them they ended up with a couple hundred junk boxes that even after the factory tried to downgrade them to Android 5 they still were not reliable enough to run Kodi properly thus leading to people wanting to return their boxes... eventually they were told by the factories that the factory was going to contact Amlogic for help and thats where things stopped and have been now since last fall...

    Amlogic sets this crap in motion by getting the factories to use the new S912 which even Android itself is still at a buggy level itself... and in the end its the individual buyer halfway around the world that gets beat as who's going to waste that much time on a none working box thats probably not worth the costs in time and trying to ship and return...

    Personally i dont get why Amlogic's never been more forthcoming with help with linux on places like this because you guys here actually do provide working solutions for people at no expense to them which i'm sure help keep people wanting to buy boxes...

    your right X11 does work but tends to be more complicated for the enduser when issues pop up and its kinda a waste to not have the advantage of the acceleration at a hardware level..

    anyways i digress... just sad to see Amlogic become some 2-bit company when it could be so much more...

    Just to be clear about this... I don't think anyone is to blame other then Amlogic by pushing a SoC to the box makers without decently supporting it to begin with...

    wrxtasy... i agree and understand 100% when it comes to dealers and the innocent buyer looking for the best deal...

    The question one begs to ask is ... why Amlogic would choose to base their new flagship SoC S912 around a gpu based on IpCores for a processor they claim they cant produce the required linux userspace binaries for... I find the idea of Amlogic NOT having the Mali DDK for the Midgard T82xx they used in the S912 to be insane...

    This is how the Arm rep explained it to me... Arm supplies the required Mali DDK (in this case) to whoever the Silicon Partner is, Amlogic in this case. A few of us awhile back looked into trying to get the DDK from Arm...

    This is about Amlogic retaining control...

    Amlogic has always had Terrible support for Linux from the git go, sure, over the years they've gotten better as they appear to be helpful by throwing a bone once and awhile and by providing limited info to handful of coders, but that didn't seem to come until they seen a handful of coders sink their time into making Linux a reality by letting others do most of the work. Amlogic already controls most of the market as they spoon feed the manufactures who are more then happy in most cases to pass the firmware buck off to someone else which is why so much of the existing Android firmware is so similar from box to box no matter who the actual maker is. In alot of cases is just small differences in the device tree info that differs as small parts of the SoC may change. Ive spent years disassembling box firmware files and its not hard to see all the common markers from one vendor do the next, point being Amlogic's in control.

    All thats fine with me but people really should be made aware of the reality of things and its simple in that Until Amlogic decides to help with userland binaries to let Linux be fully supported on the S912's things are going to be tough to progress and in the meantime dealers keep pushing the S912 based boxes off on the mis-informed buyers coerced into buying a S912 box with buggy software... meaning Android...

    After 3 years of pestering Amlogic and not once having a emall of phone call returned I have long since given up asking for help... Having other Arm Sdk's lead me to ask a Arm rep about aquiring the Mali DDK and was told Arm will provide the required tools to their silicon partners after some terms are met... NDA's ... money... so basically it means if your not a huge volume vendor NO... further to the question was because Amlogic is the Silicon Partner using the T82x in question that it would be up to them to provide the Userland binaries for the version specific linux kernel to allow linux to run... the only way around this would be to find another silicon partner that has the full ddk to do it which again probably mean No... I asked as well about myself being able to sign/pay so as to able to create linux binaries as a company for exiting mali based products and was told they would get back to me which after that point all i got was a email thanking me for interest in the product and i never heard anymore. that was early last year...

    I spent a lot of time looking at the S912 as i truly thought it would be the next powerhouse in the cheaper SoC market as compared to the more expensive Intel or Nvidia level of boxes, but in now light of watching Amlogics tactics tell my customers to avoid the S912 based boxes no matter who they buy it from...
    would tell others to stick with boxes that have current public support and for anyone looking for more power to forget about Amlogic products as they seem to now be more about selling and less about support.

    In the meantime as others have said... they are being forced to upgrade by the manufacturers stopping the production on earlier models that had just finally started to come into their own as truly good stable software is finally coming from non-amlogic sources such as here and other places... Amlogic is taking advantage of a over populated manufacturing market by using the introduction of Rush-to-Market on products while trying to compete and the reality is its not because the chip isn't not a good design but rather over them trying to retain software control at the consumers cost...

    I know its not gonna happen but the best thing that could happen for now would be for the dealers buying from the manufactures to stop purchasing S912 based boxes and stick with boxes that are better supported, which i am sure from the manufactures point makes no never mind as they are really only interested in selling what theres a demand for... it might even make boxes cheaper as the S812 should be cheaper as they are no longer Amlogics cadilac...

    I understand business and how things are done but in the case of the S912's even Android is not very stable let alone expect Kodi to be any better is deceiving as to be honest we all know that Kodi with its ability to stream media is a key driver behind a lot of the increased interest in tv boxes...

    Hardkernel and the Odroid boards as far as i am aware are using the earlier Midgard or older Mali's so getting help from him may not be applicable...

    Kszaq... sorry if in anyway i come off as trying to imply or say your misinforming anyone as that is truly not my intention, i'm sure your repeating someone else's excuses for a problem of their own creation, and i truly hope what you said is wrong...

    on another note... keep up the great work, because you and the others like you a great many people have got working boxes because of you guys and the support you have managed to give the public... someday i hope someone rewards you guys for all the work you guys do because you guys deserve it...

    For me i am not interested in using Android to turn a TVbox into another Google spy toy as the people that come to me have already had a bad Android box experience because of a box they bought that doesn't function in the manner the dealer that sold it to them said it would, as a result i realized there was a decent market in providing people with a decent working solution when it comes to Android boxes and streaming media... My business is about providing the best running solution i can create for the end user and ive had to learn a few hard lessons over the years buy not staying away from certain things. If i sound biased towards a linux solution, its because i am... lol...

    There are methods of solving the issues but in some cases they introduce other issues and are bulky and not somthing i would want to dump into the public domain as that would just help justify Amlogics sale of the S912... I spent many years reverse engineering smart card wafers and firmware so i am not totally unfamiliar with firmware disassembly and hardware using jtag and other debugging links, but any real solution for public use is probably going to rely on Amlogic or someone else that can legally lay their hands on the Mali DDK to compile the version specific Userland Binaries... Maybe its time to dig out the old BlackHat and put in some time digging around... Even tho Odroids using a different midgard product following some of the threads over there help with a better understanding as there are some great guys and good posts for anyone researching the topic.

    Anyways... just my thoughts and hopefully i have not pee'd in anyones sandbox... I don't post all that much as i'm busy doing my own thing but do like to see what others are up to... it was the comments implying that buyers are responsible for what they get that got me to speak up... and i do agree that at times people do deserve what they get but i usually treat that as a case by case rather then blanket general statement...

    i would agree with kenmills... ive been doing this for a long long time and its kinda disheartening to see other supposedly smarter users flaming others over a issue thats ALWAYS been the manufacturers problem... most are smart enough to realize that the average joe tends to buy whats the best deal and with the manner most dealers market their wares it tough for perspective buys to know any better...

    The manufactures have always had a poor track record in providing good software support for the boards they decide to create and release as they have become overly dependent on the growing group of online programmers who tend to be hobbiest or part time guys trying to enjoy themselves for software that actually works properly or is more up to date. Most manufactures seem to focus on releasing the next generation of wonder boxes while they compete amongst themselves and depend on the on-line guys to fix up their messes. Even Amlogic is not very forth coming in providing proper information other then to a small handful of guys while locking everyone else out, which im sure at sometime will come back to bite them as other better supported SoCs will eventually push Amlogic backinto the tablet market, the whole Android box market is like gravy to them until the bigger players get their prices down and then things will change.

    As far as the S912 goes its possible to make a working graphics stack as there are ways of gleaning the information required to make up the user space portion Amlogic refuses to release. Its just extremely time consuming and ludicrous that others have to commit to that to create working solutions for the products that Amlogic help the main manufacturers create and dump on the open market. Currently i have both the T95K and T95U Pro boxes running Krypton as well as currently working Leia on linux.

    Sorry for the rant it just irks me to see other supposedly smarter users blaming the average unsuspecting buyer for expecting what they buy to work... and dont come ban as say they are at least providing Android support which lets them off the hook because both of these newer boxes im developing for came from a reputable manufacturer and even Android thats PROVIDED constantly crashes/locks up as Kodi performs extremely poorly and has a number of issues...

    hm... ive been compiling your setup for both the MXIII... as well as for Eny's M8S with a project i added to your sources specifically for the M8S and everything actually works pretty well...

    the only issue i seem to have and havent nailed down yet why is that streaming with every plugin ive tried works great but when it comes to playing local content and using Kodi's library funtions causes the box to hang on the home screen and keep recyling from the Jarvis 16.1 entrance screen to a basically blank confluence home page... ( its the home page background with nothing else showing)...

    ive tried running full debug logs and about the only thing i ever find in any of the logs no matter what debug log level you run is a few "CSkinInfo: failed to load skin settings" message in the log files... ssh'ing into the box and i can see and check all the running process's and even the crash logs dont indicate anything specific to the whats causing the issue... going into the userdata directory and tossing the MyVideo99.db will instantly restore the box on the next cycle between the Jarvis entrance screen and confluences home page... its only the content databases that seem to hang... the plugin db seems ok... from observing the running processes and watching the actual box screen on the tv you can see that when you try and scan in any video or music content that the scrapers appear to be going out and gathering all the metadata and then you'll see the "compressing the database" message and from that point as soon as you try and go back to the home screen that the box is now hung between the Jarvis entrance and Home Page of the skin your usiing... ive tried other skins and the symptoms are the same...

    so far ive not been able to nail down the cause but it almost seems to like either the used database is not closed properly or somethings being put into it thats causing a issue because. its any attempt to put content into either the myvideos or the mymusic ones that cause the problem... throwing them away fixes the issue as they get recreated to their empty defaults and seem fine...

    ive downloaded the updated db's and looked in them and they all appear to be fine and are filled with valid info... Ive a huge amount of local video and music sources all locally stored on about 16 terabytes of local servers that work fine with everything else and had it not been for trying to scan in that local content i'd wouldnt have noticed the issue as streaming everything else i typically do worked great.. im NOT using mysql to centralize the data so the box is just using the built in Sqlite to handle the box locally... ive tried scanning flat file directories as well as recursively trying to see if that was a issue as i know that with some boxes still running Android and using Kodi with smb shares can cause db problems so nfs is used to solve that... in this cause tho cause theres no android that should not be a issue...

    eventually when i get time i will find the issue but thought i would just mention the issue to see if its just me or if others have experienced the same thing...

    other then that your project seems to be pretty good and im sure will make alot of the S812 users happy... and im glad to see people like you helping to support others...
    keep up the great work...

    All things aside... i think most all make valid points as to how things have evolved and will continue to and i thank all involved in both camps as ive just kept to myself and done my own thing as im only interested in 2 particular boxes that i use... over all tho i tend to look at both projects as basically coming down to the boxes they each support rather then trying to pit one project against or over the other...

    as i said im thankful for both camps and will continue to watch and learn from both...

    i can understand why some think to many get swayed into the makers trap and just blindly buy products with poor support but to say the 912 SoC is useless is just plain un-informed... just because theres not a plethora of software floating around is not a valid reason to condemn the chip... Ive had my own linux-kodi software running on T95u-pros since they came out... its not all the difficult for anyone wanting to do their own thing... ive been using original M8S's on my own firmware since they came out and it wasn't all that much work to port it up to the S912's im using...

    Unfortunately the current coders are putting what little time they have into supporting the projects they already have and people need to respect that... im sure in time you'll see 912 builds in all the OpenElec and Libreelec projects... you can bet the box makers are hoping as well because they now how crappy their own firmware generally is and have been using coders on sites like this or FT for years to fix their problems or just plain outright scab some code and call it theirs...

    but lets not be lame and trash the whole chipset just because of a lack of support at this point in time... hardware specs dont mean shit without decent firmware and just about every chip used in these cheap boxes for years now have been plagued with either buggy or badly performing firmware...

    my 2 cents...

    sorry should have clarified... yes i made my own firmware strickly for the eny m8s boxes that i use...

    sorry i dont have a git as i didnt have the time to put into learning the finer points of git or source revision stuff... Im a old school Linux guy whos been coding since the slackware days so im used to working with the source tars and just making my edits to them without worrying about revision control... not that im against it just was not something i bothered putting much time into...

    originally for Amlogic chips i started by looking at OpenElec and how it worked and used it as a learning point and then created my own toolchain and just develope in Linux... so unfortunately my sources are not setup for git...

    right now im still working on a skin for Krypton as my M8S's are moving off 16.1 up to Krypton now that its into beta stages... my intent when i get caught up was to look into maybe creating a M8S and X2 (Eny's S912 box) Project but thats going to take awhile as im short on time and would need to look into all the edits ive done to the Linux sources and create patches for OE or LE source tree... Im also trying to bring my A9's up to the more current 3.14 kernel tree thats being used for the newer A53 driven boxes as well...

    so unfortunately none of that is going to solve any or your immediate needs... i just kinda posted as i watch here and OE and noticed some chat about things not working on the M8S+ and was pretty sure its not really different then the M8S other then newer Android OS and thought id comment as i know the M8S box from Eny pretty well..

    on another note... i thought the Acemax units all had fully working firmware from Acemax for OE and LE... at least thats what Ken from Acemax/Maxtech was telling me over on Freaktab trying to get me to buy their boxes cause i had said i was intereested in moving away from Eny...

    hm... cant speak about the M8S+ as i strickly use the M8S but i will say for me to totally solve the power on/off funtions it was more then using the normal M8S remote.conf file... i had to solve it in the build and edit the amlogic drivers in the linux kernel prior to building the firmware... wifi/bluetooth issues should be solveable with patches to the m8m2_n200_2g.dtd and compiling with the proper drivers in the linux sources...

    i think part of the problem lies in theres so many hacked up versions of the linux sources regarding trying to keep folding in the more current amlogic drivers to the linux source trees that it gets confusing at times... over the years ive seen so many subtle dif's between the various kernel souces i long ago gave up and just concentrated on createing a source tree that worked with what hardware i was using and never bothered trying to keep up with the newer amlogic trees and incorporating them... really in truth unless your working with newer hardware thats not got proper drivers in the linux source tree then its worth the effort but i found once i had a working tree for the hardware i stopped trying to incorporate the newer amlogic crap and just concentrated on fixing the things i needed...

    its to bad Amlogic is not more forth right in making their Linux sources more accessable, cause trying to get anything from them is a waste of time... i had to source all my docs and software via the internet and underground sites which is kinda a shame for anyone trying to learn...

    Typically the M8S would use the meson8m2_n200_2G for the 2gig sram version... then you may need to correct for the wifi driver from within the build ...

    ive not used the LibreElec builds but they appear to be based on the OpenElec just with better publc support but either way you may need to allow some of the typical linux patches to make some corrections to the device tree to fix what ever issue you may have... most of the M8S's are the same ( including the clones) in most ways, its usually the ethernet and wifi that has issues from one board to the another... Ive used Enys exclusiively since the original M8S's awhile ago and even they have changed in wifi/bluetooth chipsets over the model line... Assuming LibreElec uses the same methodology in its build set as OpenElec did its best to use the existing sources and then apply patches in the patch directorys to make your changes rather then trying to edit the source files prior to building... if you must edit the source files its best to make your source edits and then recompress the file and adjust the md5 files that way your not fighting with the build system wiping out your changes all the time when you clean and build the editted packages...