LibreELEC (Leia) v8.95.2 BETA

  • looks like they are making some good headway and making things more usable but "full media support" i think is still aways off. from what ive been reading trying to play catch up is mainline kernel support is getting much better but theres still a quite a bit of hardware support still missing and the level of trying to reverse engineer the userspace code is still going on.

    on another note: as I am gathering source code and information trying to come up to speed on the subject of getting Amlogic support into the main stream kernel i keep seeing or reading about this idea of Amlogic and Baylibre having formed some type of relationship making Baylibre responsible for Amlogics linux development and support which makes me wonder why anyone would have to reverse engineer anything as Amlogic could simply supply the required information. Even if there was a licencing problem between Amlogic and Arm over binaries and Amlogic making that availble to someone like Baylibre theres no reason why Amlogic cant release the technical specs on the SoC as that Amlogics stuff. Having the full docs and reference design materials would drastically speed up the development of open source common parts.

    anyways still reading and gleaning just something that makes me wonder as i catchup

  • For what it's worth the old issue of the `current` Nvidia driver in Generic build hanging the machine when entering suspend is also present in Leia v8.95.2 Beta (the workaround of forcing the ancient legacy driver still functions)

    Issue thread here: - v8.0.0: Device crashes when entering suspended mode (nVidia driver issue)

    From the sound of things it's an Nvidia binaries problem rather than any LibreELEC derived issue, but fingers crossed someone will take a look and see if there's any progress on the Nvidia end before the v9 goes final ? ;)

  • Assumptions about availability of Amlogic documentation and how various relationships inter-relate aren't correct, but that's understandable as there are layers within layers and it's not a straightforward topic. Baylibre are an independent (kernel focussed) software development company. Amlogic has subcontracted development tasks to Baylibre in the past, e.g. core board support for the AXG platform used in smart speakers. LibreComputer also outsources a range of development and support tasks to Baylibre which is awesome because the quality of work is high and it's been done in a way that benefits the entire Amlogic ecosystem not just LibreComputers own products. Several of the Baylibre team are kernel maintainers so they are not Amlogic's Linux support team, but they are involved in whatever action is happening. IMHO Amlogic have been quite supportive considering Linux is not their primary OS interest and we are not their customer. As with most large commercial organisations you need to understand their business model and be talking to the right people and asking the right questions to get the right response.

    LibreComputer claiming "full media support" with 4.19 is over-reaching. The status quo continues to improve but there are still major items to check off the list and users testing mainline kernel images will quickly discover missing capabilities. Amlogic users tend to have high expectations so we aren't going to commence significant public testing until we reach a "feature complete" state and are ready to switch focus to bug-fixing.

  • For what it's worth the old issue of the `current` Nvidia driver in Generic build hanging the machine when entering suspend is also present in Leia v8.95.2 Beta (the workaround of forcing the ancient legacy driver still functions)

    I think we will have removed nvidia support from our codebase before the suspend issues (which go back to OE days) will ever be resolved.

  • That may be somewhat true but sources involved have also been privately said the budget money paid by Amlogic to Baylibre was exhausted and its only because of the personal interest of a couple of the people involved that things are somewhat moving but not really with the type of help and support Amlogic could bring to bear if they so desired. And i agree that maybe back 3 years or so Amlogic's or even Rockchps interest in Linux was not of any real interest but these days neither one of those billion dollar empires are dumb enough now to ignore the impact linux is having and is going to continue having in moving forward with what they currently are selling and the new things they are about to bring to market so honestly lets not put Amlogic up on the being helpful pedestal with vague and half-truths... I spend most of my engineering career reverse engineering and developing secure platform devices and testing and understand the whole concepts involved in fab level and software development and understand pretty well the whole development cycle and no matter how you cut it , Amlogic really has spent not much more then whats pocket change and other things when the reality is it was only Amlogic's choice in the wafer and SoC hardware and the ip cores they decided to licence and its pretty crappy to push onto the public a product thats real only benefits are routed in firmware they for whatever reason just dumped on the market to maintain the release of new products to keep the growing market share...

    This really would be no different then if the big Auto makers decided to make cars without providing any downstream support in how to maintain or fix the motor or something. I mean does GM, FORD or CHRYSLER make it so your car cant be fixed because you decided to buy the repair parts from some 3rd party parts maker. I don't think so.

    Don't get me wrong as i realize that there are a LOT of great people that want to help and are doing their best to do so but everytime i see someone trying to blow sunshine about Amlogic actually helping just gets me going. I know pretty much what docs they provided as all of its been leaked and if you know where to go it can be found and if Amlogic truly was trying to help why did they make it be like that. And even if they actually are why does it continue to be behind basically closed doors from the public. Honestly there is probably MORE coders with Linux experience in these areas that could be tapped into as they are actually LINUX people and know how to fix the stuff if they had the materials.

    Rockchip at least to have seen the light and my quess is someplace down the road they will come to dominate as Amlogic continues to be this anal about things, and as speaking as someone that could put some serious help forward along with some others its this behaviour that makes us not willing to even give up the scripts that would at least bring the S812' and S9xx up to a unified kernel based on their own 4.9

    So be clear and honest lets just admit Amlogic is stone walling while they wait and depend on the public to fix what they will end up using in the future. Rockchip really is the way to go at this point as they deserve the public help and i am truly glad to see a few talented people start to work torwards that.

  • Enthusiasm for RK is understandable from anyone who's spent time in the Amlogic trenches, but in our experience switching from one SoC vendor to another doesn't solve development problems. It only results in different development problems :)

  • Enthusiasm for RK is understandable from anyone who's spent time in the Amlogic trenches, but in our experience switching from one SoC vendor to another doesn't solve development problems. It only results in different development problems :)

    from your point i agree as i realize your trying to support a pretty diverse set of SoC's and their associated platforms which is really tough for any single person or group of people, but in the environment you have created here your tapping into some pretty good people willing to give up their time to put their skills to good use.

    from my perspective i know how hard it was to unify the S812's and most of the current S9xx boxes on amlogic's own linux branch and then deal with writing working drivers for the missing parts for the S912's. All things considered though if they would have simply provided the same type of docs that i now see Rockchip openly providing pretty much everything people are working towards would be done. it took about 6 months of dumping running code from a S912 and using a program like IdaPro to create and model the actual S912 SoC in software and from there it was a couple months writing working drivers while not messing with anyones proprietary code, thank god we still live in a world where totally dismantling someone else product for learning reasons is legal as long as your not pilfering from the protected software. As hard as it was we only worked on a couple of specific boxes which was easier then what you guys are trying to do. i am currently already into the T860 code i see posted on the various githubs and once i lay my hands on a decent test board i am going to see how much of the existing T820 code i have will migrate up... i suspect a lot will but i am not sure of any differences between Amlogic which is where we worked and the current Rockchip and how each implement things.. things like symbol names and other things which if not provided by the SoC maker may be different. thats why its good to have a board running test code while using things like Jtag to watch and record things...

    anyways once again i digress , but your right as Rockchp has at least restored some of my skepticism in any of the manufacturers.