Date   

Re: Wireguard recipe

Zunzunegui Abad, Mario-Sergio <mario.zunzunegui@...>
 

Airbus Amber
Hello Bas.
The result is the same.
I have added to my sources/meta-freescale/recipes-fsl/images/fsl-image-core.bb the following IMAGE_INSTALL_append = " \
kernel-devsrc \
wireguard-tools \
wireguard-module \
"

kernel-devsrc is for adding kernel headers.

Exactly the same, I can generate private and public keys with command "wg genkey . .. ."
But when I run "modprobe wireguard" the result is
modprobe: FATAL: Module wireguard not found.


I think I am not adding the module properly.
Any other Idea?
Thank you very much



-----Mensaje original-----
De: Bas Mevissen [mailto:abuse@...] Enviado el: jueves, 25 de febrero de 2021 15:18
Para: Mario Sergio Zunzunegui Abad
CC: Zunzunegui Abad, Mario-Sergio; meta-freescale@...
Asunto: Re: [meta-freescale] Wireguard recipe

On 2021-02-25 15:12, Mario Sergio Zunzunegui Abad wrote:

Hello Bas.
I am afraid I havent realised I had to do that action.
Could you please tell me how to include this module kmod-wireguard?
Thank you very much
Sorry, got the name wrong. That is how it is called in OpenWRT. :-) What you need is "wireguard-module" and you can add it to IMAGE_INSTALL_append like wireguard-tools.

Bas.

El jue., 25 feb. 2021 15:09, Bas Mevissen <abuse@...>
escribió:

On 2021-02-22 16:28, Zunzunegui Abad, Mario-Sergio wrote:

[Edited Message Follows]

Hello.

I am trying to install WireGuard in Yocto.

I have included the code and recipe and compiled all with bitbake
and generated an image.

I have added the code provided by NXP in folder
sources/meta-openembedded/meta-networking/recipes-kernel.

Also added "wireguard-tools" in IMAGE_INSTALL_append in
meta-freescale/recipes-fsl/images/fsl-image-core.bb, then run
"bitbake fsl-image-core"

I can generate public and private keys with wg command.

But when I try to configure WireGuard, it seems that it is not
loaded the module.

root@vpx3-152:~# modprobe wireguard

modprobe: FATAL: Module wireguard not found.

root@vpx3-152:~#

What I am doing wrong?
Aren't you missing the kmod-wireguard package in your image?

Regards.

#Yocto-wireguard

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.


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

Bas Mevissen
 

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@...> 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


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

Terry Barnaby
 

On 25/02/2021 12:02, Fabio Estevam wrote:
On Thu, Feb 25, 2021 at 8:58 AM Terry Barnaby <terry@...> 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


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

Константин Еременок
 

Thanks. Sorry for a spam.


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

Bas Mevissen
 

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

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

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

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

2. I took the branch origin/imx_4.14.98_2.0.0_ga. Is it a community supported branch?
From 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@...>:

On Thu, Feb 25, 2021 at 2:22 PM Bas Mevissen <abuse@...> wrote:
On 2021-02-25 14:04, Andrey Zhizhikin wrote:
On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@...>
wrote:
On 2021-02-25 13:32, Andrey Zhizhikin wrote:
Hello Bas,
On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...>
wrote:
On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
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.


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

Константин Еременок
 

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@...>:

On Thu, Feb 25, 2021 at 2:22 PM Bas Mevissen <abuse@...> wrote:
>
> On 2021-02-25 14:04, Andrey Zhizhikin wrote:
> > On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@...>
> > wrote:
> >>
> >> On 2021-02-25 13:32, Andrey Zhizhikin wrote:
> >> > Hello Bas,
> >> >
> >> > On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...>
> >> > wrote:
> >> >>
> >> >> On 2021-02-25 12:21, Otavio Salvador wrote:
> >> >> > Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
> >> >> > <terry@...> escreveu:
> >> >> >>  From what I am seeing I will have to use a NXP fsl-* based
> >> >> >> 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.




Re: Wireguard recipe

Christian Betz
 

Hello,

From my experience there are a number of steps; let me try and save you some trouble!

(1) create patch for wireguard in your layer. i needed this for linux-fslc kernel on yocto dunfell as of linux kernel version 5.4.83. (i haven't tried later versions or merged  dunfell branch since december, you may not need this patch right now)

filename: ./recipes-wireguard/wireguard/files/wireguard-compat.patch
-------snip------
diff --git a/src/compat/compat-asm.h b/src/compat/compat-asm.h
index 53b33d4..1240bc3 100644
--- a/src/compat/compat-asm.h
+++ b/src/compat/compat-asm.h
@@ -41,8 +41,10 @@
 #endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(5, 5, 0)
+/*
 #define SYM_FUNC_START ENTRY
 #define SYM_FUNC_END ENDPROC
+*/
 #endif
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 5, 0)
-------snip------

(2) create bbappend in your layer to apply patch

filename: ./recipes-wireguard/wireguard/wireguard-module_%.bbappend
-------snip------
# Patch to make wireguard compile on Yocto
SRC_URI_append_yourboardname = " file://wireguard-compat.patch;striplevel=2"
-------snip------

(3) fix bug with systemd location in recipe (if you are using systemd)

filename: ./recipes-wireguard/wireguard/wireguard-tools_%.bbappend
-------snip------
# Fix bug with systemd unit in wrong location
# TODO: check if this is fixed upstream
do_install () {
    oe_runmake DESTDIR="${D}" PREFIX="${prefix}" SYSCONFDIR="${sysconfdir}" \
        SYSTEMDUNITDIR="${systemd_unitdir}/system" \
        WITH_SYSTEMDUNITS=${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'yes', '', d)} \
        WITH_BASHCOMPLETION=yes \
        WITH_WGQUICK=yes \
        install
}
-------snip------

(4) make sure you have a kernel cfg for everything wireguard needs:

stock linux-fslc seems to be missing some things wireguard needs.

filename: ./recipes-bsp/linux-fslc/files/wireguard-extra-kernel-options.cfg
-------snip------
CONFIG_SKB_EXTENSIONS=y
CONFIG_XFRM=y
CONFIG_NET_IPIP=y
CONFIG_NET_UDP_TUNNEL=y
CONFIG_NET_FOU=y
CONFIG_IPV6_FOU=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CT_PROTO_DCCP=y
CONFIG_NF_CT_PROTO_SCTP=y
CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_DEFRAG_IPV6=y
CONFIG_LIBCRC32C=y
-------snip------

(5) add the kernel config in a bbappend for linux-fslc.

filename: grep wireguard recipes-bsp/linux-fslc/linux-fslc_%.bbappend
-------snip------
# Add custom kernel options for wireguard, wireless PCI
# Enable wireguard module
SRC_URI += "file://wireguard-extra-kernel-options.cfg"
-------snip------

(6) add "wireguard-tools kernel-module-wireguard" to your image, i.e.:

filename: recipes-mycompany/images/myproduct-image.bb
-------snip------
...
IMAGE_INSTALL_append = " wireguard-tools kernel-module-wireguard"
...
-------snip------


On Thu, Feb 25, 2021 at 8:36 AM Zunzunegui Abad, Mario-Sergio <mario.zunzunegui@...> wrote:

[Edited Message Follows]

Airbus Amber

Hello.

I am trying to install WireGuard in Yocto.

I have included the code and recipe and compiled all with bitbake and generated an image.

 

I have added the code provided by NXP in folder sources/meta-openembedded/meta-networking/recipes-kernel.

 

Also added  "wireguard-tools" in IMAGE_INSTALL_append in meta-freescale/recipes-fsl/images/fsl-image-core.bb, then run "bitbake fsl-image-core"

 

I can generate public and private keys with wg command.

 

But when I try to configure WireGuard, it seems that it is not loaded the module.

 

root@vpx3-152:~# modprobe wireguard

modprobe: FATAL: Module wireguard not found.

root@vpx3-152:~#

 

What I am doing wrong?

Regards.

 

#Yocto-wireguard






--
"the new garbage collector will be an arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector" -- LuaJIT Roadmap


Re: Wireguard recipe

Bas Mevissen
 

On 2021-02-25 15:12, Mario Sergio Zunzunegui Abad wrote:

Hello Bas.
I am afraid I havent realised I had to do that action.
Could you please tell me how to include this module kmod-wireguard?
Thank you very much
Sorry, got the name wrong. That is how it is called in OpenWRT. :-)
What you need is "wireguard-module" and you can add it to IMAGE_INSTALL_append like wireguard-tools.

Bas.

El jue., 25 feb. 2021 15:09, Bas Mevissen <abuse@...> escribió:

On 2021-02-22 16:28, Zunzunegui Abad, Mario-Sergio wrote:

[Edited Message Follows]
Hello.
I am trying to install WireGuard in Yocto.
I have included the code and recipe and compiled all with bitbake and
generated an image.
I have added the code provided by NXP in folder
sources/meta-openembedded/meta-networking/recipes-kernel.
Also added "wireguard-tools" in IMAGE_INSTALL_append in
meta-freescale/recipes-fsl/images/fsl-image-core.bb, then run "bitbake
fsl-image-core"
I can generate public and private keys with wg command.
But when I try to configure WireGuard, it seems that it is not loaded
the module.
root@vpx3-152:~# modprobe wireguard
modprobe: FATAL: Module wireguard not found.
root@vpx3-152:~#
What I am doing wrong?
Aren't you missing the kmod-wireguard package in your image?

Regards.
#Yocto-wireguard


Re: Wireguard recipe

szunzunegui@...
 

Hello Bas.
I am afraid I havent realised I had to do that action.
Could you please tell me how to include this module kmod-wireguard?
Thank you very much


El jue., 25 feb. 2021 15:09, Bas Mevissen <abuse@...> escribió:
On 2021-02-22 16:28, Zunzunegui Abad, Mario-Sergio wrote:

> [Edited Message Follows]
>
> Hello.
>
> I am trying to install WireGuard in Yocto.
>
> I have included the code and recipe and compiled all with bitbake and
> generated an image.
>
> I have added the code provided by NXP in folder
> sources/meta-openembedded/meta-networking/recipes-kernel.
>
> Also added  "wireguard-tools" in IMAGE_INSTALL_append in
> meta-freescale/recipes-fsl/images/fsl-image-core.bb, then run "bitbake
> fsl-image-core"
>
> I can generate public and private keys with wg command.
>
> But when I try to configure WireGuard, it seems that it is not loaded
> the module.
>
> root@vpx3-152:~# modprobe wireguard
>
> modprobe: FATAL: Module wireguard not found.
>
> root@vpx3-152:~#
>
> What I am doing wrong?
>

Aren't you missing the kmod-wireguard package in your image?

> Regards.
>
> #Yocto-wireguard
>
>






Re: Wireguard recipe

Bas Mevissen
 

On 2021-02-22 16:28, Zunzunegui Abad, Mario-Sergio wrote:

[Edited Message Follows]
Hello.
I am trying to install WireGuard in Yocto.
I have included the code and recipe and compiled all with bitbake and generated an image.
I have added the code provided by NXP in folder sources/meta-openembedded/meta-networking/recipes-kernel.
Also added "wireguard-tools" in IMAGE_INSTALL_append in meta-freescale/recipes-fsl/images/fsl-image-core.bb, then run "bitbake fsl-image-core"
I can generate public and private keys with wg command.
But when I try to configure WireGuard, it seems that it is not loaded the module.
root@vpx3-152:~# modprobe wireguard
modprobe: FATAL: Module wireguard not found.
root@vpx3-152:~#
What I am doing wrong?
Aren't you missing the kmod-wireguard package in your image?

Regards.
#Yocto-wireguard


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

Andrey Zhizhikin
 

On Thu, Feb 25, 2021 at 2:22 PM Bas Mevissen <abuse@...> wrote:

On 2021-02-25 14:04, Andrey Zhizhikin wrote:
On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@...>
wrote:

On 2021-02-25 13:32, Andrey Zhizhikin wrote:
Hello Bas,

On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...>
wrote:

On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
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.


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

Bas Mevissen
 

On 2021-02-25 14:04, Andrey Zhizhikin wrote:
On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@...> wrote:
On 2021-02-25 13:32, Andrey Zhizhikin wrote:
Hello Bas,

On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...>
wrote:

On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
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.


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

Bas Mevissen
 

On 2021-02-25 14:01, Fabio Estevam wrote:
Hi Bas,
On Thu, Feb 25, 2021 at 9:55 AM Bas Mevissen <abuse@...> 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.


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

Andrey Zhizhikin
 

On Thu, Feb 25, 2021 at 1:55 PM Bas Mevissen <abuse@...> wrote:

On 2021-02-25 13:32, Andrey Zhizhikin wrote:
Hello Bas,

On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...>
wrote:

On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
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.


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

Fabio Estevam
 

Hi Bas,

On Thu, Feb 25, 2021 at 9:55 AM Bas Mevissen <abuse@...> 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


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

Bas Mevissen
 

On 2021-02-25 13:32, Andrey Zhizhikin wrote:
Hello Bas,
On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...> wrote:
On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
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.


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

Andrey Zhizhikin
 

Hello Bas,

On Thu, Feb 25, 2021 at 1:18 PM Bas Mevissen <abuse@...> wrote:

On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based
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.


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

Andrey Zhizhikin
 

On Thu, Feb 25, 2021 at 12:50 PM Terry Barnaby <terry@...> wrote:

On 25/02/2021 11:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based 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.


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

Bas Mevissen
 

On 2021-02-25 12:21, Otavio Salvador wrote:
Em qui., 25 de fev. de 2021 às 06:53, Terry Barnaby
<terry@...> escreveu:
From what I am seeing I will have to use a NXP fsl-* based 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.


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

Fabio Estevam
 

On Thu, Feb 25, 2021 at 8:58 AM Terry Barnaby <terry@...> 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.

321 - 340 of 24894