As an aside, the kernel mentioned in the last post will probably be our last release on the .31 series. The Linux kernel maintainers no longer really care about it, and even Freescale have moved on. We considered it important, however, to actually fix bugs where they stand rather than dragging users through new kernels unecessarily.
Here is our current kernel roadmap after the release of 2.6.31.14.20 (current schedule: Friday 25th February 2011).
2.6.35.11 (longterm support)We need to support the 2.6.35 series while Freescale uses it as the basis for their BSP releases. This is mainly because while a lot of support for the platform is going into mainline as I type this, it is not comprehensive enough to adequately support customers or the multimedia features we require (case in point, the Flash player).
Since 2.6.35.11 and forwards will be long term supported by the Linux Foundation and maintained by distributions, and because it is the basis of the Ubuntu 10.10 (Maverick) distribution in particular, it makes sense to move all our improvements and drivers to 2.6.35.11 and forward, so we can maintain support for the BSP components required.
2.6.35.x will be maintained for customers and internal testing, and for the MX51 platform, but we will probably only make very minimal number of releases before it is "dropped" for mainline. This will mostly depend on where Freescale go with their kernel support (a potential 2.6.38/2.6.39 BSP pending at some unknown date). Whether we engage in this kernel version for MX53 is still a decision to be made. We will, however, keep supporting TO2 boards.
Development on 2.6.35 will start next weekend (Saturday 26th February 2011), or sooner :)
Mainline (2.6.38 or 2.6.39)Using the sterling work of Sascha Hauer and other developers (hi Arnaud, Amit!) there is now support for the vast majority of the Efika MX platform requirements - Smarttop and Smartbook can be built using Sascha's imx development tree and some patches from Arnaud Patard. However it does not support some important features mentioned above, which makes shipping it a difficult decision. We do want to support this kernel, and we do want to support Linaro in getting our platform into the standard Linaro tree, since Ubuntu and other distributions will soon start using it as a basis for ARM platform support.
We will work with mainline (Sascha etc.) and real mainline (Linus, GregKH etc.) to bring in the improvements we need to get the best platform support for ARM Smartbooks and other devices as we possibly can. This will happen immediately after we release our first .35 kernel, and how well this work goes will determine how quickly we drop support for .35.
We are already picking around these trees and have booting kernels on Gentoo (good work, Steve). Any releases we make will be for DEVELOPMENT AND TESTING PURPOSES ONLY. We will not ship it on any installer or product by default, but just so we can keep everyone inline with the development track as we move forward.
Major feature additions required for shipping (not conclusive):
- i.MX51/53 VPU support in kernel (and userspace libva support for the decoder/encoders). This will also include getting JPEG decoding done in the VPU, since this is actually possible up to a certain size limitation.
- i.MX51/53 IPU support under DRM (GEM allocator, Connector/Encoder/CRTC)
- Vastly improved EDID support and parsing in the mainline kernel (even under DRM, the parsing is terrible, if they are to move all this into the kernel for KMS and take control away from Xorg, they have to do a better job. Saleem Abdulrasool is spearheading this for us, though, and he's done an excellent job so far..)
- i.MX51/53 GPU support - possibly a non-mainlined patch to add GSL with a DRM wrapper. Lots of licensing issues to deal with here.
- i.MX51/53 Security Engine support. This needs to be a kernel crypto/hashing driver and it needs to be able to be accessed via /dev/crypto so that OpenSSL and so on can adequately use it.
A lot of this will also require on userspace support for several very important features for the above (video decoding especially, PulseAudio and libc optimization for NEON, that kind of thing).
FutureThere's always room for improvement.. we have some proposals for research projects that developers may be interested in looking into, that nobody seems to have picked up yet:
- Can we adequately use NEON in the kernel* to
- speed up memory copies from userspace?
- speed up TCP/IP checksumming?
- speed up hashing?
- speed up RAID (XOR)?
- (requirements: ARM doesn't seem to have the use-FPU-in-kernel functions that PPC and x86 have to arbitrate access to this)
- Are there points in the kernel where ARMv7 architecture additions are not being used, or an algorithm or function is implemented as a core library function of the kernel (in lib/ or kernel/ in the root of the tree) where other platforms implement optimized versions?
- Silly things to look at might be things like popcnt.
- Do these functions get used enough that they would produce a noticable speed improvement to make the work worthwhile?
* footnote: Freescale did write patches for 2.4.x kernels back in the day, for AltiVec support at least a couple of these things (see libmotovec). Other developers pushed AltiVec and SSE support in the kernel for RAID management, so kernel support of these units does happen on some platforms. NEON is helped in this matter by having the same exception-less design as AltiVec and SSE (and AVX) which means you won't be causing kernel panics for "unhandled FPU exceptions" (as would be the case with a traditional FPU. As a side note, VFPv3 can run exception-less too, so that is also an opportunity..)
