i.MX6: Using kernel from Linus mainline instead of Freescale git

[ganesank]

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,

• Does Freescale/NXP kernel maintainer apply patches and test all branches of Linus mainline 3.14.y, 3.18.y, 4.1.y, 4.3.y, 4.4.y, ..... ? or is it expected (I doubt it) that it work automatically in all branches?
• When the i.MX Chip specific patches are submitted to mainline kernel? Is there are strategy?
• Are the patches submitted periodically? or what is the strategy?

Regards,

Ganesan. K

[sinanakman]

Hi Ganesan

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

kernel.

Again, this doesn't answer any of the 3 questions you asked

above but might give you another perspective on the choice

of kernel.

Hope this helps

Regards

Sinan Akman

[ganesank]

Thanks for the responses.

I understand that there are two aspects,

• Mainline kernel will be the most latest when it comes to patches and bug-fixes to the common kernel components such as file-system, driver frameworks, etc.. Freescale BSP branch might be lagging behind in those bug-fixes.
• Freescale BSP branch will be the latest in terms of bug-fixes and patches in chip specific drivers SDMA, IPU, VPU, GPU, etc.. This is very critical in the case of new SoC released by silicon vendor, for example i.MX6D+

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.

[timharvey]

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.

Regards,

Tim

[fabio_estevam]

Hi Tim,

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.

Regards,

Fabio Estevam

[gusarambula]

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:

FSL Community BSP

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.

[OtavioSalvador]

ganesank​ as gusarambula​ said there are some very important differences between both projects. I think you find the link[1] useful to help you in making a decision.

1. FSL Community BSP Release Notes 2.0 documentation

I hope it helps.     

[ganesank]

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.

[OtavioSalvador]

I am glad we provided you helpful information. Please get in touch with us if we can assist you in other things as well.

[gusarambula]

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!