Date   

Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

On Fri, Apr 10, 2020 at 11:46 AM Gary Bisson
<gary.bisson@...> wrote:
On Fri, Apr 10, 2020 at 11:22:45AM -0300, Otavio Salvador wrote:
On Fri, Apr 10, 2020 at 11:20 AM Carlos Rafael Giani
<crg7475@...> wrote:
Hm I thought there was some sort of imx-kernel base class. Apparently
there isn't. If there were, it could then be merged with the
linux-imx-headers recipe, and perhaps create something like a -dev package.

But then again, a -dev package from a kernel recipe ...? Kind of weird.
The problem is that you cannot mix packages / apps with different
versions of this. This ends being part of the binary ABI.
I understand it's a tricky topic as some packages won't build if the
kernel headers are not aligned. But I'm not sure it is better to have
packages building but having runtime issues because of mismatch...

Since our kernel is also used on other OSes we will not update its
headers. It also feels wrong to do so.
Add a patch to the layer for it.

Otavio, do you expect all the vendors to have their kernel matching
exactly the linux-imx-headers version?
Because looking at meta-freescale-3rdparty master branch [1], some
kernels are still based on 3.14...
and it is vendors consideration for their users. If they don't care,
who should care? We are starting removing broken boards and vendors
should pay attention to users.

There are two routes here:

- use mainline BSP
- use NXP BSP

for NXP BSP it comes with the need to keep upgrading it.


I personnaly think that the headers should be installed from the kernel
being built, then it's up to the vendor to check the compatibility but
at least that would fix the issue Carlos is seeing.
This does not help; those headers should not exists in first case but
as we do, a common base need to be used for all distro. Their symbols
goes to other libraries and apps so it cannot change between machines.

FYI, our next kernel release will be 5.4.3_1.0.0 as it is out since last
week. So if master stays with 4.19 we'll still have a mismatch I guess.
Will be going to 5.4 soon and people can help, patches welcome.

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


Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

On Fri, Apr 10, 2020 at 11:20 AM Carlos Rafael Giani
<crg7475@...> wrote:
Hm I thought there was some sort of imx-kernel base class. Apparently
there isn't. If there were, it could then be merged with the
linux-imx-headers recipe, and perhaps create something like a -dev package.

But then again, a -dev package from a kernel recipe ...? Kind of weird.
The problem is that you cannot mix packages / apps with different
versions of this. This ends being part of the binary ABI.

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


Re: linux-imx-headers and ioctl mismatches

Carlos Rafael Giani
 

Hm I thought there was some sort of imx-kernel base class. Apparently there isn't. If there were, it could then be merged with the linux-imx-headers recipe, and perhaps create something like a -dev package.

But then again, a -dev package from a kernel recipe ...? Kind of weird.

On 10.04.20 16:12, Otavio Salvador wrote:
On Fri, Apr 10, 2020 at 7:19 AM Carlos Rafael Giani <crg7475@...> wrote:
...
Just mentioning this here to discuss ideas. Perhaps it would make sense
to create a virtual/imx-headers package, or place the git repo URL as a
configurable variable?
This is not an easy problem. The issue is kinda similar of Linux ABI
and we can't use two different versions on same binary feed so we'd
need to mark it all as MACHINE_ARCH.

The easiest solution I can think of is do a backport of this change to
linux-boundary or they bump their kernel version.


Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

On Fri, Apr 10, 2020 at 7:19 AM Carlos Rafael Giani <crg7475@...> wrote:
...
Just mentioning this here to discuss ideas. Perhaps it would make sense
to create a virtual/imx-headers package, or place the git repo URL as a
configurable variable?
This is not an easy problem. The issue is kinda similar of Linux ABI
and we can't use two different versions on same binary feed so we'd
need to mark it all as MACHINE_ARCH.

The easiest solution I can think of is do a backport of this change to
linux-boundary or they bump their kernel version.


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


linux-imx-headers and ioctl mismatches

Carlos Rafael Giani
 

The linux-imx-headers recipe gathers certain headers from the kernel source so that other recipes which do access these headers don't have to mark the entire kernel as a dependency.

However, if a platform doesn't actually use linux-imx as its kernel, or at least uses a kernel release version that differs from that of linux-imx, ioctl mismatches can occur.

Current example: linux-imx is at version 4.19 , while linux-boundary is at 4.14. The DMA_BUF_IOCTL_PHYS ioctl is defined in the uapi/dma-buf.h header in 4.14 as:

  #define DMA_BUF_IOCTL_PHYS      _IOW(DMA_BUF_BASE, 1, struct dma_buf_phys)

but in 4.19 as:

  #define DMA_BUF_IOCTL_PHYS      _IOW(DMA_BUF_BASE, 10, struct dma_buf_phys)

This leads to Boundary Devices platforms that can't handle this ioctl properly because of the definition mismatch.

Just mentioning this here to discuss ideas. Perhaps it would make sense to create a virtual/imx-headers package, or place the git repo URL as a configurable variable?


Re: Mainline 5.4 kernel with VPU acceleration on iMX6

Fabio Estevam
 

Hi Andreas,

On Tue, Apr 7, 2020 at 5:44 AM Andreas Müller <schnitzeltony@...> wrote:

Have no use case currently so just out of curiosity: Does this also
apply to community kernels - do they support vpu-acceleration?
Not sure what you mean by "community kernel", but any recent kernel
from kernel.org (such as 5.4.x, 5.5.x, 5.6.x) support VPU acceleration
on i.MX6.

Regards,

Fabio Estevam


Re: Mainline 5.4 kernel with VPU acceleration on iMX6

Andreas Müller
 

On Mon, Apr 6, 2020 at 9:51 PM Fabio Estevam <festevam@...> wrote:

Hi Mark,

On Sun, Apr 5, 2020 at 7:17 PM Mark Farver <mfarver@...> wrote:

On Sun, Apr 5, 2020 at 1:19 AM Carlos Rafael Giani <crg7475@...> wrote:
For using etnaviv, just use glimagesink. For using the VPU, use the v4l2*dec elements.
Definitely doing CPU decoding. I don't see any kernel messages that
indicate the VPU has been detected even though I have
Try grepping for "coda", which is the VPU driver name in mainline:

# dmesg | grep coda
[ 5.483623] coda 2040000.vpu: Direct firmware load for
vpu_fw_imx6q.bin failed with error -2
[ 5.492236] coda 2040000.vpu: Falling back to sysfs fallback for:
vpu_fw_imx6q.bin
[ 69.619815] coda 2040000.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
[ 69.632736] coda 2040000.vpu: Firmware code revision: 46076
[ 69.638440] coda 2040000.vpu: Initialized CODA960.
[ 69.643255] coda 2040000.vpu: Firmware version: 3.1.1
[ 69.649875] coda 2040000.vpu: encoder registered as video9
[ 69.656045] coda 2040000.vpu: encoder registered as video10
[ 69.662214] coda 2040000.vpu: decoder registered as video11

CONFIG_VIDEO_IMX_PXP=y in the kernel config. Is that the correct
CONFIG_VIDEO_IMX_PXP=y applies to other i.MX SoCs.

option? Are there others? The device tree entry for the VPU seems to
be included in the kernel configuration by default.

I grabbed OSSystems meta-gstreamer layer to get 1.16.2, but even with
that included I do not appear to get any v4l2 decode plugins:

# gst-inspect-1.0 --version
gst-inspect-1.0 version 1.16.2
GStreamer 1.16.2
Unknown package origi

# gst-inspect-1.0 |grep v4l
imxv4l2video: imxv4l2videosrc: V4L2 CSI Video Source
imxv4l2video: imxv4l2videosink: V4L2 CSI Video Sink
This is wrong. You should not install these imx elements when using a
mainline kernel. These elements are to be used with NXP kernel only.
Have no use case currently so just out of curiosity: Does this also
apply to community kernels - do they support vpu-acceleration?

Andreas


Re: Mainline 5.4 kernel with VPU acceleration on iMX6

Fabio Estevam
 

Hi Mark,

On Sun, Apr 5, 2020 at 7:17 PM Mark Farver <mfarver@...> wrote:

On Sun, Apr 5, 2020 at 1:19 AM Carlos Rafael Giani <crg7475@...> wrote:
For using etnaviv, just use glimagesink. For using the VPU, use the v4l2*dec elements.
Definitely doing CPU decoding. I don't see any kernel messages that
indicate the VPU has been detected even though I have
Try grepping for "coda", which is the VPU driver name in mainline:

# dmesg | grep coda
[ 5.483623] coda 2040000.vpu: Direct firmware load for
vpu_fw_imx6q.bin failed with error -2
[ 5.492236] coda 2040000.vpu: Falling back to sysfs fallback for:
vpu_fw_imx6q.bin
[ 69.619815] coda 2040000.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
[ 69.632736] coda 2040000.vpu: Firmware code revision: 46076
[ 69.638440] coda 2040000.vpu: Initialized CODA960.
[ 69.643255] coda 2040000.vpu: Firmware version: 3.1.1
[ 69.649875] coda 2040000.vpu: encoder registered as video9
[ 69.656045] coda 2040000.vpu: encoder registered as video10
[ 69.662214] coda 2040000.vpu: decoder registered as video11

CONFIG_VIDEO_IMX_PXP=y in the kernel config. Is that the correct
CONFIG_VIDEO_IMX_PXP=y applies to other i.MX SoCs.

option? Are there others? The device tree entry for the VPU seems to
be included in the kernel configuration by default.

I grabbed OSSystems meta-gstreamer layer to get 1.16.2, but even with
that included I do not appear to get any v4l2 decode plugins:

# gst-inspect-1.0 --version
gst-inspect-1.0 version 1.16.2
GStreamer 1.16.2
Unknown package origi

# gst-inspect-1.0 |grep v4l
imxv4l2video: imxv4l2videosrc: V4L2 CSI Video Source
imxv4l2video: imxv4l2videosink: V4L2 CSI Video Sink
This is wrong. You should not install these imx elements when using a
mainline kernel. These elements are to be used with NXP kernel only.

video4linux2: v4l2src: Video (video4linux2) Source
video4linux2: v4l2sink: Video (video4linux2) Sink
video4linux2: v4l2radio: Radio (video4linux2) Tuner
video4linux2: v4l2deviceprovider (GstDeviceProviderFactory)
So first, make sure the coda driver is probed successfully in the kernel.

Then Gstreamer would detect the VPU decoders plugins:

# gst-inspect-1.0 | grep v4l2
video4linux2: v4l2src: Video (video4linux2) Source
video4linux2: v4l2sink: Video (video4linux2) Sink
video4linux2: v4l2radio: Radio (video4linux2) Tuner
video4linux2: v4l2deviceprovider (GstDeviceProviderFactory)
video4linux2: v4l2convert: V4L2 Video Converter
video4linux2: v4l2jpegenc: V4L2 JPEG Encoder
video4linux2: v4l2h264enc: V4L2 H.264 Encoder
video4linux2: v4l2mpeg4enc: V4L2 MPEG4 Encoder
video4linux2: v4l2mpeg4dec: V4L2 MPEG4 Decoder
video4linux2: v4l2mpeg2dec: V4L2 MPEG2 Decoder
video4linux2: v4l2h264dec: V4L2 H264 Decoder


Re: Mainline 5.4 kernel with VPU acceleration on iMX6

Mark Farver
 

On Sun, Apr 5, 2020 at 1:19 AM Carlos Rafael Giani <crg7475@...> wrote:
For using etnaviv, just use glimagesink. For using the VPU, use the v4l2*dec elements.
Definitely doing CPU decoding. I don't see any kernel messages that
indicate the VPU has been detected even though I have
CONFIG_VIDEO_IMX_PXP=y in the kernel config. Is that the correct
option? Are there others? The device tree entry for the VPU seems to
be included in the kernel configuration by default.

I grabbed OSSystems meta-gstreamer layer to get 1.16.2, but even with
that included I do not appear to get any v4l2 decode plugins:

# gst-inspect-1.0 --version
gst-inspect-1.0 version 1.16.2
GStreamer 1.16.2
Unknown package origi

# gst-inspect-1.0 |grep v4l
imxv4l2video: imxv4l2videosrc: V4L2 CSI Video Source
imxv4l2video: imxv4l2videosink: V4L2 CSI Video Sink
video4linux2: v4l2src: Video (video4linux2) Source
video4linux2: v4l2sink: Video (video4linux2) Sink
video4linux2: v4l2radio: Radio (video4linux2) Tuner
video4linux2: v4l2deviceprovider (GstDeviceProviderFactory)

Thank you
Mark Farver


Re: Mainline 5.4 kernel with VPU acceleration on iMX6

Carlos Rafael Giani
 

etnaviv takes care of GPU support, which is related to scaling, but unrelated to video decoding - the latter one is handled by the CODA960 VPU.

For using etnaviv, just use glimagesink. For using the VPU, use the v4l2*dec elements.

On 05.04.20 01:31, Mark Farver wrote:
Does anyone know definitively if etnaviv/gstreamer has support for
accelerated h264 decoding/rescaling?  I can play video through both
the fbcondev and wayland sinks, but both consume a great deal of CPU,
and frame dropping gets pretty bad if I attempt to resize the video.

I need to know if I should continue pursuing etnaviv, or if it is a
dead end for now and I need to fall back to using the vivante driver.


    


Mainline 5.4 kernel with VPU acceleration on iMX6

Mark Farver
 

Does anyone know definitively if etnaviv/gstreamer has support for
accelerated h264 decoding/rescaling? I can play video through both
the fbcondev and wayland sinks, but both consume a great deal of CPU,
and frame dropping gets pretty bad if I attempt to resize the video.

I need to know if I should continue pursuing etnaviv, or if it is a
dead end for now and I need to fall back to using the vivante driver.


IMX Gstreamer and image overlay

Mauro Ziliani
 

Hi all.


I need to mask a v4l2 stream with a png image.

I do that applying gdkpixbufoverlay before final imxv4l2sink, but the stream is very slow and a lot of frames are lost.ù


There is way to mask the stream using IPU or other hardware processor?


The board is equiped with imx6dl


This is the actual pipeline

#!/bin/sh

gst-launch-1.0 imxv4l2src device=/dev/video0 \
        ! capsfilter caps="video/x-raw, width=640, height=480" \
        ! imxvideoconvert_g2d rotation=4 \
        ! gdkpixbufoverlay location=mask.png \
        ! imxv4l2sink overlay-width=800 overlay-height=600 overlay-left=235 overlay-top=65 enable-last-sample=true name=sink


Best regards,

  MZ


Re: CVE related consulting on linux-qoriq

Zhenhua Luo
 

Yes, the CVE fixes are integrated in SDK kernel, the patch of CVE-2019-14814 will be included in the next LSDK which will be available in this April.


Best Regards,

Zhenhua

-----Original Message-----
From: zangrc <zangrc.fnst@...>
Sent: Friday, March 27, 2020 11:22 AM
To: Zhenhua Luo <zhenhua.luo@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] CVE related consulting on linux-qoriq

Hi,
Our team found that there are currently some CVE patches on some branches
that are also applicable to other branches. May I ask if NXP has any
corresponding measures to deal with this situation.
E.g:
CVE-2019-14814 has been fixed on the v5.3 branch and is not fixed on v4.19. But
it also should be applied to v4.19.

Best Regards,
Zang Ruochen
On 3/25/20 11:54 AM, Zhenhua Luo wrote:
Hi Ruochen,

Are those CVE patches developed for kernel tree or meta-freescale layer? May
I know which kernel version you are working? I can check the process.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of zangrc via
Lists.Yoctoproject.Org
Sent: Wednesday, March 25, 2020 11:36 AM
To: meta-freescale@...
Cc: meta-freescale@...
Subject: [meta-freescale] CVE related consulting on linux-qoriq

Hi,

Our team is going to work on the CVE correction of linux-qoriq.
I wonder if we submit such patches, will they be merged? If yes,
which ML should I send?

Best Regards,
Zang Ruochen


Re: CVE related consulting on linux-qoriq

zangrc
 

Hi,
Our team found that there are currently some CVE patches on some branches that are also applicable to other branches. May I ask if NXP has any corresponding measures to deal with this situation.
E.g:
CVE-2019-14814 has been fixed on the v5.3 branch and is not fixed on v4.19. But it also should be applied to v4.19.

Best Regards,
Zang Ruochen

On 3/25/20 11:54 AM, Zhenhua Luo wrote:
Hi Ruochen,

Are those CVE patches developed for kernel tree or meta-freescale layer? May I know which kernel version you are working? I can check the process.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of zangrc via
Lists.Yoctoproject.Org
Sent: Wednesday, March 25, 2020 11:36 AM
To: meta-freescale@...
Cc: meta-freescale@...
Subject: [meta-freescale] CVE related consulting on linux-qoriq

Hi,

Our team is going to work on the CVE correction of linux-qoriq.
I wonder if we submit such patches, will they be merged? If yes, which ML
should I send?

Best Regards,
Zang Ruochen


Re: imx-vpuwrap_4.5.4 error

nus1998
 

Looks that is fixed, thanks


Nus


At 2020-03-27 04:29:05, "Tom Hochstein" <tom.hochstein@...> wrote:
>Sorry for the trouble. Lauren has fixed imx-vpuwrap and is building to make sure there are no other problems.
>
>Tom
>
>-----Original Message-----
>From: Otavio Salvador <otavio.salvador@...> 
>Sent: Thursday, March 26, 2020 7:37 AM
>To: nus1998 <nus1998@...>; Tom Hochstein <tom.hochstein@...>; Lauren Post <lauren.post@...>
>Cc: meta-freescale@...
>Subject: Re: [meta-freescale] imx-vpuwrap_4.5.4 error
>
>+ Tom and Lauren
>
>On Thu, Mar 26, 2020 at 4:20 AM nus1998 <nus1998@...> wrote:
>>
>> Hi,
>>
>> It seems that "git://github.com/NXP/vpu_wrapper.git" is broken which is the source url used by imx-vpuwrap_4.5.4.bb in zeus branch : imx-5.4.3-2.0.0.xml.
>> and FSL_MIRROR has no imx-vpuwrap-4.5.4.bin too (the newest is 4.5.3), I wonder is there a alternative URL available or workaround for this?
>>
>> Thanks
>> Nus
>


Re: imx-vpuwrap_4.5.4 error

Tom Hochstein
 

Sorry for the trouble. Lauren has fixed imx-vpuwrap and is building to make sure there are no other problems.

Tom

-----Original Message-----
From: Otavio Salvador <otavio.salvador@...>
Sent: Thursday, March 26, 2020 7:37 AM
To: nus1998 <nus1998@...>; Tom Hochstein <tom.hochstein@...>; Lauren Post <lauren.post@...>
Cc: meta-freescale@...
Subject: Re: [meta-freescale] imx-vpuwrap_4.5.4 error

+ Tom and Lauren

On Thu, Mar 26, 2020 at 4:20 AM nus1998 <nus1998@...> wrote:

Hi,

It seems that "git://github.com/NXP/vpu_wrapper.git" is broken which is the source url used by imx-vpuwrap_4.5.4.bb in zeus branch : imx-5.4.3-2.0.0.xml.
and FSL_MIRROR has no imx-vpuwrap-4.5.4.bin too (the newest is 4.5.3), I wonder is there a alternative URL available or workaround for this?

Thanks
Nus


Re: imx-vpuwrap_4.5.4 error

Otavio Salvador
 

+ Tom and Lauren

On Thu, Mar 26, 2020 at 4:20 AM nus1998 <nus1998@...> wrote:

Hi,

It seems that "git://github.com/NXP/vpu_wrapper.git" is broken which is the source url used by imx-vpuwrap_4.5.4.bb in zeus branch : imx-5.4.3-2.0.0.xml.
and FSL_MIRROR has no imx-vpuwrap-4.5.4.bin too (the newest is 4.5.3), I wonder is there a alternative URL available or workaround for this?

Thanks
Nus
--
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


imx-vpuwrap_4.5.4 error

nus1998
 

Hi,

It seems that "git://github.com/NXP/vpu_wrapper.git" is broken which is the source url used by imx-vpuwrap_4.5.4.bb in zeus branch : imx-5.4.3-2.0.0.xml.
and FSL_MIRROR has no imx-vpuwrap-4.5.4.bin too (the newest is 4.5.3), I wonder is there a alternative URL available or workaround for this?

Thanks
Nus


Re: CVE related consulting on linux-qoriq

Zhenhua Luo
 

Hi Ruochen,

Are those CVE patches developed for kernel tree or meta-freescale layer? May I know which kernel version you are working? I can check the process.


Best Regards,

Zhenhua

-----Original Message-----
From: meta-freescale@... <meta-
freescale@...> On Behalf Of zangrc via
Lists.Yoctoproject.Org
Sent: Wednesday, March 25, 2020 11:36 AM
To: meta-freescale@...
Cc: meta-freescale@...
Subject: [meta-freescale] CVE related consulting on linux-qoriq

Hi,

Our team is going to work on the CVE correction of linux-qoriq.
I wonder if we submit such patches, will they be merged? If yes, which ML
should I send?

Best Regards,
Zang Ruochen


CVE related consulting on linux-qoriq

zangrc
 

Hi,

Our team is going to work on the CVE correction of linux-qoriq.
I wonder if we submit such patches, will they be merged? If yes, which ML should I send?

Best Regards,
Zang Ruochen

561 - 580 of 24855