Posts by dipswitch

    Amlogic releases their BSP codebase which is the same awful code from 3.10 ported to 3.14 ported to 4.9 ported to 4.19 (in process) where each iteration focusses only on supporting their latest/greatest chipsets. Their technical focus on new devices frequently stomps on support for older devices so it's a long-term nightmare to support a wide range of devices with and you cannot take the latest buildroot release and use it with Meson 8. It's also fragile code which is a pain in the arse to maintain; fixing one problem constantly breaks something else. LE's strategy is to move all of our target hardware platforms onto mainline kernel to solve these issues; mainline provides a maintainable codebase that supports a broad range of hardware using well written drivers using modern kernel API frameworks. The root of the problems with the BSP drivers is they were written long before many of the upstream frameworks existed (or matured) so Amlogic evolved their own proprietary ones (with no external scrutiny, hence the many architectural and code quality issues). This means the BSP drivers don't fit modern kernels and writing from scratch is cleaner and usually easier than attempting to adapt them. The solution for Meson 8 is someone (Martin B unless anyone else starts contributing) writing a new HDMI driver that fits into the current kernel DRM (direct rendering manager) framework. There's been a lot of work in the last 18m on the dw-hdmi IP Amlogic used with GXBB and up (and common with Allwinner/Rockchip). Meson 8 uses different IP so it needs a different driver, but dw-hdmi provides strong guidance on what the structure of the missing driver needs to be like. I'm confident it will happen, but HDMI drivers are complex, there is limited documentation on the IP used (and the in-use BSP drivers frequently disagree with Amlogic's internal documentation) so it's a reverse engineering effort. Martin has been experimenting with HDMI code for a while now, but it's only quite recently that surrounding core board support was really in a stable enough or complete enough state to start making a serious effort. And I'm sure he has a life outside of poking Meson 8 code, so it won't be quick.

    Thank you for the explanation. It's great to read how so much effort is being put by so many people into te LE project, even keeping meson 8 up and running.


    I feel it's sad that soc builders like amlogic maintain their focus on android and stb use, not really putting real effort in suppporting their products for the opensource community. It seems, from an economic point of view, it is not in their interest to spend developing cost in that area.


    When i read this article:


    Irdeto Partners with Amlogic and Skyworth to Launch Platform Under Google Android TV Production-Ready Hybrid STB Reference Design Program - Irdeto


    it seems they got a goot deal. And to be fair, with having 500+ personnel on payroll, revenue is needed for the company to survive. They probably feel that investing in opensource wont give them enough profit. Well, seems the rasberry foundation is proving that things can be different.

    S812 has quite a bit more grunt than S905 but .. not much use without the HDMI driver. Fingers crossed..

    for me as a noob to get a bit of an idea of whats going on... is it the question if a driver for kernel 3.x can be used for a newer linux kernel? i dont have any linux development knowlegde.., you cant use a kernel driver for an older kernel on a newer kernel? and if this is the case, doesnt amlogic / arm release drivers for newer kernels? do we need the source for the drivers? does the driver source even exist in public domain?

    Panfrost does not currently support the Mali G31/52 (Bifrost) chips used in G12A/G12B/SM1 hardware and I don't see that changing for a while yet. It's not an issue though as we have all the required blobs and can use those; hence we are shipping two images (AMLGX with lima/panfrost and AMLG12 with blobs) which are working on a range of newer hardware. There are no plans to drop support for S905 and up devices but it is a large task and developers have proper jobs and families so progress comes as it comes; we're not forcing the schedule. We will push a master branch bump to Linux 5.4.x soon; although there are ongoing changes to the video decoding drivers that need corresponding changes to Kodi/ffmpeg so our master branch will not be as usable as Linux 5.2/5.3 was for a while.

    Great news! But wat a huge task. And to think that all this is being accomplished by volunteers coding in their spare time, awesome.


    Am i right to assume that s802 - s805 - s812 are being considered obsolete?

    Great to hear! Always enlightening to read your explanations, makes things a bit more understandable. Could the succesful development of panfrost mean that we possibly can expect future LE release on mainstream linux with support for s905x2 - s905x3 - s922 ? This all seems a huge task. Is there any prediction when all this magic will be reality?


    Will s905* will be supported in future LE releases? (still going strong, great soc!)

    it has been a while since i dropped in here asking this question, have been wondering how things are now..., if i might ask chewitt, status on the s912, last i can remember is that after it was being cursed upon for a long time a solution for the missing fbdev mail libraries was developed in using libhybris and android gralloc mali drivers. is this still the case? i seem to remember something about an opensource driver being developed for the s912, did that development succeed?I think this was called panfrost?

    Why would you even bother trying to run illegal addons? There has been so much work put in LE / Kodi to get genuine video services like amazon prime and netflix working, so much effort to get adaptive streaming and widevine running. you wanna waste all that effort with some shitty add-on?


    just get a decent supported device, dont be cheap and subscribe to your favourite streaming provider, and you're all set. you can even get something x86 with a bluray drive, buy second hand bluray's, then you've got yourself dirt cheap high quality content.

    Looks like Dell is blocking max. performance at firmware level. Maybe max. performance leads to heat problems, or whatever issues.

    The only "solution" I see is a firmware hack.

    That would make sense, because these 3040 boxes are really tiny. They fit in the palm of your hand. I already was wondering about the incredible small footprint these cherry trail units have. This was what attracted me to them in the first place. I can imagine that the current "normal" power setting is good enough for them to just do thin client tasks on a simple linux os. Nothing fancy there. Doing h264 30mbit 1080p decode is a whole other story. Could well be they burn on "perfomance" power mode, looking at how tiny they are.

    Ask Dell, they should know what they write on boot. I'm very sure the video stop comes from UEFI, not LE.

    I believe you! Problem is that these dell wyse 3040 boxes are being sold primarely as thinclients. Seems no one at dell is waiting for a guy asking about uefi settings. Even reimaging these devices is a pain in the ***, since they use some kind of deployment tool, with uefi pxe booting.

    That leaves me with almost no options; i was hoping i could get the box booting in csm legacy mode and run LE like that, but that also seems to easy to be true. CSM booting disappeared as soon as i enabled uefi booting and i'm searching for a way to get csm module enabled again.

    These cherry trail boxes, even a fancy dell wyse, keep giving me a headache!

    Set your energy preference back to "performance" at UEFI settings.

    This is a problem, i've searched the dell firmware back and over twice, there are no energy preference settings. I can set c-states, turbo b**st, and something else c-states (cant remember), but no performance settings.

    This is a weird problem: i have this Dell Wyse 3040 thin client, a great little device with dual displayport output. It runs stock linux, which can easily be replaced with another os. This is a cherry trail box, is has an atom x5-z8350 with native 64bit uefi firmware (yes, finally!).


    LE installs and runs great in 64bit uefi mode, no problem there. Now the only problem is: when playing back video, video runs for about 3 seconds and then freezes. I can revert back to menu (the frozen video reverts to background), and then i have to stop the stalled video manually. Combined with a flirc usb receiver this tiny box makes a really great LE device, so i'm hoping the video playback issue can be resolved.

    Do yourself a favour, throw away the 32bit efi crap devices. I had a couple of these devices, even a very expensive industrial grade device. If it doesnt work it doesnt work. 32bit efi is just a nasty way of crippling an otherwise perfectly fine 64bit cpu. A way for the industry to limit use of potentional usefull hardware to next to nothing.


    Especially the intel cherry trail devices often come with 32bit efi, those cheap little plastic chinese boxes with sub par cooling. My humble opinion: save a little more and get yourself something better, like intel n3700 or j5005 devices, from a well known brand (with decent cooling).

    would you mind sharing what is needed to get netflix working on kodi? Im sick of having to jump between my tv and the kodi setup

    Go to the Kodi forum -> video add-on section. There you will find the unofficial netflix repository stuff.Remember that all video decoding on linux is done in software, so you need more then a little device to get 1080p working (just found out myself. Runs great on my core i5 mediacenter. a low end atom x5 however...)

    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.

    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?

    I also have not read about development on s912 for a while . The last thing i read over about a year ago is that there was no descent driver and library for linux. How have things gone since then? What was said back then is that there was no libmali.so for the mali-t820 in the s912. efforts to get LE ported included using the android driver + library, which back then resulted in an generic "do-not-buy" advice for the s912. Is this still the case? Or has the appropriate driver and library become available? The advice used to be, when going the amlogic route, buy s905 duo to proper software support.

    given that your internal android is already overwritten, it does not hurt to run installtointernal again.

    It tried it twice. I can boot le fine from sd card, ssh into in, installtointernal, looks allright, no errors, but the box refuses to boot from internal flash. Also when i boot le from sd card and then choose reboot from internal (and remove the sd card), the screen just stays black.