Re: VPU_EncGetVersionInfo failed


Tim Harvey
 

On Mon, Jul 14, 2014 at 10:11 AM, Allan Matthew <amatthew@...> wrote:
I believe I found the issue. In my device tree I had the VPU supply set to
pu_dummy when it should have been set to a regulator. Seems to have fixed
the issue.

Allan Matthew
Embedded Software Engineer, 3DRx
3D Robotics
(858) 225-1414
website | facebook | instagram
Alan,

This info was extremely helpful - I ran into this as well after
recently moving my boards to the 3.10.17_1.0.0-ga kernel. Note that I
also had to set system_rev based on the SOC type so that the imx-vpu
could determine the vpu firmware name... not clear where this was ever
set in Freescale's vendor kernel and thus if VPU even works on the
references boards with the 3.10.17 kernel.

Perhaps Freescale can shed some light on the subject? I'm wondering if
I'm completely misunderstanding the comments in the dts files or if
they are just plain wrong:

imx6qdl-sabresd.dtsi:
&vpu {
pu-supply = <&pu_dummy>; /* ldo-bypass:use pu_dummy if VDDSOC
share with VDDPU */
};

The comment above seems to indicate that if you are using LDO-bypass
mode you would set this to pu-dummy. I think this comment is
backwards, and if you are bypassing the LDO you need to set to to
reg_pu (which is what I needed to do on my board to get the VPU
initialized properly).

imx6q-sabresd-ldo.dts:
&vpu {
pu-supply = <&reg_pu>; /* ldo-bypass:use pu_dummy if VDDSOC
share with VDDPU */
};

Same comment, different choice. Is 'imx6q-sabresd-ldo.dts' the dtb for
sabresd 'using' the internal LDO or 'bypassing' the internal LDO's? We
are talking about multiple LDO's correct? (LDO_ARM on VDDARM*_CAP*
pins and LDO_SOC on VDDSOC_CAP* pins and LDO_PU on VDDPU_CAP* pins).
On our boards we provide our own VDD_ARM and VDD_SOC to VDDARM*_IN*
and VDDSOC_IN* pins to support the higher freq IMX6Q parts so I have
always assumed I am using 'ldo bypass' mode.

Please advise,

Regards,

Tim



On Mon, Jul 14, 2014 at 7:36 AM, Lauren Post <Lauren.Post@...>
wrote:

Sorry I was wrong on my part numbers – that is a solo which does have a
VPU. The DTS for solo and dual lite are the same.



From: meta-freescale-bounces@...
[mailto:meta-freescale-bounces@...] On Behalf Of Lauren Post
Sent: Monday, July 14, 2014 9:28 AM
To: Allan Matthew
Cc: meta-freescale@...
Subject: Re: [meta-freescale] VPU_EncGetVersionInfo failed



On Fri, Jul 11, 2014 at 3:41 PM, Otavio Salvador <otavio@...>
wrote:

On Fri, Jul 11, 2014 at 6:08 PM, Allan Matthew <amatthew@...>
wrote:
I'm using a custom MCIMX6S5EVM10AC board and am having an issue with the
vpuenc gstreamer plugin. I'm able to otherwise use gstreamer plugins
like
mfw_v4lsink, tvsrc, mfw_isink etc but the vpu does not seem to be
working.
When invoking vpuenc with the h.264 codec, I get the following debug
error
from gst-launch:

0:00:02.613795334 1154 0x389920 ERROR vpuenc
vpuenc.c:441:vpuenc_core_init: func VPU_EncGetVersionInfo failed!! with
ret


This part you are using is a i.MX 6 Solo Lite chip which does not have a
VPU. That is why you are getting this failure.







--
_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale

Join meta-freescale@lists.yoctoproject.org to automatically receive all group messages.