From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by mx.groups.io with SMTP id smtpd.web12.7085.1614332209897957701 for ; Fri, 26 Feb 2021 01:36:50 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OANUAvsr; spf=pass (domain: gmail.com, ip: 209.85.167.42, mailfrom: eremenok.k.by@gmail.com) Received: by mail-lf1-f42.google.com with SMTP id d3so12874963lfg.10 for ; Fri, 26 Feb 2021 01:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KSHg9SCXBpD1JcxarZAybJaddNEsEWMZ1Fhp0Xp0YgI=; b=OANUAvsrqDoLqFU2R1PXD1p2cOsaK8h3ZZX4QJee++p18oifxtxxZvoGZv+/pmwQSj Gu1dxDdWLBg/VzDaLDL5GF0qvjXulkcvnmVn0RGawAKGmM4eBfsJT1rYoBQnL14eLc+z FkQi7btgohDcwR4FmdxSx7bx2jJuTCxbiN1+0pELujF/2971zQT24Zmq6m7pYvs6l5Nr SEGKpOhXK5vlZrhyqmlZG08gD6bWBm2+fM4qbTQwQeSZp5zPvEuuOOSCb6MFQDaM2b8h vF1zJMbYYsjxM1lRDkA5jCgkHkWqTJUSRfFb4WriA+DsYrrU9sDj5YBPgimxt0+TMRgD YVGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KSHg9SCXBpD1JcxarZAybJaddNEsEWMZ1Fhp0Xp0YgI=; b=DDqinkpapHr01XlnBYmB966K7Kbm+f/caz9RpjTGwWYRATcCaPlsN/end/UfZIvDH0 WWpxC8h6ewkqbVAPZT5EGxJIG0NEwQssmZUc7VMN1iN+vAVh4olvVhqUddW+Z8U5ZLc/ j/ENZ77nhjJ2RUwK1PWnuTHZwHPZ2tpJkhoKhWFKb/LvvNYwWRERKwy2lLR9FOJOxNiR wfFgDDnTQktZz/wkzHlBZ2raEHYxShVXVpVVfLqDn5gysVV6Plm7NvXIBZ8eYl2uzYE8 RkuUFgdlxMSbamfmu5nKCk+MmJp6uxuLH6ERIBlITzafy+q59C5Nns2Mq/oJ30va1dLY ZCWg== X-Gm-Message-State: AOAM532BePLcNjVjxRsAaQGuK4gC7825pFEEGZdtcTn/HtbaX6256kLD 9eal9H91xSd7jqZL3P0UgEly5aD5vTzXgHZbCoE= X-Google-Smtp-Source: ABdhPJxM3Desq3icLDjODQ4HmY9qz/+WIGWGiMt9CsF2euKACTEtxVDrEP3Kw1wtqd3xAvlm+CwdfYguu5QAFZmIfwM= X-Received: by 2002:ac2:42d1:: with SMTP id n17mr1275211lfl.76.1614332207896; Fri, 26 Feb 2021 01:36:47 -0800 (PST) MIME-Version: 1.0 References: <12bb83d9-625a-f967-ed15-9602fc4cd46b@faresoftware.it> <910eca81-bcb4-c4b2-d591-9a853026f184@beam.ltd.uk> <9d621536-e38e-c8ee-4d5e-dc3f24fb09f1@beam.ltd.uk> <30d6ff10b73bd117198a8e2dd3e47388@basmevissen.nl> <78459aa4ec6360c05752a8bc1d44eac5@basmevissen.nl> In-Reply-To: From: eremenok.k.by@gmail.com Date: Fri, 26 Feb 2021 12:36:37 +0300 Message-ID: Subject: Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? To: Andrey Zhizhikin Cc: Bas Mevissen , Otavio Salvador , Terry Barnaby , meta-freescale@lists.yoctoproject.org Content-Type: multipart/alternative; boundary="000000000000cd1ce405bc3a01ca" --000000000000cd1ce405bc3a01ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, there. I see here a lot of specialists. Some qestions. 1. What kernel (community or non-community) would you take for your own board (not NXP, not O.S.)? 2. I took the branch origin/imx_4.14.98_2.0.0_ga. Is it a community supported branch? =D1=87=D1=82, 25 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 17:00, Andr= ey Zhizhikin : > On Thu, Feb 25, 2021 at 2:22 PM Bas Mevissen wrot= e: > > > > On 2021-02-25 14:04, Andrey Zhizhikin wrote: > > > On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen > > > wrote: > > >> > > >> On 2021-02-25 13:32, Andrey Zhizhikin wrote: > > >> > Hello Bas, > > >> > > > >> > On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen > > >> > wrote: > > >> >> > > >> >> On 2021-02-25 12:21, Otavio Salvador wrote: > > >> >> > Em qui., 25 de fev. de 2021 =C3=A0s 06:53, Terry Barnaby > > >> >> > 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 cas= e > 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 woul= d > 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 thos= e > > >> > 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, i= t > > >> 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 w= ant > > >> 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 operati= on > > > bc552ba32d60 MA-7633-2 [Android-Reboot]reboot to fastboot\recovery m= ode > > > 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. > >=20 > > --000000000000cd1ce405bc3a01ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,= there.
I see h= ere a lot of specialists. Some qestions.=C2=A0
1. What kernel (community=C2=A0or non-commu= nity) would=C2=A0you take for your own board (not NXP, not O.S.)?
2. I took the branch=C2= =A0origin/imx_4.14.98_2.0.0_ga. Is it a community=C2=A0supported branch?= =C2=A0

=D1=87=D1=82, 25 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2= 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 =C3=A0s 06:53, Ter= ry Barnaby
> >> >> > <terry@beam.ltd.uk> escreveu:
> >> >> >>=C2=A0 From what I am seeing I will have to= use a NXP fsl-* based
> >> >> >> distribution
> >> >> >> to support the imx hardware video processi= ng features. I have built
> >> >> >> such
> >> >> >> a distro with both linux-fslc-imx and limu= x-imx kernels (I think!) for
> >> >> >> the Wandboard, which boots and runs but th= e HDMI display was not
> >> >> >> functional. I will persevere looking at th= at.
> >> >> >
> >> >> > No, you don't. You can use linux-fslc (mai= nline) and fslc-* distros as
> >> >> > i.MX6 has full mainline support. At O.S. Syste= ms we have been using
> >> >> > Linux mainline with many customers with great = success.
> >> >> >
> >> >>
> >> >> Wouldn't make sense to first evaluate the perfo= rmance 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 m= ight have some
> >> > "shortcuts" to boost performance in certain a= reas, 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 issu= es in those
> >> > domains on your own efforts.
> >> >
> >> > This is my pure speculation here, so take it with a gra= in 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) onl= y there to
> >> demonstrate the platform. Maybe that has changed over time.<= br> > >
> > 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 b= ad
> > 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 ha= s
> 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 th= e
> 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 pr= oduct receives
> >> > commitment to use either of BSP flavors - all areas sho= uld be
> >> > validated, not only the performance aspects of Multimed= ia domain.
> >> >
> >>
> >> Yes, when you have decided on the hardware to use. If you ar= e
> >> 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 developmen= t where
> >> time
> >> is usually very limited, so you want a quick but reliable re= sult).
> >
> > Correct, fully agree here.
> >
> >>
> >> >>
> >> >> BTW Would kernel.org stable kernel work as well on i.MX= 6 if you need
> >> >> graphics and video? I used it successfully for head= less IOT
> >> >> applications.
> >> >
> >> > As Fabio already indicated - this is possible.
> >> >
> >>
> >> Fabio said "mainline". I'm not sure whether me= ant 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 ope= ration
> > bc552ba32d60 MA-7633-2 [Android-Reboot]reboot to fastboot\recove= ry 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.



--000000000000cd1ce405bc3a01ca--