Date   

Re: drivers/net/nfc directory removed from imx-4.14.98-2.0.0_ga

nus1998
 

Sorry It's prefix is net but not drivers/net, so it is there...


Nus

At 2020-04-20 10:03:56, "nus1998" <nus1998@...> wrote:

Hi All,

When I build NXP nfc driver, I got a error that some unknown symbol, after tracing the code, I found there is no nfc hci driver while in mailline linux kernel 4.14.98 contains it in net/drivers/nfc.
I want to know why iMX removed this directory and where these functions are implemented.

B.R.
Nus


drivers/net/nfc directory removed from imx-4.14.98-2.0.0_ga

nus1998
 

Hi All,

When I build NXP nfc driver, I got a error that some unknown symbol, after tracing the code, I found there is no nfc hci driver while in mailline linux kernel 4.14.98 contains it in net/drivers/nfc.
I want to know why iMX removed this directory and where these functions are implemented.

B.R.
Nus


Re: Error while trying to build a nitrogen8m image with yocto master

Carlos Rafael Giani
 

Thanks, that fixed it. I'll send a PR.

On 19.04.20 10:45, Andrey Zhizhikin wrote:
On Sun, Apr 19, 2020 at 10:33 AM Carlos Rafael Giani
<crg7475@...> wrote:
I tried to build a nitrogen8m image with the current master branches of
poky, meta-freescale, meta-freescale-3rdparty, and meta-openembedded.
However, I immediately got this error:

 > Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto} nitrogen8m) for DEFAULTTUNE
(cortexa53-crypto) does not contain TUNE_PKGARCH
(${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64',
'${ARMPKGARCH_tune-cortexa53-crypto}' ,d)}).Toolchain tunings invalid:
 > Tuning 'cortexa53-crypto' has no defined features, and cannot be used.

This goes beyond my Yocto knowledge. Why are no features defined?
meta/conf/machine/include/tune-cortexa53.inc does define features.
It is that the nitrogen8m does not have that tune file included.
Instead, it uses a more generic
[conf/machine/include/arm/arch-arm64.inc] tune file, which should be
replaced with the [/conf/machine/include/tune-cortexa53.inc]. In fact,
all nitrogen8m* derivatives lacks this tune and uses generic.

You can replace the [require conf/machine/include/arm/arch-arm64.inc]
with [require conf/machine/include/tune-cortexa53.inc] for all
meta-freescale-3rdparty/conf/machine/nitrogen8m*.conf machines and
send a PR.

Has anybody else got this error?

I was successful with building an image for the imx8mmevk machine.






    


Re: Error while trying to build a nitrogen8m image with yocto master

Andrey Zhizhikin
 

On Sun, Apr 19, 2020 at 10:33 AM Carlos Rafael Giani
<crg7475@...> wrote:

I tried to build a nitrogen8m image with the current master branches of
poky, meta-freescale, meta-freescale-3rdparty, and meta-openembedded.
However, I immediately got this error:

> Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto} nitrogen8m) for DEFAULTTUNE
(cortexa53-crypto) does not contain TUNE_PKGARCH
(${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64',
'${ARMPKGARCH_tune-cortexa53-crypto}' ,d)}).Toolchain tunings invalid:
> Tuning 'cortexa53-crypto' has no defined features, and cannot be used.

This goes beyond my Yocto knowledge. Why are no features defined?
meta/conf/machine/include/tune-cortexa53.inc does define features.
It is that the nitrogen8m does not have that tune file included.
Instead, it uses a more generic
[conf/machine/include/arm/arch-arm64.inc] tune file, which should be
replaced with the [/conf/machine/include/tune-cortexa53.inc]. In fact,
all nitrogen8m* derivatives lacks this tune and uses generic.

You can replace the [require conf/machine/include/arm/arch-arm64.inc]
with [require conf/machine/include/tune-cortexa53.inc] for all
meta-freescale-3rdparty/conf/machine/nitrogen8m*.conf machines and
send a PR.


Has anybody else got this error?

I was successful with building an image for the imx8mmevk machine.



--
Regards,
Andrey.


Error while trying to build a nitrogen8m image with yocto master

Carlos Rafael Giani
 

I tried to build a nitrogen8m image with the current master branches of poky, meta-freescale, meta-freescale-3rdparty, and meta-openembedded. However, I immediately got this error:

Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto} nitrogen8m) for DEFAULTTUNE (cortexa53-crypto) does not contain TUNE_PKGARCH (${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64', '${ARMPKGARCH_tune-cortexa53-crypto}' ,d)}).Toolchain tunings invalid:
Tuning 'cortexa53-crypto' has no defined features, and cannot be used.
This goes beyond my Yocto knowledge. Why are no features defined? meta/conf/machine/include/tune-cortexa53.inc does define features.

Has anybody else got this error?

I was successful with building an image for the imx8mmevk machine.


Re: gst-play looks abnormal

nus1998
 


As I encountered severals issues on zeus, I decided to rollback and paid couple days to download/build sumo imx-4.14.98_2.0.0_ga.xml (actually 2.0.1_patch.xml), but I'm curious why it CANNOT pass the build in default settings.

First, I must modify SDCARD_ROOTFS ?= "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.ext4" in sources/meta-fsl-bsp-release/imx/meta-bsp/conf/machine/include/imx-base.inc to generate image, otherwise error encountered.

Second issue is out of default setting but is common feature too, the linux-imx LOCALVERSION contains '_' which leading to build failure as deb package packing doesn't allow it.

Now I wonder which release should I choose to develop on...

B.R.
Nus


At 2020-04-15 10:56:40, "nus1998" <nus1998@...> wrote:

Well, where can I found the known issues on this release? as for this gst issue, I found on it works normally on imxv4l2sink, on waylandsink the display looks OK but the performance is only 1.X frames/second. if there are few issues on the features what we used, we suppose to continue to use it, otherwise we might to turn to an old release.

BTW: is the last fully tested release imx-4.14.98-2.0.0_ga.xml?


B.R.
Nus


在 2020-04-15 00:17:42,"Tom Hochstein" <tom.hochstein@...> 写道:

Sorry, Nus, this is a known issue in this release. Please note that the 5.4.3-2.0.0 release was a targeted release for 8MP/8DXL Alpha and 8QXPC0 Beta. Due to resource constraints, 6DL was not fully tested.

 

The next release in Q2 will also be a targeted release but should have this fixed. We’re currently looking at Q3 for a fully tested release.

 

Tom

 

From: meta-freescale@... <meta-freescale@...> On Behalf Of nus1998 via lists.yoctoproject.org
Sent: Monday, April 13, 2020 9:35 PM
To: meta-freescale@...
Subject: Re: [meta-freescale] gst-play looks abnormal

 

Hi All,

 

Any tips that I can trace the issue? there are many binary libraries involved makes it difficult to debug...

 

PS: "alloc_contig_range: [X, Y) PFNs busy" is not the root issue as I changed a low profile test video, this message is disappeared but there is no difference on display. and I'm confused why stream shows the height is 1088? the source height is 1080.

 

B.R.

Nus

At 2020-04-13 20:55:12, "nus1998" <nus1998@...> wrote:

Hi All,

 

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

 

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03  build on Oct 16 2019 06:53:44
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO]  Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO]  bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper  build on Dec  7 2017 18:13:49
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Sep 20 2017 15:02:14.
[WARN]  VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI :
file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
  (nil)
All Stream information
 Stream # 0
  type : video_0
  taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
 Stream # 1
  type : audio_0
  taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

All video streams
 video_0 #
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1

All audio streams:
 audio_0 #
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

Current video track:
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
Current audio track:
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).

 

On PC:

 

On i.MX6DL (2GB RAM)

 

B.R.

Nus


Re: gst-play looks abnormal

nus1998
 

Hi,

I don't know whether it is a known issue:

when running traditional qt application based on widget like animatedtiles example, the performance is terrible and even worse than i.MX25 (ARM9 without opengl), but running on qml engine it looks good.
the build target is default xwayland and so the qpa plugin is wayland-gl.


Nus


在 2020-04-15 10:56:40,"nus1998" <nus1998@...> 写道:

Well, where can I found the known issues on this release? as for this gst issue, I found on it works normally on imxv4l2sink, on waylandsink the display looks OK but the performance is only 1.X frames/second. if there are few issues on the features what we used, we suppose to continue to use it, otherwise we might to turn to an old release.

BTW: is the last fully tested release imx-4.14.98-2.0.0_ga.xml?


B.R.
Nus


在 2020-04-15 00:17:42,"Tom Hochstein" <tom.hochstein@...> 写道:

Sorry, Nus, this is a known issue in this release. Please note that the 5.4.3-2.0.0 release was a targeted release for 8MP/8DXL Alpha and 8QXPC0 Beta. Due to resource constraints, 6DL was not fully tested.

 

The next release in Q2 will also be a targeted release but should have this fixed. We’re currently looking at Q3 for a fully tested release.

 

Tom

 

From: meta-freescale@... <meta-freescale@...> On Behalf Of nus1998 via lists.yoctoproject.org
Sent: Monday, April 13, 2020 9:35 PM
To: meta-freescale@...
Subject: Re: [meta-freescale] gst-play looks abnormal

 

Hi All,

 

Any tips that I can trace the issue? there are many binary libraries involved makes it difficult to debug...

 

PS: "alloc_contig_range: [X, Y) PFNs busy" is not the root issue as I changed a low profile test video, this message is disappeared but there is no difference on display. and I'm confused why stream shows the height is 1088? the source height is 1080.

 

B.R.

Nus

At 2020-04-13 20:55:12, "nus1998" <nus1998@...> wrote:

Hi All,

 

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

 

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03  build on Oct 16 2019 06:53:44
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO]  Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO]  bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper  build on Dec  7 2017 18:13:49
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Sep 20 2017 15:02:14.
[WARN]  VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI :
file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
  (nil)
All Stream information
 Stream # 0
  type : video_0
  taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
 Stream # 1
  type : audio_0
  taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

All video streams
 video_0 #
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1

All audio streams:
 audio_0 #
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

Current video track:
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
Current audio track:
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).

 

On PC:

 

On i.MX6DL (2GB RAM)

 

B.R.

Nus


Re: gst-play looks abnormal

nus1998
 

Well, where can I found the known issues on this release? as for this gst issue, I found on it works normally on imxv4l2sink, on waylandsink the display looks OK but the performance is only 1.X frames/second. if there are few issues on the features what we used, we suppose to continue to use it, otherwise we might to turn to an old release.

BTW: is the last fully tested release imx-4.14.98-2.0.0_ga.xml?


B.R.
Nus


在 2020-04-15 00:17:42,"Tom Hochstein" <tom.hochstein@...> 写道:

Sorry, Nus, this is a known issue in this release. Please note that the 5.4.3-2.0.0 release was a targeted release for 8MP/8DXL Alpha and 8QXPC0 Beta. Due to resource constraints, 6DL was not fully tested.

 

The next release in Q2 will also be a targeted release but should have this fixed. We’re currently looking at Q3 for a fully tested release.

 

Tom

 

From: meta-freescale@... <meta-freescale@...> On Behalf Of nus1998 via lists.yoctoproject.org
Sent: Monday, April 13, 2020 9:35 PM
To: meta-freescale@...
Subject: Re: [meta-freescale] gst-play looks abnormal

 

Hi All,

 

Any tips that I can trace the issue? there are many binary libraries involved makes it difficult to debug...

 

PS: "alloc_contig_range: [X, Y) PFNs busy" is not the root issue as I changed a low profile test video, this message is disappeared but there is no difference on display. and I'm confused why stream shows the height is 1088? the source height is 1080.

 

B.R.

Nus

At 2020-04-13 20:55:12, "nus1998" <nus1998@...> wrote:

Hi All,

 

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

 

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03  build on Oct 16 2019 06:53:44
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO]  Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO]  bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper  build on Dec  7 2017 18:13:49
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Sep 20 2017 15:02:14.
[WARN]  VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI :
file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
  (nil)
All Stream information
 Stream # 0
  type : video_0
  taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
 Stream # 1
  type : audio_0
  taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

All video streams
 video_0 #
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1

All audio streams:
 audio_0 #
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

Current video track:
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
Current audio track:
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).

 

On PC:

 

On i.MX6DL (2GB RAM)

 

B.R.

Nus


Re: gst-play looks abnormal

Tom Hochstein
 

Sorry, Nus, this is a known issue in this release. Please note that the 5.4.3-2.0.0 release was a targeted release for 8MP/8DXL Alpha and 8QXPC0 Beta. Due to resource constraints, 6DL was not fully tested.

 

The next release in Q2 will also be a targeted release but should have this fixed. We’re currently looking at Q3 for a fully tested release.

 

Tom

 

From: meta-freescale@... <meta-freescale@...> On Behalf Of nus1998 via lists.yoctoproject.org
Sent: Monday, April 13, 2020 9:35 PM
To: meta-freescale@...
Subject: Re: [meta-freescale] gst-play looks abnormal

 

Hi All,

 

Any tips that I can trace the issue? there are many binary libraries involved makes it difficult to debug...

 

PS: "alloc_contig_range: [X, Y) PFNs busy" is not the root issue as I changed a low profile test video, this message is disappeared but there is no difference on display. and I'm confused why stream shows the height is 1088? the source height is 1080.

 

B.R.

Nus

At 2020-04-13 20:55:12, "nus1998" <nus1998@...> wrote:

Hi All,

 

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

 

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03  build on Oct 16 2019 06:53:44
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO]  Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO]  bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper  build on Dec  7 2017 18:13:49
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Sep 20 2017 15:02:14.
[WARN]  VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI :
file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
  (nil)
All Stream information
 Stream # 0
  type : video_0
  taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
 Stream # 1
  type : audio_0
  taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory :
www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

All video streams
 video_0 #
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1

All audio streams:
 audio_0 #
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

Current video track:
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
Current audio track:
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).

 

On PC:

 

On i.MX6DL (2GB RAM)

 

B.R.

Nus


Re: gst-play looks abnormal

nus1998
 

Hi All,

Any tips that I can trace the issue? there are many binary libraries involved makes it difficult to debug...

PS: "alloc_contig_range: [X, Y) PFNs busy" is not the root issue as I changed a low profile test video, this message is disappeared but there is no difference on display. and I'm confused why stream shows the height is 1088? the source height is 1080.

B.R.
Nus

At 2020-04-13 20:55:12, "nus1998" <nus1998@...> wrote:

Hi All,

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03  build on Oct 16 2019 06:53:44
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO]  Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO]  bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper  build on Dec  7 2017 18:13:49
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Sep 20 2017 15:02:14.
[WARN]  VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI : file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
  (nil)
All Stream information
 Stream # 0
  type : video_0
  taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory : www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
 Stream # 1
  type : audio_0
  taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory : www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

All video streams
 video_0 #
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1

All audio streams:
 audio_0 #
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

Current video track:
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
Current audio track:
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).


On PC:

On i.MX6DL (2GB RAM)

B.R.
Nus


gst-play looks abnormal

nus1998
 

Hi All,

Today I tested video playback by gst-play, the sound is perfect without any lag, but the display looks abnormal. when sliding pictures, the display looks good and the same board is no problem to play video by burning android image. both of yocto and android share the same DDR initial code, so I think it doesn't matter of DDR crosstalk. the yocto branch I used is imx-linux-zeus/imx-5.4.3-2.0.0.xml, the print message and photos are attached as below:

root@imx6dlsabresd:~# ./gst-play 1080p_t1.mp4
Volume: 100%
Now playing /home/root/1080p_t1.mp4
State changed: buffering

====== AIUR: 4.5.4 build on Mar 30 2020 12:56:38. ======
        Core: MPEG4PARSER_06.16.03  build on Oct 16 2019 06:53:44
 file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm11_elinux.so.3.2
------------------------
    Track 00 [video_0] Enabled
        Duration: 0:00:41.908333000
        Language: und
    Mime:
        video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)avc, width=(int)1920, height=(int)1080, framerate=(fraction)30000/1001, codec_data=(buffer)01640028ffe1001867640028acb403c0113f2e022000000c800002ed51e3065401000568cf32c8b0
------------------------
display(/dev/fb0) resolution is (800x480).
====== OVERLAYSINK: 4.5.4 build on Mar 30 2020 12:56:57. ======
display(/dev/fb0) resolution is (800x480).
[INFO]  Product Info: i.MX6Q/D/S
[[10299.304378] alloc_contig_range: [72400, 728ff) PFNs busy
INFO]   Product Info: i.MX6Q/D/S
=[10299.311635] alloc_contig_range: [72400, 729ff) PFNs busy
===== VPUDEC: 4.5.4 build on Mar [10299.320940] alloc_contig_range: [72400, 72aff) PFNs busy
30 2020 12:57:01. ======
        wrappe[10299.328919] alloc_contig_range: [72400, 72bff) PFNs busy
r: 3.0.0 (VPUWRAPPER_ARM_LINUX Bu[10299.336682] alloc_contig_range: [72800, 72cff) PFNs busy
ild on Mar 27 2020 10:21:40)
        vpulib: 5.4.38
        firmware: 3.1.1.46076
[INFO]  bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
------------------------
    Track 01 [audio_0] Enabled
        Duration: 0:00:42.026666000
        Language: und
    Mime:
        audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, bitrate=(int)124920, stream-format=(string)raw, codec_data=(buffer)1210
------------------------

====== BEEP: 4.5.4 build on Mar 30 2020 12:56:45. ======
        Core: AAC decoder Wrapper  build on Dec  7 2017 18:13:49
 file: /usr/lib/imx-mm/audio-codec/wrap/lib_aacd_wrap_arm12_elinux.so.3
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8  build on Sep 20 2017 15:02:14.
[WARN]  VPU iram is less than needed, some parts don't use iram
display(/dev/fb0) resolution is ([10299.742796] mxc_v4l2_output v4l2_out: Bypass IC.
800x480).
[10299.750303] mxc_v4l2_output v4l2_out: Bypass IC.

===!!! Current pulsesink device is alsa_output.platform-sound.stereo-fallback !!!===

[10300.098134] alloc_contig_range: [72880, 72900) PFNs busy
[10300.107275] alloc_contig_range: [72880, 72900) PFNs busy
[10300.116202] alloc_contig_range: [72880, 72900) PFNs busy
[10300.125512] alloc_contig_range: [72880, 72900) PFNs busy
[10300.134782] alloc_contig_range: [72880, 72900) PFNs busy
URI : file:///home/root/1080p_t1.mp4
Duration: 0:00:00.000000000
Global taglist:
  (nil)
All Stream information
 Stream # 0
  type : video_0
  taglist :
    codec : H.264/AVC
    language-code : und
    container-format : MOV/MP4/3GP
    application-name : FormatFactory : www.pcfreetime.com
    video-codec : H.264 (High Profile)
    audio-codec : AAC
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
 Stream # 1
  type : audio_0
  taglist :
    codec : AAC
    language-code : und
    bitrate : 3268
    container-format : MOV/MP4/3GP
    application-name : FormatFactory : www.pcfreetime.com
    video-codec : H.264/AVC
    audio-codec : AAC decoder
    minimum-bitrate : 3100
    maximum-bitrate : 3100
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

All video streams
 video_0 #
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1

All audio streams:
 audio_0 #
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)

Current video track:
  width : 1920
  height : 1088
  max_bitrate : -1
  bitrate : -1
  framerate : 29.97
  pixel-aspect-ratio  1:1
Current audio track:
  sample rate : 44100
  channels : 2
  max_bitrate : 3100
  bitrate : 3268
  language : (null)
Current subtitle track:
State changed: playing
0:00:42.0 / 0:00:42.0
Reached end of play list.
State changed: stopped
Total showed frames (1257), display master blited (1257), playing for (0:00:42.031174000), fps (29.906).


On PC:

On i.MX6DL (2GB RAM)

B.R.
Nus


Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

On Sat, Apr 11, 2020 at 7:05 PM Andrey Zhizhikin <andrey.z@...> wrote:
On Fri, Apr 10, 2020 at 8:46 PM Otavio Salvador
<otavio.salvador@...> wrote:

On Fri, Apr 10, 2020 at 3:43 PM Kevin Lannen <kevin@...> wrote:
I would be happy to help out some with moving linux-imx to the 5.4 kernel as we are very interested in using it. Is this planned to be in for the Dunfell branch when that is released?
It all depends how long it takes. Dunfell is an important release and as such we ought to try to have it using new components.
We need someone to help updating NXP components; I am focusing more on mainline BSP support since I've been doing this on our free time.
Is there a github issue or a list somewhere tracking what needs to be done for this?
No, even though we can open. Generally we need to update:

- linux-imx
- u-boot-imx
- headers
- gpu drivers
- media codecs
- gst
I'm currently working on this one, primarily for imx8mm and imx8mn
machines. So far, I have the following list I've noted for myself:
- linux-imx (with mfgtool)
- u-boot-imx
- linux-imx-headers
- kernel-module-imx-gpu-viv (gpu drivers)
- kernel-module-qca9377 (wlan drivers)
- imx-atf
- imx-mkimage
- imx-test
- optee-imx (client, os, test)
- media codecs
- gst (base, good, bad, gstreamer and imx-gst)

I'm almost through with it for the Mini, then would cross-check if
everything compiles for Nano. I would send a PR once both validations
are done.

Otavio,
One general question: Do we keep the 4.19.35 in the layer, or I can
simply drop it and introduce the 5.4.3? So far, I did just that and it
seems to be going OK.
Please drop.


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

Andrey Zhizhikin
 

On Fri, Apr 10, 2020 at 8:46 PM Otavio Salvador
<otavio.salvador@...> wrote:

On Fri, Apr 10, 2020 at 3:43 PM Kevin Lannen <kevin@...> wrote:
I would be happy to help out some with moving linux-imx to the 5.4 kernel as we are very interested in using it. Is this planned to be in for the Dunfell branch when that is released?
It all depends how long it takes. Dunfell is an important release and as such we ought to try to have it using new components.
We need someone to help updating NXP components; I am focusing more on mainline BSP support since I've been doing this on our free time.
Is there a github issue or a list somewhere tracking what needs to be done for this?
No, even though we can open. Generally we need to update:

- linux-imx
- u-boot-imx
- headers
- gpu drivers
- media codecs
- gst
I'm currently working on this one, primarily for imx8mm and imx8mn
machines. So far, I have the following list I've noted for myself:
- linux-imx (with mfgtool)
- u-boot-imx
- linux-imx-headers
- kernel-module-imx-gpu-viv (gpu drivers)
- kernel-module-qca9377 (wlan drivers)
- imx-atf
- imx-mkimage
- imx-test
- optee-imx (client, os, test)
- media codecs
- gst (base, good, bad, gstreamer and imx-gst)

I'm almost through with it for the Mini, then would cross-check if
everything compiles for Nano. I would send a PR once both validations
are done.

Otavio,
One general question: Do we keep the 4.19.35 in the layer, or I can
simply drop it and introduce the 5.4.3? So far, I did just that and it
seems to be going OK.


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


--
Regards,
Andrey.


Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

Carlos,

On Sat, Apr 11, 2020 at 7:32 AM Carlos Rafael Giani <crg7475@...> wrote:
This issue came up when I noticed that the ION and DWL allocators in libimxdmabuffer failed. (DWL is an API from the Hantro VPU libraries, and it fails, because internally it itself uses ION.)

This is the relevant code: https://github.com/Freescale/libimxdmabuffer/blob/master/imxdmabuffer/imxdmabuffer_ion_allocator.c#L428

I am now wondering if I can add some workaround to also support older kernels that are subject to such a header mismatch. An ugly workaround would be to manually define the IOCTL, like this:

#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 19, 0)
#define CUSTOM_DMA_BUF_IOCTL_PHYS _IOW(DMA_BUF_BASE, 1, struct dma_buf_phys)
#else
#define CUSTOM_DMA_BUF_IOCTL_PHYS DMA_BUF_IOCTL_PHYS
#endif

And then use the CUSTOM_DMA_BUF_IOCTL_PHYS instead of the regular DMA_BUF_IOCTL_PHYS in the code.
This does not work as the libimxdmabuffer is shared (and it should be)
across multiple machines of same SoC family. Considering that, the
best choice is to apply a patch to old Linux kernels to make it to use
the newer API/ABI with this backport.

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

This issue came up when I noticed that the ION and DWL allocators in libimxdmabuffer failed. (DWL is an API from the Hantro VPU libraries, and it fails, because internally it itself uses ION.)

This is the relevant code: https://github.com/Freescale/libimxdmabuffer/blob/master/imxdmabuffer/imxdmabuffer_ion_allocator.c#L428

I am now wondering if I can add some workaround to also support older kernels that are subject to such a header mismatch. An ugly workaround would be to manually define the IOCTL, like this:

  #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 19, 0)
  #define CUSTOM_DMA_BUF_IOCTL_PHYS      _IOW(DMA_BUF_BASE, 1, struct dma_buf_phys)
  #else
  #define CUSTOM_DMA_BUF_IOCTL_PHYS      DMA_BUF_IOCTL_PHYS
  #endif

And then use the CUSTOM_DMA_BUF_IOCTL_PHYS instead of the regular DMA_BUF_IOCTL_PHYS in the code.

Pro: This would make libimxdmabuffer work with existing setups, and could even be backported to zeus and warrior.

Con: Defining IOCTLs in userspace like this is usually not a good idea.

Comments?


On 10.04.20 16:22, 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.



    


Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

On Fri, Apr 10, 2020 at 3:43 PM Kevin Lannen <kevin@...> wrote:
I would be happy to help out some with moving linux-imx to the 5.4 kernel as we are very interested in using it. Is this planned to be in for the Dunfell branch when that is released?
It all depends how long it takes. Dunfell is an important release and as such we ought to try to have it using new components.
We need someone to help updating NXP components; I am focusing more on mainline BSP support since I've been doing this on our free time.
Is there a github issue or a list somewhere tracking what needs to be done for this?
No, even though we can open. Generally we need to update:

- linux-imx
- u-boot-imx
- headers
- gpu drivers
- media codecs
- gst

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

Kevin Lannen
 

I would be happy to help out some with moving linux-imx to the 5.4 kernel as we are very interested in using it. Is this planned to be in for the Dunfell branch when that is released?
It all depends how long it takes. Dunfell is an important release and as such we ought to try to have it using new components.
We need someone to help updating NXP components; I am focusing more on mainline BSP support since I've been doing this on our free time.
Is there a github issue or a list somewhere tracking what needs to be done for this?


Kevin Lannen

Embedded Systems Engineer
kevin@...
970-690-8619


Re: linux-imx-headers and ioctl mismatches

Otavio Salvador
 

On Fri, Apr 10, 2020 at 3:25 PM Kevin Lannen <kevin@...> wrote:
I would be happy to help out some with moving linux-imx to the 5.4 kernel as we are very interested in using it. Is this planned to be in for the Dunfell branch when that is released?
It all depends how long it takes. Dunfell is an important release and
as such we ought to try to have it using new components.

We need someone to help updating NXP components; I am focusing more on
mainline BSP support since I've been doing this on our free time.

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

Kevin Lannen
 

Hi Otavio,

I would be happy to help out some with moving linux-imx to the 5.4 kernel as we are very interested in using it. Is this planned to be in for the Dunfell branch when that is released?

Regards,


Kevin Lannen

Embedded Systems Engineer
kevin@...
970-690-8619

-----Original Message-----
From: meta-freescale@... <meta-freescale@...> On Behalf Of Otavio Salvador via lists.yoctoproject.org
Sent: Friday, April 10, 2020 11:52 AM
To: Gary Bisson <gary.bisson@...>
Cc: Carlos Rafael Giani <crg7475@...>; meta-freescale <meta-freescale@...>; Chris Dimich <chris.dimich@...>
Subject: Re: [meta-freescale] linux-imx-headers and ioctl mismatches

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

541 - 560 of 24854