Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx?

["Bas Mevissen" <abuse@basmevissen.nl>]

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 
https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_4.14.98_2.0.0_ga? 
That is not community, but NXP.

Regards,

Bas.


> чт, 25 февр. 2021 г. в 17:00, Andrey Zhizhikin <andrey.z@gmail.com>:
> 
>> On Thu, Feb 25, 2021 at 2:22 PM Bas Mevissen <abuse@basmevissen.nl> 
>> wrote:
>>> 
>>> On 2021-02-25 14:04, Andrey Zhizhikin wrote:
>>>> On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@basmevissen.nl>
>>>> wrote:
>>>>> 
>>>>> On 2021-02-25 13:32, Andrey Zhizhikin wrote:
>>>>>> Hello Bas,
>>>>>> 
>>>>>> On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen 
>>>>>> <abuse@basmevissen.nl>
>>>>>> wrote:
>>>>>>> 
>>>>>>> On 2021-02-25 12:21, Otavio Salvador wrote:
>>>>>>> > Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
>>>>>>> > <terry@beam.ltd.uk> escreveu:
>>>>>>> >>  From what I am seeing I will have to use a NXP fsl-* based
>>>>>>> >> distribution
>>>>>>> >> to support the imx hardware video processing features. I have built
>>>>>>> >> such
>>>>>>> >> 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
>>>>>>> own
>>>>>>> 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,
>>>>> that
>>>>> 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
>> place.
>> 
>> 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
>>>>> evaluating
>>>>> the hardware to see whether it meets your requirements, you might 
>>>>> want
>>>>> to take the option that gives you the best impression of the
>>>>> performance
>>>>> that can be achieved without too much of a hassle.
>>>>> (it is an important step to do, at a stage of the development where
>>>>> time
>>>>> is usually very limited, so you want a quick but reliable result).
>>>> 
>>>> Correct, fully agree here.
>>>> 
>>>>> 
>>>>>>> 
>>>>>>> BTW Would kernel.org stable kernel work as well on i.MX6 if you 
>>>>>>> need
>>>>>>> graphics and video? I used it successfully for headless IOT
>>>>>>> applications.
>>>>>> 
>>>>>> As Fabio already indicated - this is possible.
>>>>>> 
>>>>> 
>>>>> Fabio said "mainline". I'm not sure whether meant linux-fslc (as
>>>>> Otavio
>>>>> used it) or kernel.org.
>>>> 
>>>> In this sense, linux-fslc *is* de-facto the kernel provided from
>>>> kernel.org. 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)
>>> 
>>>>>>> 
>>>>>>> Bas.
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Regards,
>>>>>> Andrey.
>>>>>> 
>>>>>> 
>>>> 
>>>> --
>>>> Regards,
>>>> Andrey.
>>> 
>>> Regards,
>>> 
>>> Bas.
>> 
>> --
>> Regards,
>> Andrey.
>> 
>>