We have been using the i.MX kernel from the following link. We use any stable _GA release for i.MX6. http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
In my understanding this is the standard procedure followed by most of the Freescale/NXP customers. But I am wondering whether it is possible to take the kernel from Linus mainline (http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/) knowing that Freescale/NXP submits patches to the mainline eventually.
Can anyone provide clarity on the following,
This doesn't really answer any of your questions but I just wanted
to let you know that we primarily use only mainline kernel in all
our projects. BSPs are useful to see an (early) implementation
of a specific feature but a BSP kernel might have many bugs that
are already fixed in mainline kernel. As gusarambula points out
there are several NXP and other developers who contribute
patches to mainline and some of them based on an implemetation
in a vendor specific BSP kernel. I guess as gusarambula
suggests a BSP kernel would be safer to refer to for a sepecific
feature as it is documented on each release notes but in the
long run we find it much more advantageous to use mainline
Again, this doesn't answer any of the 3 questions you asked
above but might give you another perspective on the choice
Hope this helps
Thanks for the responses.
I understand that there are two aspects,
I am wondering whether there is any common meeting point to minimize our efforts in looking for latest bug-fixes. One of the requirements in medical device development is to analyze defects and bug-fixes of the open source components used in the product before and after the product is launched.
Any official opinion from Freescale/NXP would be helpful.
Hello Ganesan K,
While the community yocto release does provide a kernel option that uses a mainline kernel (currently linux-flsc_4.4) it contains very little additions that cover what is missing from mainline with regards to i.MX6.
Here is the list of what I know of is missing in mainline linux for i.MX6 as of the latest 4.4 kernel:
- lack of a CSI capture driver (there has been some activity on this and I'm hoping to see this hitting mainline in the 4.6 timeframe)
- lack of a Vivante GPU driver (the 'etnaviv' reverse-engineered GPU driver will appear however in 4.5 which will release within weeks but note that there is no gstreamer support for this to my knowledge and I'm unclear what patches are needed for things like X11/Wayland/Weston)
- some display output features such as dual-display (the Freescale downstream kernel allows independent and/or mirrored display on any of the 4 possible output paths for the i.MX6 where-as the mainline kernel just allows one output path to my knowledge)
- uncertain of VPU support status: The mainline kernel 'coda' VPU driver has supported i.MX6 for some time but there is not a lot of information available on how to use this for i.MX6 and the fact that there is no gstreamer support for coda/i.MX6 is also an issue. I hope to see the opensource Gstreamer-imx project support coda and etanviv support soon but work has not started there.
- Note that crypto support for i.MX6 made it into the 4.3 kernel which was a long time coming
I generally consider the mainline kernel of much higher quality than the downstream Freescale kernel as it is heavily code reviewed and the bar is set much higher on the quality of code submissions than what I've seen from the Freescale patches in their kernel. Many of the features that appeared in the early Freescale kernel for i.MX6 have already been cleaned up and mainlined. The latest Freescale downstream kernel is at 3.14 although they have backported many patches up to around 3.18 for drivers such as the PCIe host, and the FEC network controller.
I have tested mainline Gstreamer with the coda driver and it works out of the box. The issue when I tested was that the performance was not good due to the lack of IPU resize/colorspace conversion support in the mainline kernel.
As soon as we have CSC/resize support in the kernel, then we should be able to achieve decent performance with mainline Gstreamer + coda.
Hello Ganesan K,
There are two NXP BSPs available. One is the BSP release which is a static commit and it’s supported by NXP; the other is a BSP supported by the community and part of the Yocto Project. Perhaps you may find that the Community BSP better suits your needs as it would be a balance between the fixed BSP and the Mainline kernel in terms of updates. There is information on that BSP on the link below:
Perhaps OtavioSalvador can comment a bit more on the Community BSP for a project that requires to have bug fixing as up to date as possible.
Thanks for all the clarifications.
I joined Healthcare industry from semiconductor industry having worked with mostly mobile, consumer and automotive infotainment customers. It was easier in those industries to use open source software including Linux kernel. Once software is locked to particular version of kernel and other open source packages it is just matter of doing verification and validation against requirements and supported use-cases. There are not much worries about keeping track of functional bug-fixes and security patches to open source packages. It was more like apply a new bug-fix only when it is reported by customers or it is a serious security vulnerability. But in healthcare industry, FDA has clear guidance on what needs to be done for any off-the-shelf and open source software which includes defining a strategy and complying to that strategy to perform anomaly analysis of defects in the open source software used in the product. Anomaly analysis has to be done before verification start and then periodically once product is released . If a reported defect is relevant to the functional use-cases of medical device then the manufacturer is expected to incorporate those bug-fixes and release new software for future manufacturing and update all devices of existing customers as well. The same is the case with security vulnerabilities.
The whole procedure of SOUP (Software of Unknown Pedigree/Provenance) analysis and strategy was not tricky when we used X86 architecture with Linux. We used to do anomaly analysis with reference to Linus mainline. It was very confusing for Freescale/NXP i.MX6 based solutions for reasons like, NXP lags behind Linus mainline, not all NXP's bug-fixes/patches are merged to Linus mainline and not all the security fixes from upstream Linux are back-ported to Freescale mainline. Now I am convinced that it is better to use Yocto BSP which bridges NXP and Linus mainlines. It would be much easier to perform anomaly and vulnerability analysis with reference to Yocto BSP. Thanks to OtavioSalvador and gusarambula for providing right guidance.
Hello Ganesan K,
NXP does not implement their Board Support Packages to all Kernel versions. Each BSP release supports a specific Kernel version. BSPs are updated for current products but there is no fix periodicity on this.
The patches for the BSP are never released officially to mainline kernel although some are submitted by external efforts as they can be useful. However, patches are version specific so you should not expect them to work in kernel versions different from those in which the patches were intended to work. (Some people tweak the patches tough, but I would recommend using the supported kernel versions).
I would strongly suggest using the BSP Kernel versions available as these are tested for the supported processors on the BSP Release Notes.
I hope this information helps!