|
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@...> 写道：
|
|
|
|
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@...> 写道：
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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 SalvadorPlease 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: 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.
-- 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 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) 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:
No, even though we can open. Generally we need to update: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? - 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,
toggle quoted messageShow quoted text
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:Add a patch to the layer for it.On Fri, Apr 10, 2020 at 11:20 AM Carlos Rafael GianiI understand it's a tricky topic as some packages won't build if the Otavio, do you expect all the vendors to have their kernel matchingand 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 theThis 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 sinceWill 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:Add a patch to the layer for it.On Fri, Apr 10, 2020 at 11:20 AM Carlos Rafael GianiI understand it's a tricky topic as some packages won't build if the Otavio, do you expect all the vendors to have their kernel matchingand 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 kernelThis 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 lastWill be going to 5.4 soon and people can help, patches welcome. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
|
|
|
|
Re: linux-imx-headers and ioctl mismatches
Otavio Salvador
On Fri, Apr 10, 2020 at 11:20 AM Carlos Rafael Giani
<crg7475@...> wrote: Hm I thought there was some sort of imx-kernel base class. ApparentlyThe problem is that you cannot mix packages / apps with different versions of this. This ends being part of the binary ABI. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
|
|
|
|
Re: linux-imx-headers and ioctl mismatches
Carlos Rafael Giani
Hm I thought there was some sort of imx-kernel base class. Apparently there isn't. If there were, it could then be merged with the linux-imx-headers recipe, and perhaps create something like a -dev package.
toggle quoted messageShow quoted text
But then again, a -dev package from a kernel recipe ...? Kind of weird.
On 10.04.20 16:12, Otavio Salvador wrote:
On Fri, Apr 10, 2020 at 7:19 AM Carlos Rafael Giani <crg7475@...> wrote:
|
|
|
|
Re: linux-imx-headers and ioctl mismatches
Otavio Salvador
On Fri, Apr 10, 2020 at 7:19 AM Carlos Rafael Giani <crg7475@...> wrote:
... Just mentioning this here to discuss ideas. Perhaps it would make senseThis is not an easy problem. The issue is kinda similar of Linux ABI and we can't use two different versions on same binary feed so we'd need to mark it all as MACHINE_ARCH. The easiest solution I can think of is do a backport of this change to linux-boundary or they bump their kernel version. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
|
|
|
|
linux-imx-headers and ioctl mismatches
Carlos Rafael Giani
The linux-imx-headers recipe gathers certain headers from the kernel source so that other recipes which do access these headers don't have to mark the entire kernel as a dependency.
However, if a platform doesn't actually use linux-imx as its kernel, or at least uses a kernel release version that differs from that of linux-imx, ioctl mismatches can occur. Current example: linux-imx is at version 4.19 , while linux-boundary is at 4.14. The DMA_BUF_IOCTL_PHYS ioctl is defined in the uapi/dma-buf.h header in 4.14 as: #define DMA_BUF_IOCTL_PHYS _IOW(DMA_BUF_BASE, 1, struct dma_buf_phys) but in 4.19 as: #define DMA_BUF_IOCTL_PHYS _IOW(DMA_BUF_BASE, 10, struct dma_buf_phys) This leads to Boundary Devices platforms that can't handle this ioctl properly because of the definition mismatch. Just mentioning this here to discuss ideas. Perhaps it would make sense to create a virtual/imx-headers package, or place the git repo URL as a configurable variable?
|
|
|
|
Re: Mainline 5.4 kernel with VPU acceleration on iMX6
Fabio Estevam
Hi Andreas,
On Tue, Apr 7, 2020 at 5:44 AM Andreas Müller <schnitzeltony@...> wrote: Have no use case currently so just out of curiosity: Does this alsoNot sure what you mean by "community kernel", but any recent kernel from kernel.org (such as 5.4.x, 5.5.x, 5.6.x) support VPU acceleration on i.MX6. Regards, Fabio Estevam
|
|
|
|
Re: Mainline 5.4 kernel with VPU acceleration on iMX6
Andreas Müller
On Mon, Apr 6, 2020 at 9:51 PM Fabio Estevam <festevam@...> wrote:
Have no use case currently so just out of curiosity: Does this also apply to community kernels - do they support vpu-acceleration? Andreas
|
|
|
