Date   

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


Root filesystem missing

Mark Farver
 

Trying to get linux-fslc-imx running on a new custom carrier board
running a Karo-8133 module and I'm stuck trying to get the root
filesystem to detect.

Trying different things the boot process can never find the root
filesystem, though I can ext2ls it just fine from within u-Boot.

Waiting for root device PARTUUID=0cc66cc0-02...

Drivers for SD and EXT2/4 filesystems are in the kernel. I found some
stuff that seem to imply there was some naming aliasing going on in
the imx kernel that might explain this:

sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
imx6dl-pinctrl 20e0000.iomuxc: unable to find group for node usdhc2grp
imx6dl-pinctrl 20e0000.iomuxc: unable to find group for node usdhc2grp
sdhci-esdhc-imx: probe of 2194000.usdhc failed with error -22
imx6dl-pinctrl 20e0000.iomuxc: unable to find group for node usdhc4grp
imx6dl-pinctrl 20e0000.iomuxc: unable to find group for node usdhc4grp
sdhci-esdhc-imx: probe of 219c000.usdhc failed with error -22

Any suggestions on debugging this problem? Does the aliasing mean I
should use other names for the pinctrl entries?

Alternatively, is there a kernel and etnaviv driver combination that I
should be using instead with Rocko?


Re: data abort compiling u-boot with GCC != 6.4

Max Krummenacher
 

Hi

Have a look here:
https://www.yoctoproject.org/pipermail/yocto/2018-March/040486.html

So either update your U-Boot to something newer, cherry-pick the mentioned commit from upstream U-
Boot or pin the compiler to gcc 6.4.

Max

Am Dienstag, den 17.03.2020, 10:28 -0700 schrieb Federico Giovanardi:

I'm getting a data-abort exception every time i access the FEC ethernet device from u-boot; it
happens using tftp or just ping.


=> ping 172.31.4.2
Using FEC device
data abort
pc : [<4ffd769c>] lr : [<4ffd8960>]
reloc pc : [<1782d69c>] lr : [<1782e960>]
sp : 4f5a7d00 ip : 0000006a fp : 4ffb427c
r10: 00000000 r9 : 4f5a7eb8 r8 : 4ffee74c
r7 : 00000001 r6 : 00000000 r5 : 0000002a r4 : 4ffec94e
r3 : 14000045 r2 : 01041fac r1 : 02041fac r0 : 4ffec94e
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
With the same source everything works fine just switching the compiler.

I'm using u-boot 2016-07, almost not customized except for a pin used to keep the board up.
For now I've tested with:

arm-poky-linux-gnueabi-gcc 9.2 -> FAIL
arm-poky-linux-gnueabi-gcc 7.3 -> FAIL
arm-poky-linux-gnueabi-gcc 6.4 -> OK

all the toolchain are generated using yocto and are know to be working correctly.
U-boot is compiled with:


CROSS_COMPILE=/opt/poky-arag/2.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-
gnueabi/arm-poky-linux-gnueabi-

make mrproper
make ARCH=arm CROSS_COMPILE=$CROSS_COMPILE delta70_defconfig
make ARCH=arm CROSS_COMPILE=$CROSS_COMPILE
without environment variables affecting compilation, build host is arch linux just updated, I've
tried also in an ubuntu 16.04 chroot
but with the same result.

Any clue?

Regards.
Federico Giovanardi


data abort compiling u-boot with GCC != 6.4

Federico Giovanardi
 

I'm getting a data-abort exception every time i access the FEC ethernet device from u-boot; it happens using tftp or just ping.
=> ping 172.31.4.2
Using FEC device
data abort
pc : [<4ffd769c>]          lr : [<4ffd8960>]
reloc pc : [<1782d69c>]    lr : [<1782e960>]
sp : 4f5a7d00  ip : 0000006a     fp : 4ffb427c
r10: 00000000  r9 : 4f5a7eb8     r8 : 4ffee74c
r7 : 00000001  r6 : 00000000     r5 : 0000002a  r4 : 4ffec94e
r3 : 14000045  r2 : 01041fac     r1 : 02041fac  r0 : 4ffec94e
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...
With the same source everything works fine just switching the compiler.

I'm using u-boot 2016-07, almost not customized except for a pin used to keep the board up.
For now I've tested with:

arm-poky-linux-gnueabi-gcc 9.2   -> FAIL
arm-poky-linux-gnueabi-gcc 7.3   -> FAIL
arm-poky-linux-gnueabi-gcc 6.4   -> OK

all the toolchain are generated using yocto and are know to be working correctly.
U-boot is compiled with:

CROSS_COMPILE=/opt/poky-arag/2.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-
make mrproper
make ARCH=arm CROSS_COMPILE=$CROSS_COMPILE delta70_defconfig
make ARCH=arm CROSS_COMPILE=$CROSS_COMPILE
without environment variables affecting compilation, build host is arch linux just updated, I've tried also in an ubuntu 16.04 chroot
but with the same result.

Any clue?

Regards.
Federico Giovanardi


Re: Use Wayland for a single application fullscreen without window decoration

Clay Montgomery
 

Hi Christian,

   My Lightwing application runs OpenGL ES full-screen only. I found that you really don't have to use Wayland, but just use the lower-level DRM (Display Resource Manager) API, instead.

   I have not used Qt for years, but I remember its window manager used to have a "no decoration" build option.

Regards, Clay


On 3/4/2020 3:29 AM, Christian Lohr wrote:

Hello,

 

I have a Variscite Dart i.MX8M (this Model: http://variwiki.com/index.php?title=DART-MX8M) and I want to run a single application (Qt) without window decoration, and it should run in fullscreen mode. I’ve also read that EGLFS with i.MX8 is no more supported (this was my preferred solution), and only Wayland or XWayland is possible. This Wayland/Weston topic is completely new to me. Is there a more detailed description how to get it running? Do I have to use Weston Compositor, or should I use a different compositor?

I’ve read through this : https://wiki.yoctoproject.org/wiki/Wayland , but I didn’t find a solution for my problem. Is there anybody who already did this?

 

Best regards,

 

 

Christian Lohr

Im Auftrag von:

Carl Zeiss Meditec AG
Göschwitzer Strasse 51-52

07745 Jena, Deutschland

christian.lohr.ext@...

Tel: +493641220206

 

 

 



    

561 - 580 of 24851