1. Meta-Freescale
  2. Messages

Expanded

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

				
				
				
			

			
			

				
	

	

	
	

		
			

				
					

					

				
				

					

						
						
					

				

			

			

				

					

				

			

			
			
				

	



		
			
		
	

	
	

		
		
		
		
		
	

	

		
		
		
		
		
	

	
	

		
		
		
		
	



	

		

			
	
		

			

				

					
						
							601 - 620 of 24914