Yes, it happened! On 4th of May, Amlogic released their new Linux SDK which includes Kernel 3.14.29 (I’ll talk about it later), Buildroot 2016.02, U-Boot and kernel drivers for their 64bit STB and TV SoCs.
All mentioned can be found on their GPL download site.
What is new in that Linux SDK you might ask… well, nothing special. Just few new driver implementations for CEC, eMMC/NAND, lightly modified WiFi drivers code, commits to kernel tree (which was originally forked from Linaro 3.14 which can be seen from kernel sources available eg. on Hardkernel’s Odroid C2 GitHub), few new reference boards introduced and more bugs!
It is amazing how these things happen. Current GPL release of Amlogic kernel is as is. GPL releases are released as tarballs (no way you will get full git history).
I will be whining for one old issue Amlogic does have on all of it’s platforms and on all released (GPL and non-GPL) and one I struggled with today for 2-3 hours until I figured out why simple Linux tar command is crashing and not doing it’s job (Error in ‘tar’: double free or corruption) when passing simple arguments to it like:
tar --selinux --acls --xattrs -czf <destination_file> <what_to_compress>
That simple command worked perfectly on all kernels they released before latest one (tested on same Buildroot version and with same tar sources). That latest kernel is mixture of everything. There are some normal AOSP 3.14 patches and there are some backports (Amlogic engineering way) from (get this!) 4.3 kernel.
Now, normal way of debugging this error would be…. Do I have everything enabled in my configuration files (Buildroot 2016.02 and their GPL Kernel) so my tar command can read SELinux contexts, POSIX ACLs and extended attributes? After I double checked my configuration I started rebuilding whole system because well, maybe something went wrong. 2nd try… Same error.
Ok, I forgot to enable GDB but I can build it without rebuilding whole system so I did that. Running same tar with it’s attributes from debugger gives me hint. Kernel kills tar without much useful information.
Thinking about it for 5 minutes or so I remembered that in git history from non-gpl released kernel there are changes to security subsystem (SELinux to be exact).
Figuring that if I already spent that much time trying to fix issue I have, I’ll spend additional 15-20 minutes rebuilding kernel with SELinux completely disabled. And guess what…. It worked! Wtf?!
Ok, so that was it. Cleaning Buildroot configuration, modifying Kernel config not to build security subsystem, rebuilding whole thing and that issue can be closed (for now).
Second issue I mentioned earlier is really disappointing. Amlogic M8 series (S802, S805 and S812) and GXBaby (S905) in Android (I did not check older platforms like MX but I am pretty sure it is same) do have issue with online SD quality streams that are using adaptive bitrate (via application developed for world wide operator).
Not only that I reported that issue to one of Amlogic engineers but also to person who (is or was? Not sure there because he seems to ignore me for some time now) my contact in Amlogic multiple times, I offered them everything they need (VPN account, account to service provider that is providing that OTT service…) and…. I got one big NOTHING. Not even reply telling me that they are not interested in fixing that particular issue or that they just don’t care about it (it’s about manners Amlogic guys!).
I think it’s enough whining for today so I will write something I find very positive.
Guys behind site linux-meson.com are doing their best to bring Amlogic SoC support to mainline Kernel and U-Boot. More about it you can check on their site.
If there any comments or questions maybe, I will actually reply to them 🙂