Posts by buzzmarshall

    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...