* imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? @ 2021-02-25 8:40 Mauro Ziliani 2021-02-25 8:47 ` [meta-freescale] " Andrey Zhizhikin 0 siblings, 1 reply; 24+ messages in thread From: Mauro Ziliani @ 2021-02-25 8:40 UTC (permalink / raw) To: meta-freescale [-- Attachment #1: Type: text/plain, Size: 213 bytes --] Hi all. I'm porting and old system based on Krogoth to Dunfell. In Krogoth the kernel was linux-imx. Now in Dunfell which is the right kernel? linux-fslc o linux-fslc-imx? Thanks all MZ [-- Attachment #2: Type: text/html, Size: 641 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 8:40 imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? Mauro Ziliani @ 2021-02-25 8:47 ` Andrey Zhizhikin 2021-02-25 9:00 ` Terry Barnaby 0 siblings, 1 reply; 24+ messages in thread From: Andrey Zhizhikin @ 2021-02-25 8:47 UTC (permalink / raw) To: Mauro Ziliani; +Cc: meta-freescale Hello Mauro, On Thu, Feb 25, 2021 at 9:40 AM Mauro Ziliani <mauro@faresoftware.it> wrote: > > Hi all. > > I'm porting and old system based on Krogoth to Dunfell. > > In Krogoth the kernel was linux-imx. > > Now in Dunfell which is the right kernel? Depends on what you define as "right". :) If you build any`fsl-` distro, then you should use either `linux-imx` of `linux-fslc-imx` kernel. If you rather opt for any of `fslc-` distro, then the kernel provider would be set to `linux-fslc`. > > linux-fslc o linux-fslc-imx? - `linux-fslc` is an upstream kernel (from stable korg), which has few patches not upstreamed yet - `linux-fslc-imx` is NXP kernel with latest patch level applied from stable korg. This is based on the NXP release (2.1.0 in [dunfell]), and then maintained in terms of security fixes applied in LTS branch. - `linux-imx` is a "pure" NXP kernel, which is provided as a part of their release(s). Current NXP release version present on the [dunfell] branch is 2.1.0 > > > Thanks all > > MZ > > -- Regards, Andrey. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 8:47 ` [meta-freescale] " Andrey Zhizhikin @ 2021-02-25 9:00 ` Terry Barnaby 2021-02-25 9:29 ` Andrey Zhizhikin 0 siblings, 1 reply; 24+ messages in thread From: Terry Barnaby @ 2021-02-25 9:00 UTC (permalink / raw) To: meta-freescale [-- Attachment #1: Type: text/plain, Size: 1907 bytes --] On 25/02/2021 08:47, Andrey Zhizhikin wrote: > Hello Mauro, > > On Thu, Feb 25, 2021 at 9:40 AM Mauro Ziliani <mauro@faresoftware.it> wrote: >> Hi all. >> >> I'm porting and old system based on Krogoth to Dunfell. >> >> In Krogoth the kernel was linux-imx. >> >> Now in Dunfell which is the right kernel? > Depends on what you define as "right". :) > > If you build any`fsl-` distro, then you should use either `linux-imx` > of `linux-fslc-imx` kernel. If you rather opt for any of `fslc-` > distro, then the kernel provider would be set to `linux-fslc`. > >> linux-fslc o linux-fslc-imx? > - `linux-fslc` is an upstream kernel (from stable korg), which has few > patches not upstreamed yet > - `linux-fslc-imx` is NXP kernel with latest patch level applied from > stable korg. This is based on the NXP release (2.1.0 in [dunfell]), > and then maintained in terms of security fixes applied in LTS branch. > - `linux-imx` is a "pure" NXP kernel, which is provided as a part of > their release(s). Current NXP release version present on the [dunfell] > branch is 2.1.0 > >> >> Thanks all >> >> MZ >> >> > > > For a novice to NXP Freescale builds, what setup would you recommend as a basic test Yocto build for a Wandboard IMX6 dual lite system in order to test the performance of the hardware video processing system using gstreamer*imx (VPU etc) ? Would fslc-x11 or fslc-xwayland distro with the linux-fslc-imx kernel be the best approach or would some fsl-* distro with the linux-imx kernel be the best approach ? The standard Wandboard build uses linux-fslc which does not seem to support the imx hardware features and so I am trying to build a suitable test platform but having no luck trying various build combinations that either wont build or wont run properly in various ways, so any pointers would be gratefully received ! Terry [-- Attachment #2: Type: text/html, Size: 2960 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 9:00 ` Terry Barnaby @ 2021-02-25 9:29 ` Andrey Zhizhikin 2021-02-25 9:53 ` Terry Barnaby 2021-02-25 11:47 ` Fabio Estevam 0 siblings, 2 replies; 24+ messages in thread From: Andrey Zhizhikin @ 2021-02-25 9:29 UTC (permalink / raw) To: Terry Barnaby; +Cc: meta-freescale Hello Terry, On Thu, Feb 25, 2021 at 10:01 AM Terry Barnaby <terry@beam.ltd.uk> wrote: > > > For a novice to NXP Freescale builds, what setup would you recommend as a basic test Yocto build for a Wandboard IMX6 dual lite system in order to test the performance of the hardware video processing system using gstreamer*imx (VPU etc) ? Since I do not have any of the i.MX6 HW and unaware of the state of VPU support - I can only speak from distro perspective. Anyone who posses the HW can clarify points from machine perspective here. > > Would fslc-x11 or fslc-xwayland distro with the linux-fslc-imx kernel be the best approach or would some fsl-* distro with the linux-imx kernel be the best approach ? The first recommendation from my side would be: choose the distro flavor. There are 2 types of distro in the layer: Community and NXP-based. 1. All distros with `fsl-` prefix are generally NXP-based, and include packages that NXP supplies as a part of their distribution. When it comes to kernel and U-Boot support - `linux-imx` and `u-boot-imx` packages are set as providers of `virtual/kernel` and `virtual/bootloader` respectively. This automatically means that if you take any of those distros prefixed with `fsl-` - you would be building NXP-based distribution. In addition, all packages that are marked as compatible with this BSP flavor would be included, in your case that would include the `gstreamer*imx` package. NOTE: you can switch the kernel provider to `linux-fslc-imx` for this BSP flavor, which would include the kernel type I described already in this thread (NXP release 2.1.0 + latest LTS patch level applied). `linux-fslc` cannot be set with this type of distro. 2. All distros with `fslc-` prefix are Community-based distros, which aims to include the upstream OSS packages and avoid using packages which has "Proprietary" license types in them. Kernel provider is set to `linux-fslc`, U-Boot provider is set to `u-boot-fslc`. As for the `gstreamer*imx` - I do not know if the compatibility set in the recipe would allow it to be included in this type of distro. NOTE: in this type of distro - only `linux-fslc` can be used as kernel provider. > > The standard Wandboard build uses linux-fslc which does not seem to support the imx hardware features and so I am trying to build a suitable test platform but having no luck trying various build combinations that either wont build or wont run properly in various ways, so any pointers would be gratefully received ! This means that Wandboard sets IMX_DEFAULT_BSP = "mainline" somewhere in its machine configuration, which targets the Community-based distribution. You can try to find where it is set and change it to IMX_DEFAULT_BSP = "nxp" to target NXP-based distro, and then use any of `fsl-` prefixed configuration files on your DISTRO variable. What you will get with this setup is then NXP-based distribution, but since as I said above I do not have any i.MX6 HW - I cannot guarantee that this setup would be 100% operable. Also in this case you would opt-in to use NXP distribution, so you should watch for licensing terms. > > Terry > > -- Regards, Andrey. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 9:29 ` Andrey Zhizhikin @ 2021-02-25 9:53 ` Terry Barnaby 2021-02-25 11:21 ` Otavio Salvador 2021-02-25 11:47 ` Fabio Estevam 1 sibling, 1 reply; 24+ messages in thread From: Terry Barnaby @ 2021-02-25 9:53 UTC (permalink / raw) To: Andrey Zhizhikin; +Cc: meta-freescale On 25/02/2021 09:29, Andrey Zhizhikin wrote: > Hello Terry, > > On Thu, Feb 25, 2021 at 10:01 AM Terry Barnaby <terry@beam.ltd.uk> wrote: >> >> For a novice to NXP Freescale builds, what setup would you recommend as a basic test Yocto build for a Wandboard IMX6 dual lite system in order to test the performance of the hardware video processing system using gstreamer*imx (VPU etc) ? > Since I do not have any of the i.MX6 HW and unaware of the state of > VPU support - I can only speak from distro perspective. Anyone who > posses the HW can clarify points from machine perspective here. > >> Would fslc-x11 or fslc-xwayland distro with the linux-fslc-imx kernel be the best approach or would some fsl-* distro with the linux-imx kernel be the best approach ? > The first recommendation from my side would be: choose the distro > flavor. There are 2 types of distro in the layer: Community and > NXP-based. > > 1. All distros with `fsl-` prefix are generally NXP-based, and include > packages that NXP supplies as a part of their distribution. When it > comes to kernel and U-Boot support - `linux-imx` and `u-boot-imx` > packages are set as providers of `virtual/kernel` and > `virtual/bootloader` respectively. This automatically means that if > you take any of those distros prefixed with `fsl-` - you would be > building NXP-based distribution. In addition, all packages that are > marked as compatible with this BSP flavor would be included, in your > case that would include the `gstreamer*imx` package. > NOTE: you can switch the kernel provider to `linux-fslc-imx` for this > BSP flavor, which would include the kernel type I described already in > this thread (NXP release 2.1.0 + latest LTS patch level applied). > `linux-fslc` cannot be set with this type of distro. > > 2. All distros with `fslc-` prefix are Community-based distros, which > aims to include the upstream OSS packages and avoid using packages > which has "Proprietary" license types in them. Kernel provider is set > to `linux-fslc`, U-Boot provider is set to `u-boot-fslc`. As for the > `gstreamer*imx` - I do not know if the compatibility set in the recipe > would allow it to be included in this type of distro. > NOTE: in this type of distro - only `linux-fslc` can be used as kernel provider. > >> The standard Wandboard build uses linux-fslc which does not seem to support the imx hardware features and so I am trying to build a suitable test platform but having no luck trying various build combinations that either wont build or wont run properly in various ways, so any pointers would be gratefully received ! > This means that Wandboard sets IMX_DEFAULT_BSP = "mainline" somewhere > in its machine configuration, which targets the Community-based > distribution. You can try to find where it is set and change it to > IMX_DEFAULT_BSP = "nxp" to target NXP-based distro, and then use any > of `fsl-` prefixed configuration files on your DISTRO variable. > > What you will get with this setup is then NXP-based distribution, but > since as I said above I do not have any i.MX6 HW - I cannot guarantee > that this setup would be 100% operable. Also in this case you would > opt-in to use NXP distribution, so you should watch for licensing > terms. > >> Terry >> >> > -- > Regards, > Andrey. Hi Andrey, Many thanks for your time and info on this, that is a great help to firm up where I should be starting from and which distros are compatible (to some degree anyway) with which kernel. 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. Terry ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 9:53 ` Terry Barnaby @ 2021-02-25 11:21 ` Otavio Salvador 2021-02-25 11:50 ` Terry Barnaby 2021-02-25 12:18 ` Bas Mevissen 0 siblings, 2 replies; 24+ messages in thread From: Otavio Salvador @ 2021-02-25 11:21 UTC (permalink / raw) To: Terry Barnaby; +Cc: Andrey Zhizhikin, meta-freescale 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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 11:21 ` Otavio Salvador @ 2021-02-25 11:50 ` Terry Barnaby 2021-02-25 12:24 ` Andrey Zhizhikin 2021-02-25 12:18 ` Bas Mevissen 1 sibling, 1 reply; 24+ messages in thread From: Terry Barnaby @ 2021-02-25 11:50 UTC (permalink / raw) To: Otavio Salvador; +Cc: Andrey Zhizhikin, meta-freescale On 25/02/2021 11: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. > Thanks for the info, I must be getting something wrong then. If I do, what I think is a standard http://freescale.github.io dunfell build, using "MACHINE ??= 'wandboard'", "DISTRO ?= 'fslc-x11'" and add IMAGE_INSTALL_append=" gstreamer1.0-plugins-imx" to get the gstreamer plugs for the imx video processing hardware support built (they are not there by default, this uses linux-fslc), I get an error: ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx' (but /datal3/DartSystems/ds200i-system/fsl-community-bsp/sources/meta-freescale-distro/recipes-fsl/images/fsl-image-multimedia-full.bb RDEPENDS on or otherwise requires it) gstreamer1.0-plugins-imx was skipped: incompatible with machine wandboard (not in COMPATIBLE_MACHINE) If I use an IMX_DEFAULT_BSP="nxp" based build the gstreamer1.0-plugins-imx gets built. So what am i doing wrong ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 11:50 ` Terry Barnaby @ 2021-02-25 12:24 ` Andrey Zhizhikin 0 siblings, 0 replies; 24+ messages in thread From: Andrey Zhizhikin @ 2021-02-25 12:24 UTC (permalink / raw) To: Terry Barnaby; +Cc: Otavio Salvador, meta-freescale On Thu, Feb 25, 2021 at 12:50 PM Terry Barnaby <terry@beam.ltd.uk> wrote: > > On 25/02/2021 11: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. > > > Thanks for the info, I must be getting something wrong then. > > If I do, what I think is a standard http://freescale.github.io dunfell > build, using "MACHINE ??= 'wandboard'", "DISTRO ?= 'fslc-x11'" and add > IMAGE_INSTALL_append=" gstreamer1.0-plugins-imx" to get the gstreamer > plugs for the imx video processing hardware support built (they are not > there by default, this uses linux-fslc), I get an error: > > ERROR: Nothing RPROVIDES 'gstreamer1.0-plugins-imx' (but > /datal3/DartSystems/ds200i-system/fsl-community-bsp/sources/meta-freescale-distro/recipes-fsl/images/fsl-image-multimedia-full.bb > RDEPENDS on or otherwise requires it) > gstreamer1.0-plugins-imx was skipped: incompatible with machine > wandboard (not in COMPATIBLE_MACHINE) This is expected, and actually follows to what I previously said: gstreamer1.0-plugins-imx package is not compatible with Community BSP (chosen by setting IMX_DEFAULT_BSP="mainline"). As Fabio already indicated, gstreamer1.0-plugins-imx should be used **only** with NXP-based BSP (selected by setting IMX_DEFAULT_BSP="nxp") as it requires the NXP-specific modifications in the kernel, which are not upstreamed (and probably would not be). > > If I use an IMX_DEFAULT_BSP="nxp" based build the > gstreamer1.0-plugins-imx gets built. So what am i doing wrong ? > This is also expected behavior. Once opted for NXP-based BSP - package compatibility becomes valid, hence it can be built and installed. So in a sense - you're not doing anything wrong here. You're changing the BSP flavor from Community to NXP-based one. -- Regards, Andrey. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 11:21 ` Otavio Salvador 2021-02-25 11:50 ` Terry Barnaby @ 2021-02-25 12:18 ` Bas Mevissen 2021-02-25 12:32 ` Andrey Zhizhikin 1 sibling, 1 reply; 24+ messages in thread From: Bas Mevissen @ 2021-02-25 12:18 UTC (permalink / raw) To: Otavio Salvador; +Cc: Terry Barnaby, Andrey Zhizhikin, meta-freescale 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-*. 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. Bas. > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 12:18 ` Bas Mevissen @ 2021-02-25 12:32 ` Andrey Zhizhikin 2021-02-25 12:55 ` Bas Mevissen 0 siblings, 1 reply; 24+ messages in thread From: Andrey Zhizhikin @ 2021-02-25 12:32 UTC (permalink / raw) To: Bas Mevissen; +Cc: Otavio Salvador, Terry Barnaby, meta-freescale 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. 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, 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. > > 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. > > Bas. > -- Regards, Andrey. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 12:32 ` Andrey Zhizhikin @ 2021-02-25 12:55 ` Bas Mevissen 2021-02-25 13:01 ` Fabio Estevam 2021-02-25 13:04 ` Andrey Zhizhikin 0 siblings, 2 replies; 24+ messages in thread From: Bas Mevissen @ 2021-02-25 12:55 UTC (permalink / raw) To: Andrey Zhizhikin; +Cc: Otavio Salvador, Terry Barnaby, meta-freescale 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. When there is a huge performance difference between fsl and fslc, it needs to be resolved. > 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). >> >> 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. So I wanted to check that. >> >> Bas. >> > > -- > Regards, > Andrey. > > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 12:55 ` Bas Mevissen @ 2021-02-25 13:01 ` Fabio Estevam 2021-02-25 13:12 ` Bas Mevissen 2021-02-25 13:04 ` Andrey Zhizhikin 1 sibling, 1 reply; 24+ messages in thread From: Fabio Estevam @ 2021-02-25 13:01 UTC (permalink / raw) To: Bas Mevissen Cc: Andrey Zhizhikin, Otavio Salvador, Terry Barnaby, meta-freescale Hi Bas, On Thu, Feb 25, 2021 at 9:55 AM Bas Mevissen <abuse@basmevissen.nl> wrote: > Fabio said "mainline". I'm not sure whether meant linux-fslc (as Otavio > used it) or kernel.org. > So I wanted to check that. imx6 has decent graphics support in the mainline kernel via the Etnaviv driver. Userspace is standard Mesa, with no binary blobs involved. VPU is supported by the coda driver and the standard Gstreamer packages. By mainline, I do mean a "kernel.org" based kernel. linux-fslc uses the stable tree from "kernel.org" as the base and add additional patch on top. Hope that clarifies things. Cheers ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 13:01 ` Fabio Estevam @ 2021-02-25 13:12 ` Bas Mevissen 0 siblings, 0 replies; 24+ messages in thread From: Bas Mevissen @ 2021-02-25 13:12 UTC (permalink / raw) To: Fabio Estevam Cc: Andrey Zhizhikin, Otavio Salvador, Terry Barnaby, meta-freescale On 2021-02-25 14:01, Fabio Estevam wrote: > Hi Bas, > > On Thu, Feb 25, 2021 at 9:55 AM Bas Mevissen <abuse@basmevissen.nl> > wrote: > >> Fabio said "mainline". I'm not sure whether meant linux-fslc (as >> Otavio >> used it) or kernel.org. >> So I wanted to check that. > > imx6 has decent graphics support in the mainline kernel via the > Etnaviv driver. Userspace is standard Mesa, with no binary blobs > involved. > VPU is supported by the coda driver and the standard Gstreamer > packages. > > By mainline, I do mean a "kernel.org" based kernel. > > linux-fslc uses the stable tree from "kernel.org" as the base and add > additional patch on top. > Ah yes, I see. Linux-fslc is now really up to date with kernel.org. I recall (from 2017 era) that that was different. Maybe I'm wrong about that. > Hope that clarifies things. > Yes, thanks for the explanation. Bas. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 12:55 ` Bas Mevissen 2021-02-25 13:01 ` Fabio Estevam @ 2021-02-25 13:04 ` Andrey Zhizhikin 2021-02-25 13:22 ` Bas Mevissen 1 sibling, 1 reply; 24+ messages in thread From: Andrey Zhizhikin @ 2021-02-25 13:04 UTC (permalink / raw) To: Bas Mevissen; +Cc: Otavio Salvador, Terry Barnaby, meta-freescale 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. > > 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. > > > 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. > > >> > >> Bas. > >> > > > > -- > > Regards, > > Andrey. > > > > -- Regards, Andrey. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 13:04 ` Andrey Zhizhikin @ 2021-02-25 13:22 ` Bas Mevissen 2021-02-25 14:00 ` Andrey Zhizhikin 0 siblings, 1 reply; 24+ messages in thread From: Bas Mevissen @ 2021-02-25 13:22 UTC (permalink / raw) To: Andrey Zhizhikin; +Cc: Otavio Salvador, Terry Barnaby, meta-freescale 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. >> >> > 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 13:22 ` Bas Mevissen @ 2021-02-25 14:00 ` Andrey Zhizhikin 2021-02-26 9:36 ` eremenok.k.by 0 siblings, 1 reply; 24+ messages in thread From: Andrey Zhizhikin @ 2021-02-25 14:00 UTC (permalink / raw) To: Bas Mevissen; +Cc: Otavio Salvador, Terry Barnaby, meta-freescale 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 14:00 ` Andrey Zhizhikin @ 2021-02-26 9:36 ` eremenok.k.by 2021-02-26 10:03 ` Bas Mevissen 0 siblings, 1 reply; 24+ messages in thread From: eremenok.k.by @ 2021-02-26 9:36 UTC (permalink / raw) To: Andrey Zhizhikin Cc: Bas Mevissen, Otavio Salvador, Terry Barnaby, meta-freescale [-- Attachment #1: Type: text/plain, Size: 7218 bytes --] 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? чт, 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. > > > > [-- Attachment #2: Type: text/html, Size: 9923 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-26 9:36 ` eremenok.k.by @ 2021-02-26 10:03 ` Bas Mevissen 2021-02-26 10:16 ` Константин Еременок 0 siblings, 1 reply; 24+ messages in thread From: Bas Mevissen @ 2021-02-26 10:03 UTC (permalink / raw) To: Константин Еременок Cc: Andrey Zhizhikin, Otavio Salvador, Terry Barnaby, meta-freescale 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. >> >> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-26 10:03 ` Bas Mevissen @ 2021-02-26 10:16 ` Константин Еременок 0 siblings, 0 replies; 24+ messages in thread From: Константин Еременок @ 2021-02-26 10:16 UTC (permalink / raw) To: Bas Mevissen Cc: meta-freescale, Terry Barnaby, Otavio Salvador, Andrey Zhizhikin [-- Attachment #1: Type: text/plain, Size: 27 bytes --] Thanks. Sorry for a spam. [-- Attachment #2: Type: text/html, Size: 120 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 9:29 ` Andrey Zhizhikin 2021-02-25 9:53 ` Terry Barnaby @ 2021-02-25 11:47 ` Fabio Estevam 2021-02-25 11:57 ` Terry Barnaby 1 sibling, 1 reply; 24+ messages in thread From: Fabio Estevam @ 2021-02-25 11:47 UTC (permalink / raw) To: Andrey Zhizhikin; +Cc: Terry Barnaby, meta-freescale Hi Terry, On Thu, Feb 25, 2021 at 6:29 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote: > > For a novice to NXP Freescale builds, what setup would you recommend as a basic test Yocto build for a Wandboard IMX6 dual lite system in order to test the performance of the hardware video processing system using gstreamer*imx (VPU etc) ? > > Since I do not have any of the i.MX6 HW and unaware of the state of > VPU support - I can only speak from distro perspective. Anyone who > posses the HW can clarify points from machine perspective here. Yes, imx6 is well supported in mainline kernels including VPU support. Please note that with the mainline kernel, you should use the standard gstreamer packages, not the gstreamer-imx ones. The gstreamer-imx packages are meant to be used only with NXP kernels. Regards, Fabio Estevam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 11:47 ` Fabio Estevam @ 2021-02-25 11:57 ` Terry Barnaby 2021-02-25 12:02 ` Fabio Estevam 0 siblings, 1 reply; 24+ messages in thread From: Terry Barnaby @ 2021-02-25 11:57 UTC (permalink / raw) To: Fabio Estevam, Andrey Zhizhikin; +Cc: meta-freescale On 25/02/2021 11:47, Fabio Estevam wrote: > Hi Terry, > > On Thu, Feb 25, 2021 at 6:29 AM Andrey Zhizhikin <andrey.z@gmail.com> wrote: > >>> For a novice to NXP Freescale builds, what setup would you recommend as a basic test Yocto build for a Wandboard IMX6 dual lite system in order to test the performance of the hardware video processing system using gstreamer*imx (VPU etc) ? >> Since I do not have any of the i.MX6 HW and unaware of the state of >> VPU support - I can only speak from distro perspective. Anyone who >> posses the HW can clarify points from machine perspective here. > Yes, imx6 is well supported in mainline kernels including VPU support. > > Please note that with the mainline kernel, you should use the standard > gstreamer packages, not the gstreamer-imx ones. > > The gstreamer-imx packages are meant to be used only with NXP kernels. > > Regards, > > Fabio Estevam Many thanks for that info, from Internet info it looked like the gstreamer-imx package and associated lower libraries/drivers were needed, I will try another build, the gstreamer video hardware support wasn't there (as reported by gst-inspect-1.0) when I tried, maybe I got lost in a tangle of distro, kernel and bitbake targets. Terry ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 11:57 ` Terry Barnaby @ 2021-02-25 12:02 ` Fabio Estevam 2021-02-26 10:26 ` Terry Barnaby 0 siblings, 1 reply; 24+ messages in thread From: Fabio Estevam @ 2021-02-25 12:02 UTC (permalink / raw) To: Terry Barnaby; +Cc: Andrey Zhizhikin, meta-freescale On Thu, Feb 25, 2021 at 8:58 AM Terry Barnaby <terry@beam.ltd.uk> wrote: > Many thanks for that info, from Internet info it looked like the > gstreamer-imx package and associated lower libraries/drivers were > needed, I will try another build, the gstreamer video hardware support > wasn't there (as reported by gst-inspect-1.0) when I tried, maybe I got > lost in a tangle of distro, kernel and bitbake targets. The v4l2dec/enc plugins only show up if the VPU driver were successfully loaded. Make sure that the VPU (coda) driver is being loaded correctly with the associated firmware. After that, these v4l2dec/enc plugins should be reported by gst-inspect. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-25 12:02 ` Fabio Estevam @ 2021-02-26 10:26 ` Terry Barnaby 2021-02-26 11:27 ` Bas Mevissen 0 siblings, 1 reply; 24+ messages in thread From: Terry Barnaby @ 2021-02-26 10:26 UTC (permalink / raw) To: Fabio Estevam; +Cc: Andrey Zhizhikin, meta-freescale On 25/02/2021 12:02, Fabio Estevam wrote: > On Thu, Feb 25, 2021 at 8:58 AM Terry Barnaby <terry@beam.ltd.uk> wrote: > >> Many thanks for that info, from Internet info it looked like the >> gstreamer-imx package and associated lower libraries/drivers were >> needed, I will try another build, the gstreamer video hardware support >> wasn't there (as reported by gst-inspect-1.0) when I tried, maybe I got >> lost in a tangle of distro, kernel and bitbake targets. > The v4l2dec/enc plugins only show up if the VPU driver were successfully loaded. > > Make sure that the VPU (coda) driver is being loaded correctly with > the associated firmware. > > After that, these v4l2dec/enc plugins should be reported by gst-inspect. I discovered where I was going wrong. My Yocto/Freecale build for the Wandboard with standard fslc-x11 distro and linux-fslc kernel did have iMX8 video hardware supported and working! I was originally using a Wandboard supplied binary distro for testing that was quite old that used gstreamer modules such as imxv4l2sink, vpuenc_h264, overlaysync etc and most of the Internet documentation for iMX6's was the same. However the latest dunfell level gstreamer uses the more generally standard v4l2h264enc gstreamer module that ends up by using the iMX6 VPU's H264 encoder. Now I just need to work out if the current iMX6 video hardware API's allows me to do the video processing pipeline I want/need with suitably low enough CPU and memory bandwidth usage. Also how to get an efficient gstreamer video source for performance testing while I await a working physical camera as videotestsrc uses a lot of CPU for some reason masking the performance testing. Note I am using Fedora33 as a build platform now, and that seems fine with dunfell although not yet marked as a known working platform for building. Many thanks for everyone's help. Terry ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [meta-freescale] imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? 2021-02-26 10:26 ` Terry Barnaby @ 2021-02-26 11:27 ` Bas Mevissen 0 siblings, 0 replies; 24+ messages in thread From: Bas Mevissen @ 2021-02-26 11:27 UTC (permalink / raw) To: Terry Barnaby; +Cc: Fabio Estevam, Andrey Zhizhikin, meta-freescale On 2021-02-26 11:26, Terry Barnaby wrote: > On 25/02/2021 12:02, Fabio Estevam wrote: >> On Thu, Feb 25, 2021 at 8:58 AM Terry Barnaby <terry@beam.ltd.uk> >> wrote: >> >>> Many thanks for that info, from Internet info it looked like the >>> gstreamer-imx package and associated lower libraries/drivers were >>> needed, I will try another build, the gstreamer video hardware >>> support >>> wasn't there (as reported by gst-inspect-1.0) when I tried, maybe I >>> got >>> lost in a tangle of distro, kernel and bitbake targets. >> The v4l2dec/enc plugins only show up if the VPU driver were >> successfully loaded. >> >> Make sure that the VPU (coda) driver is being loaded correctly with >> the associated firmware. >> >> After that, these v4l2dec/enc plugins should be reported by >> gst-inspect. > > I discovered where I was going wrong. My Yocto/Freecale build for the > Wandboard with standard fslc-x11 distro and linux-fslc kernel did have > iMX8 video hardware supported and working! > > I was originally using a Wandboard supplied binary distro for testing > that was quite old that used gstreamer modules such as imxv4l2sink, > vpuenc_h264, overlaysync etc and most of the Internet documentation > for iMX6's was the same. However the latest dunfell level gstreamer > uses the more generally standard v4l2h264enc gstreamer module that > ends up by using the iMX6 VPU's H264 encoder. > > Now I just need to work out if the current iMX6 video hardware API's > allows me to do the video processing pipeline I want/need with > suitably low enough CPU and memory bandwidth usage. Also how to get an > efficient gstreamer video source for performance testing while I await > a working physical camera as videotestsrc uses a lot of CPU for some > reason masking the performance testing. > Good to hear you make progress! > Note I am using Fedora33 as a build platform now, and that seems fine > with dunfell although not yet marked as a known working platform for > building. > I also always use the latest Fedora as my development platform. It usually works without a problem (except for the warning). Only the uninative cannot always keep up with the latet glibc used in Fedora. But that is usually picked up very quickly. For older Yocto versions, I use systemd containers with a matching OS, like CentOS 7 or Debian. Toradex has a nice write-up on how to set that up. > Many thanks for everyone's help. > > Terry > > > > ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2021-02-26 11:27 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-25 8:40 imx6dl dunfell and kernel: linux-fslc or linux-fslc-imx? Mauro Ziliani 2021-02-25 8:47 ` [meta-freescale] " Andrey Zhizhikin 2021-02-25 9:00 ` Terry Barnaby 2021-02-25 9:29 ` Andrey Zhizhikin 2021-02-25 9:53 ` Terry Barnaby 2021-02-25 11:21 ` Otavio Salvador 2021-02-25 11:50 ` Terry Barnaby 2021-02-25 12:24 ` Andrey Zhizhikin 2021-02-25 12:18 ` Bas Mevissen 2021-02-25 12:32 ` Andrey Zhizhikin 2021-02-25 12:55 ` Bas Mevissen 2021-02-25 13:01 ` Fabio Estevam 2021-02-25 13:12 ` Bas Mevissen 2021-02-25 13:04 ` Andrey Zhizhikin 2021-02-25 13:22 ` Bas Mevissen 2021-02-25 14:00 ` Andrey Zhizhikin 2021-02-26 9:36 ` eremenok.k.by 2021-02-26 10:03 ` Bas Mevissen 2021-02-26 10:16 ` Константин Еременок 2021-02-25 11:47 ` Fabio Estevam 2021-02-25 11:57 ` Terry Barnaby 2021-02-25 12:02 ` Fabio Estevam 2021-02-26 10:26 ` Terry Barnaby 2021-02-26 11:27 ` Bas Mevissen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.