Choosing a S905 / S905X / S905D / S905W / S912 box guide

    • Official Post

    S912 is now working on mainline linux kernels using the "panfrost" open-source alternative to the non-existent ARM mali blob and balbes150 has a testing image available via his K18 release thread for the curious to look at. Panfrost is still under fluid development and it's not stable enough for real-world use yet; there are memory leaks so you can play video but navigating around in the GUI eventually triggers OOM crashes. It's making rapid progress though, and is attracting lots of known names from the Linux graphics community who are helping to move things forwards (even ARM's open-source group are engaged) so in the next couple of months we should reach a point where issues are resolved or reduced enough for proper public testing to start.

    Quote from wrxtasy

    High Bitrate 4K HDR Rips with 5.1/7.1 lossless HD audio need a device with Gigabit Ethernet.

    Options:

    1) Add a Realtek or ASIX Chipset - USB3 > Gigabit Ethernet adapter to 100Mbit only Ethernet boxes, some even come with USB Hubs like the Ugreen ones.

    2) Get either a S912 or S905D AML box - make sure it is Gigabit Ethernet equipped aka 1000M

    But only what I need is to open movies from mkv/m2ts files. Not streaming. I don't need gigabit ethernet

    Quote from chewitt

    S912 is now working on mainline linux kernels using the "panfrost" open-source alternative to the non-existent ARM mali blob and balbes150 has a testing image available via his K18 release thread for the curious to look at. Panfrost is still under fluid development and it's not stable enough for real-world use yet; there are memory leaks so you can play video but navigating around in the GUI eventually triggers OOM crashes. It's making rapid progress though, and is attracting lots of known names from the Linux graphics community who are helping to move things forwards (even ARM's open-source group are engaged) so in the next couple of months we should reach a point where issues are resolved or reduced enough for proper public testing to start.

    It is beyond my comprehension how one would be able to develop an opensource linux gpu driver. Is this all done without cooperation from ARM? As i try to imagine, one should need some tech docs, documentation to start "writing" the code? I keep being amazed how much hardcore programmers are still out there trying to achieve great things.

    Am i right to conclude that the current available LE images for s912 are all based on the android driver on lybhybris?

    And finally, if im not overwelcoming my stay :) , it's great to hear that s912 development on opensource gpu driver is on its way. I also read that rockchip LE , what years back was unimaginable, now is fully supported on rk3399 and rk3328. If i might ask chewitt , at this point in time, would you go the s912 route or choose the more powerfull rk3399 rock64pro solution?

    Re-edited this post again after some testing and tweaking on the RK3399 - developer board ODROID N1:

    It depends what priorities a user requires at this point in time for use with the very latest Kodi Leia nightly...

    Rockchip - RK3399:

    Limitations:

    - HDR is not fully supported, limited to only set EOTF in the HDMI infoframe metadata. See noggin 's explanation HERE

    - DD+ and DTS-HD MA/HRA, Dolby TrueHD audio passthrough not working, which means no Atmos as well.

    - HD audio decoded to 7.1 LPCM, which works well as a workaround.

    RK 3399 surprises:

    - 1080p 10bit h264 aka Hi10P Anime is hardware decoded

    - 1080p video playback is possible when using the Kodi Leia Netflix Addon

    Read the most up to date Rockhip discussion info over HERE

    Amlogic - S912 & S905(X/D):

    Limitations I can think of now when using the very latest nightly Leia (CoreELEC):

    - S905 only chipset will never have HDR support

    - HDR MaxFALL/MaxCLL metadata not yet send to HDR capable displays from the AML Linux Kernel.

    - Only 720p Max. video playback possible when using the Kodi Leia Netflix Addon

    - S912 LE / CE Kodi video playback stuttering when using external Subtitles (due to non optimal Libhybris <> Android GPU driver)

    - Workaround for that is disabling Kodi Dirty Regions in advancedsettings.xml (easily done.)

    I will let chewitt detail developments that will need to be ticked off for LE 10.x / Kodi v19 M going forward for both platforms...

    • Official Post
    Quote from dipswitch

    It is beyond my comprehension how one would be able to develop an opensource linux gpu driver. Is this all done without cooperation from ARM? As i try to imagine, one should need some tech docs, documentation to start "writing" the code? I keep being amazed how much hardcore programmers are still out there trying to achieve great things.

    Am i right to conclude that the current available LE images for s912 are all based on the android driver on lybhybris?

    And finally, if im not overwelcoming my stay :) , it's great to hear that s912 development on opensource gpu driver is on its way. I also read that rockchip LE , what years back was unimaginable, now is fully supported on rk3399 and rk3328. If i might ask chewitt , at this point in time, would you go the s912 route or choose the more powerfull rk3399 rock64pro solution?

    Panfrost is based on a combination of observational reverse engineering and mathematical theory. As I understand the story.. someone noticed that patents ARM filed for their midgard and bifrost designs resembled an earlier maths research paper and a hunch the two are connected has proven true; allowing code to be written against the concepts in the public and detailed paper instead of an obtuse patent filing (which can technically be struck-down or invalidated now the connection to independent prior-art is proven). It's all down to a little amount of luck and a huge amount of hard (brain and code) graft. Panfrost is quite an achievement :)

    99% of current S912 images from community developers are 3.14 + libhrybris. The lone developer blazing a trail on mainline S912 images with LE and Armbian is balbes150 .. but those are not ready for anything beyond a curious look at this stage. Panfrost is undergoing substantial code packaging changes at the moment and i'm not expecting progress on memleaks and other issues until the dust settles.

    At the moment I think S912 is the "least worst" option due to availability of current 3.14 images which still have some fugly bits but are functional. RK development is promising (and probably better technical chips in some areas) but the codebase still has some way to go before it stabilises on a mainline kernel while the Amlogic mainline codebase is already quite mature (aside from the critical GPU component). Amlogic also has a team of commercial developers working on related code for funded projects which I think will check items on the to-do list faster.

    Should add my tests were on Rock64 not RockPro64 - so are based on experience of the RK3328 not the RK3399.

    I'll test the RockPro64 next...

    **EDIT - RockPro64 seems to behave a little differently. Silence rather than static when playing bitstreamed HD audio - from 1080i sources - into the same AVR - but end result is neither play bistreamed HD stuff. I have only checked TV Blu-rays not movies so far... **EDIT 2 - 24p movies output at 1080p24 behave the same.

    Also h.264 50i Blu-Ray content seems to be a bit stuttery with the RK3399, I'd say - at first glance - the RK3328 on the Rock64 was doing better with this content

    Same HDR metadata issues observed as with the RK3328 Rock64. 1080i 50Hz native TV recordings are deinterlaced to 50p as per the Rock64 RK3328 and are entirely watchable at first glance (only a few minutes)

    Edited 3 times, last by noggin (February 2, 2019 at 4:01 PM).

    hi everybody,

    I would like to buy a box with S905X soc. But i need ethernet connection and optical output. Also I need to use it with libreelec or coreelec with sd card and I want the box to support auto frame rate switching so the 24p judder doesn't exists.

    Could you suggest me a cheap box with these functions?

    Thank you very much

    Its good to see someone finally started checking Arm-SoftBanks and a few other patents as your right in the similiarites of information and papers and there is more then just one once you realize were to look... Its extremely tedious routing through the US and European Patent Offices but there usually are pretty good clues to pretty much anyone that is either in the process or already granted a patent. Your almost guaranteed to find related information either directly from the Company's involved or the original authors, the university's as well are a great source because a lot of later things are based on dissertations or thesis's. Its a great way to start your information gleaning when your trying to reverse engineer something but in all likely hood its still going to take observing a running core to figure out how to write the proper garbage collection lines to help eliminate the memory leaks and other randomized issues.

    I have been compiling and playing with Panfrost and you are right in that it is extremely interesting and probably the best hope i currently see for public support of open drivers.

    • Official Post

    Lima submitted its kernel driver today. It's not the first submission but this time around it has a fairly distinguished list of "Signed-off-by" signatures on-board so I'm hopeful it goes into the 5.1 merge list and there's a date that I can drop one of the larger patch-sets. Panfrost also merged initial mesa stub support which will make mesa packaging easier from 19.1 onwards. All over the codebase we're starting to see lots of the jigsaw pieces slot into place although community development is often a frustratingly slow process. I'm confident that in the future we'll be able to release a single Amlogic image that supports GXBB + GXL + GXM devices, though that's a long-term goal (not in in this half of the year at least).

    ya i seen the mesa merge when i was reading over on Phoronix site last nite while following the Gallium3d stuff. Lima i have not really followed that much tho i am aware since you mentioned it awhile ago and the development being active again with a new group of dudes. Personally i just have to many other things going on but the Panfrost thing i am interested in following just to see how it goes (from a legal point) one of the reasons most of what myself and a couple of others have done have been outta the public over possible legal harassment, even tho it was all done based off research papers and info and nothing contained in a actual patent its just not worth the risk on our part as none of us are any type of dealer in this sport or having thing we were selling but i have been down this road before and being in Canada with stupid laws like Anton-Pillar make it way to easy for any corp to break you financially without ever even getting into actual litigaction. SoftBank and its holdings are just to big with IP so it will be interesting to see how this pans out but your right as its looking promising. :)

    • Official Post

    I'm not sure whether ARM's open-source group have been given the internal approval to submit code to Panfrost yet, but the request has been made and they're keen to start. Meanwhile a couple of ARM engineers are engaged with the Panfrost devs, testing code, and generally finding other ways to be useful. We (LE) are partly responsible for some of the those connections being made :)

    ya that would be really nice, at least that way then they would be in the same boat as some of the other graphix processor companies have with their stacks. Arm is a big company with a lot of branches but being mostly a IP based company that makes its bread and butter from licence fees so i am actually surprised that any still ARM employed guys are willing to go out on the edge like that. Company's like ARM that don't really do hardware much anymore usually ensure their revenue streams by strictly releasing binaries that are revision specific ensuring more revenue when the end user wants to step up in revisions (android would be a example). I know i have over the years talked to various factory guys about the issues and the feed back i always got was that if say Amlogic in this case wanted to pay the licence fees involved they could get ARM to create and release the blobs but Amlogic has no real interest in spending the kinda of money to do such a thing... Amlogic basically supplies a canned version of Android to the downstream factories and it comes with minimal support for the SoC they licenced it for which is one of the reasons its so hard to even update Android on some of the older boxes as they don't want to invest in the fees to include most of the backwards stuff as their interest is like most companies in strictly moving forward.

    I hope it works out because its really needed, but for me and some others we will sit to see where it actually goes.. personally i am 100% sure they can create whats needed. the real question for me is whether ARM will really allow it out in the open without trying to impede it. I think now is to early to see their real intent as they're not sure if the public can do it...lol. If they were more of a hardware based company then i would think somewhat differently but being IP based its kinda like letting the golden goose out for free if this happens. Personally i think it would still be a big benifit if it did but unfortunately its the pencil pushers and accountants that call a lot of the shots and not technical people like you or I and the others that frequent places like this. I would really like to help and get much more involved but i am gonna sit and bide my time for a bit yet to see.

    I have the concern that all this effort is in vain since the release schedule for AML GPU means that already the S905/S912 GPU's are old hat before an open source driver is available - and we already have a none supported GPU on the S905X2 and a release schedule which always stays well ahead of open source development.

    Supporting these chips with Open Source drivers is simply unsustainable.

    Shoog

    I agree as i don't think the efforts are in vain.. no matter what knowledge is the king in a pursuit like this as not many corporations toss out earlier r&d as most tend to build on top of earlier stuff until something totally new comes along. the main thing is to gain the knowledge to create the framework that can be kept up moving forward. pretty much a basic fundamental with the concept of linux.

    just as a note now that people are realizing the potential of the existing patents is to watch the long going battle with nvidia/ati and the companies they are accusing of various patent infringements. Arm's Mali product is named albeit not as one of the main defendants but more as a side player because they are basically just the ip provider... anyways the thing is this... nvidia/ati would'nt just pursue this for all these years over just nothing which means they would have had to enter exhibits into the complaint of the specifics of the infringement...

    all of the above is kinda irrelevant to the concerns here but those exhibits may be of interest when trying to build a framework... just a thought.

    Quote from flappy81

    Are there any noticeable performance or feature benefits in updating to LE 9.0.0?

    I'm currently running "8.2.3.-GUI-options" OC'ed on a C2.

    inputstream adaptive, drm, netflix and amazon vod support are the most important reasons for me. Finally a good way to watch netflix (1:1 pixelmapping, framerate switching, hq decoding, fast interface). LE 9 / Kodi 18 was for me the reason to finally get a netflix subscription. Just works out of the box, no need to tweak funky patches, just download a few add-ons and you're ready.