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

  • 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?

    Edited once, last by dipswitch ().

  • In the last 24h panfrost scored it's first "all green" graphics test run on the T820 chip used in the S912 and there are now some Khadas VIM2 boards plumbed into the mesa CI lab to ensure continuous testing of future changes. We are also in the process of switching our Allwinner and Rockchip images over to panfrost. We also found a source for the Linux T820 blobs (albeit not a redistributable one) but with panfrost in a good state I'm no longer chasing the permission to release the files. I'm sure panfrost still has some bugs, but simply being able to real-time chat with developers who are friendly and keen to solve problems is .. the total opposite of using blobs. It's a one-way journey :)

  • 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!)

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

  • 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?

  • Amlogic's "Meson 8" platform (S802/805/812) shares a lot of IP with the GXBB (first generation S905) hardware so support in the mainline kernel is in reasonable shape (bootable and usable) apart from a lack of an HDMI driver which is fundamental for mediacentre use. One of the kernel maintainers Martin Blumenstingl continues to poke away at the Meson 8 codebase and (coincidentally) in the last week he got CVBS output working. As long as he continues his efforts I'm confident there will eventually be a Eureka! moment with HDMI that allows us to consider adding back support (and even if we don't do something official - for community images to exist) but until that happens LE 9.0 is the end of the line for those devices. Meson 6 (8726MX) support in the mainline kernel is almost non-existent and those devices are considered obsolete.

  • One of the kernel maintainers Martin Blumenstingl continues to poke away at the Meson 8 codebase and (coincidentally) in the last week he got CVBS output working. As long as he continues his efforts I'm confident there will eventually be a Eureka! moment

    I hope he doesn't lose courage with poking around to get hdmi working especially now we have lima in mainline. I still have the impression the S812 is more powerfull then the S905.

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

  • 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?

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

  • The issue is that all of these efforts are a constant game of catch up. Release of LE for Leia is already a year behind schedule and as I understand it has been effectively shelved. Drivers for dvb hardware are not been developed for mainline so a lot of peoples still useful hardware is been left in the dust.
    Meanwhile AMLogic marches on releasing ever more exotic fare leaving the Mainline efforts yet further behind. Since ARM and AMLogic have made no effort to cooperate with the Linux efforts it seems that if you want a viable box in the now then look elsewhere for your hardware or software.

    I admire the efforts been made despite this but feel its all a bit to little to late.

    Shoog

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

  • Grabbed a H96+ Pro 3/32 912 and while it works great for streaming video files over the network it suffers from the uboot issue of not being able to turn on via the remote. I have solved the problem by running it 24/7 but would advise against buying it as there are many other options that are also good and can boot up via remote fine.

  • To date, a reasonable option for the ratio of costs\the result is Ugoos x2pro 4\32 or cube 2\16 (2 GB of RAM is enough to play media content). This model has full support for all elements (including WiFi) on core 5. If you don't need built-in WIFI and need maximum performance, you can use the AM6 (with metal body and excellent passive cooling system). These models use the best Android firmware (with long-term support for updates), with support for universal multi-boot. This means that you can immediately and easily run any modern system (LE, Armbian, Manjaro etc.) from external media (including USB 3.0 with a speed faster than eMMC and no volume limit of up to several terabytes) and fully retains the ability to automatically update the standard firmware via OTA.

    I own RPi 3 with LiberELEC for Kodi but I want to upgrade it because it's a bit slow, stalled (too little RAM) and LAN is not GB.

    Having read the opinions of many of you, I think the best solution is to have RPi 4 with 2 or 4 GB an LibreELEC. Especially as there is likely to be a new kernel within a year.


    The Amlogic S912 is no faster than RPi 4. It supports VP9 codecs, but that codec has no broader application and is of little importance to the Kodi user. 4K is not sufficiently present, especially through Kodi. And these, in my opinion, are the only benefits of the Amlogic S912.

    I may be wrong, but it looks like the S912 and LibreELEC are not fully compatible for now - CoreELEC is reportedly unstable. LibreELEC (TV Headend and Recording Capability) can also be installed on RPi 4, for example a Raspbian buster that serves as a computer.

    If the Amlogic S912 worked seamlessly with LibreELEC, I would buy a TV box like this. The price is very reasonable.

    The Amlogic S922 TV box (Beelink) is more expensive than the RPi 4 and is just a LibreELEC tv box. It's 30% faster, which is interesting for playing games (code TV box). So it's far more reasonable to buy an S912 .... but LibreELEC