I would really like to know why Amlogic along with the SBC manufacturers do not release their products with minimal mainline support.
Currently VIm4 uses an old kernel 5.4.125 but in LTS version
We also discussed that there is no idea when Vim4/MesonT7 will be in the mainline kernel, not even if someone is working on a port. Which would not have to be done since amlogic would have to give direct support.
Why do users/clients have to depend on consultants like BayLibre? eye, I’m not saying they do a bad job or I mess with them, I greatly admire their efforts and perseverance. But it would have to be Amlogic itself
If the new socs were supported directly on the mainline, we would almost always have the best specs, for example the performance of the Mali G52 MP8 2000MHz with private blobs, which right now performs less than a G52 MP6 1600MHz and also has worse graphics support , which is really unfortunate because it means two things: Either that ARM don’t think about their blobs or that they work poorly with their own hardware optimizations
Why buy a product that you don’t know from the outset if it will be on the mainline (long useful life and good support) and there is no estimated date for support?
Why buy a product only when it is already on mainline (possibly old product or replaced by a newer one)
Why buy a product that is only supported by the vendor with an old kernel and poorly performing drivers+blobs?
What is gained by sacrificing everything for an older 5.4.125 kernel with little upstream compatibility and no views of support for it?
Why use a 5.4.125 when already in main they are going to go for 5.20?
Thank you very much for your time and sorry for some questions
A couple more years and many SoC chip makers will be changing their song. USA is working on building chips and the government has just handed the chip makers a huge pile of money. So the ones that have been very arrogant over the years will have to up their game if they don’t want to lose market share.
I really like Khadas and was hoping they would have used a different SoC chip builder too… Maybe the next one,
I am currently using Gentoo on my N2 on 5.19.0+ with Panfrost OpenSource and the performance is spectacular the work behind Panfrost and the DRM Meson OpenSource(by Neil) is huge. That’s why it bothers me what Amlogic has done instead of taking advantage of those diamonds and boosting them simply go their own way. I can compare between Panfrost and MaliBlob Bifrost on G52. S922X G52-MP6 Panfrost VS A311D2 G52-MP8 Bifrost. In pure performance tests like glmark2-es2-wayland, G52-MP8 scores better thanks to those +MP2s, but the lack of compatibility and optimization outside of that use case kills it. Chromium is broken really I am missing full HW ACC without Vulkan Backend. Gnome has worse performance. Incompatibility outside of ES GL. Could all this be avoided? Yes. Panfrost and we would have the raw performance of MP8 with the best optimizations. This already in 2022 destroys… that we continue with driver fights and lack of direct support.
Glad that is working out for you. Its too bad so few boards like the N2 don’t support NVMe drives like the Khadas boards. If a board does not have NVMe drive support its not really any thing special.
We did have a product in a cabinet and doing final testing then find out the VIM1 is no longer available…Learned our lesson on that, so a guaranteed EoL is very important too.
@Jart25 This is a brand new chip, and the Mainline does not have any related chip patches, so Amlogic needs to provide a large number of this chip. which takes a certain amount of time.
Thanks for your response @Frank So can we expect to have VIM4 on MainLine?
even if not in the short term?
Why is Amlogic using such an old version of the lts kernel and not based on a 5.10 perhaps?
@Frank Why haven’t they released it directly on MainLine? they would save work, so they would not have to provide the code later, since they are working directly upstream
They need a stable release, every vendor is like that. The mainline is unstable. For them, a stable version is very important, so after a version is selected, it will not change. The support of the mainline will take a certain amount of time, and there is no clear time node at present.
@Frank They use a version of the lts kernel that has already been worked on and they don’t have to update since the hardware is closed, right? I mean, you can’t change the Ethernet or Wifi chipset, you can’t change the GPU either, it is given by the concept of SOC. I also see that many meson apis that are used in 5.4 are already broken in 5.8 so the code has to be rewritten…why do kernel devs break apis so much? it would be much easier to bring the socs to new lts versions of the kernel if they didn’t break them every 2x3
Amlogic designs media oriented SoC products for it’s primary customers; high-volume manufacturers of Set-Top Boxes running Android or RDK, and TV’s using custom media code on the SDK, and Smart Speaker devices using Android, Fuscia, or the SDK. The SDK is oriented to that audience and while their development approach doesn’t always result in the prettiest SDK code, the SDK does what it’s supposed to do. We should note that most of their high-volume customers prefer closed-source and strong rights-management so having less open code in circulation is often seen as a positive attribute and there is always pressure from those customers on their suppliers to be more-secure or more locked-down (and more NDAs etc.) to mitigate IP risks.
The BIG challenge with A311D2 is, unlike A311D or S905X3 etc. the chip is not a minor evolution of a previous generation - it’s the first of a new generation. It has new HDMI, new USB, new GPU etc. which minimise code inheritance and the ease of adding anything onto the current upstream codebase. It also has a u-boot boot environment with some firmware practices that are unfriendly to FOSS needs (but great for media customers that want a locked-down software environment).
TL/DR; We might like their chips for having a nice combination of performance, features and cost, but we are not Amlogic’s primary audience - so they aren’t investing $milllions of man hours in effort on upstream Linux support. If support ever comes, like the existing support (which has taken years and $$ man-hours) it will come from “the community” (cheap, but very slow) and/or corporate interests funding specific driver development (not cheap, but faster). However right now the historical interested parties (notably Google) are still using chips which are largely derivatives of older chip designs so they aren’t funding development (on newer chips they don’t use).
As pesimistic as this ^ reads, most SoC manufacturers are variations on the same theme so there isn’t one that really shines and many make Amlogic’s look awesome. The only two that stand-out for me are MediaTek who have clearly embraced upstream Linux for their next generations of product, and the Raspberry Pi Foundation whose hardware is intentionally a compromise and never “best in class”, but shipping with strong software support.
Thank you very much @chewitt as always my respects, after reading you and seeing the panorama so uncertain I have decided to return my VIM4, it is a pity, but I really want an arm64 sbc in upstream whose socs manufacturer really wants an arm64 desktop generation. Today, as you say, Amlogic is of the best value for money, and if it weren’t for the community and baylibre, right now they would only run Android, in obsolete versions and with a lousy kernel.
I’ve already seen the Uboot theme… unfortunate
The https://linux-meson.com/ project was quite a challenge and many hours of work have been thrown away in the new generations of soc, it is as if amlogic really did not want to give good support to linux desktop, that of hours that Neil worked with the DRM…the hours that community volunteers put in, to get them to throw it all away.
Now to start everything from 0? Linux Meson has taken almost 6 years to become what it is today. Starting practically from 0 or even from 20% would be a betrayal of the community. Another very different thing is that Amlogic had adapted its code directly upstream. But as you say this is almost impossible for them to do it by themselves.
You have to think twice before supporting these socs… it seems that if private Bifrost and medium Wayland work today, everything is fine, but as always everything evolves, if it weren’t for panfrost Odroid N2 would be with the obsolete mali blobs. It would be stuck in a drawer as it would happen to VIM4 in 1-2 years, or as long as it takes to break mesa and wayland again due to its own evolution.
I know your time is literally gold, but could you answer these questions for me as a senior dev? Thank you very much
Why buy a product that you don’t know from the outset if it will be on the mainline (long useful life and good support) and there is no estimated date for support?
Why buy a product only when it is already on mainline (possibly old product or replaced by a newer one)
Why buy a product that is only supported by the vendor with an old kernel and poorly performing drivers+blobs?
What is gained by sacrificing everything for an older 5.4.125 kernel with little upstream compatibility and no views of support for it?
Why use a 5.4.125 when already in main they are going to go for 5.20?
As long as the SBC manufacturer provides good support for the SoC vendor BSP codebase and commits to a decent lifespan for the board, the vast majority of use-cases are possible today and the majority of customers are happy today. I don’t have deep visibilty on the money side of businesses like Khadas, HK, etc. but they all seem to be doing well and growing which is the result of boards sold and good support.
NB: If you pick Odroid N2 as an example; the blobs work as-well today as they did on product launch day - it’s only quite recently that panfrost has perhaps overtaken them in capabilities (several years since N2 launch). Time to market is $$ earned, so blobs will continue to have a role to play.
I would of course love full upstream support at product launch (and many customers would too) but that’s not realistic: a) because it takes time for software support to be contributed to the upstream kernel and this effort always starts after the product is shipped, b) someone needs to fund the work, and it requires a lot of man-hours (and deep pockets) to upstream code.
A311D2 is not a complete start from scratch as some of the core board peripherals are iterations on previous designs; the code challenge is that Amlogic “streamlined” their drivers by dropping all the code related to older generations in the 5.4 BSP, and since upstream cares about backwards compatibility that shortcut cannot be taken and the task is made a little harder. RK3588 has the same Valhal GPU and Collabora are already working on kernel/mesa support so at some point Amlogic should be able to leverage that. The USB and DRM IP is new and home-grown through, so it won’t be inherited from someone else’s work, and the vendor drivers need to be cleaned-up and submitted. USB probably isn’t too bad, but DRM will be a non-trivial effort.
All SBC boards require compromises. If you must have an upstream supported board, the compromise is that it’s an older board. If you must have a bleeding edge board, the compromise is using some kind of vendor BSP codebase developed in-secret before launch.
For example the 4.9 in 20.04 on the VIM3 is rock solid desktop/client. With a medical grade power supply our live test boards with NVMe are running strong. Only time they went down was a couple power outages and they are not on backup supplies.
