Re: imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx?

Bas Mevissen

On 2021-02-26 10:36, Константин Еременок wrote:

Hi, there.
I see here a lot of specialists. Some qestions.
You are welcome, however:
1) Start a new topic for a new question
2) Do not top post to keep discussion threads readable

I'm not a specialist, but I think I can answer your questions.

1. What kernel (community or non-community) would you take for your own board (not NXP, not O.S.)?
IMHO, community unless quickly testing out something or when the community kernel is not sufficient (performance, specific hw support,...).

2. I took the branch origin/imx_4.14.98_2.0.0_ga. Is it a community supported branch?
From That is not community, but NXP.



чт, 25 февр. 2021 г. в 17:00, Andrey Zhizhikin <andrey.z@...>:

On Thu, Feb 25, 2021 at 2:22 PM Bas Mevissen <abuse@...> wrote:
On 2021-02-25 14:04, Andrey Zhizhikin wrote:
On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@...>
On 2021-02-25 13:32, Andrey Zhizhikin wrote:
Hello Bas,
On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...>
On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
to support the imx hardware video processing features. I have built
a distro with both linux-fslc-imx and limux-imx kernels (I think!) for
the Wandboard, which boots and runs but the HDMI display was not
functional. I will persevere looking at that.
No, you don't. You can use linux-fslc (mainline) and fslc-* distros as
i.MX6 has full mainline support. At O.S. Systems we have been using
Linux mainline with many customers with great success.
Wouldn't make sense to first evaluate the performance of the platform
(as Terry plans to do) first on an NXP fsl-* distro? In that case one
can get direct support from NXP if required. After that, derive your
distro from fslc-*.
This might not be quite indicative, as the NXP kernel might have some
"shortcuts" to boost performance in certain areas, sacrificing
conformance of the source code.
At least you get an idea of what the HW platform can do.

You might experience the situation that video performs quite well, but
then after opting for NXP kernel - you might find that some other
areas are not working as expected (some other domains). This would put
you in a situation that you've already committed to choose and deploy
the NXP-based BSP and would leave you to solve the issues in those
domains on your own efforts.
This is my pure speculation here, so take it with a grain of salt
though. :)
IMHO, you should never base your *product* on FSL. It is (at least,
is what was told me by (then) Freescale field engineers) only there to
demonstrate the platform. Maybe that has changed over time.
That is exactly what I implied, below statement is about that.
Ok, I missed that obviously.

When there is a huge performance difference between fsl and fslc, it
needs to be resolved.
By whom? This would lead to a situation that community does not take
responsibility for NXP and visa-versa. In this case - I have a bad
feeling that the engineering team in the company that decided to use
one flavor or another would be dealing with this fact. And this is
what I've also described as potential outcome.
It is actually that interaction between the community and NXP that has
brought i.MX support at the level it has. So if a performance problem
might pop up, it is that same combination that can and will work
together to get it resolved. It is to the company/person who found the
issue to bring it up (here) and not to resolve it as that requires
capabilities that are not so widespread.
In ideal situation - that would be a way to go. But in this case I
would expect that all patches that are present in NXP kernel tree are
posted upstream, so there would be no deviation and hence - no
performance differences between NXP and upstream kernels.
Of course, the problem when found - can be reported, but (a) I do not
believe that this list is a proper destination for such issues, as it
discuss the OE and not kernel-specific performance issues; and (b)
regressions can come from any side (NXP or upstream), which makes it
harder to bisect which side to be looked at.
I'm not saying that this is an impossible thing to solve, but in
reality the vast majority of efforts to solve those issues are landing
up at the side of those persons who've discovered them in the first
This is all my point of view on the subject, and might deviate on a
case-by-case basis.

IMHO, this should be considered and before the final product receives
commitment to use either of BSP flavors - all areas should be
validated, not only the performance aspects of Multimedia domain.
Yes, when you have decided on the hardware to use. If you are
the hardware to see whether it meets your requirements, you might want
to take the option that gives you the best impression of the
that can be achieved without too much of a hassle.
(it is an important step to do, at a stage of the development where
is usually very limited, so you want a quick but reliable result).
Correct, fully agree here.

BTW Would stable kernel work as well on i.MX6 if you need
graphics and video? I used it successfully for headless IOT
As Fabio already indicated - this is possible.
Fabio said "mainline". I'm not sure whether meant linux-fslc (as
used it) or
In this sense, linux-fslc *is* de-facto the kernel provided from It has a handful of patched that are not in upstream:
$ git log --no-merges --oneline stable-git/linux-5.10.y..5.10.x+fslc
2b929f3dcf6c media: coda: Change firmware probing order
dacfb877023a ARM: imx: add smp support for imx7d
10c7ebc67e34 drivers, misc: add U-Boot bootcount driver
67ea92db430f fec: Add disable_giga parameter to force 10/100 operation
bc552ba32d60 MA-7633-2 [Android-Reboot]reboot to fastboot\recovery mode
695186a85a0d ARM: imx: add cpu_is_imx6() routine

So I wanted to check that.
And that worked out brilliantly :-)
(thanks, see my response to Fabio on the same subject as well)


Join to automatically receive all group messages.