platform: coda: how to use firmware-imx binary releases?

platform: coda: how to use firmware-imx binary releases?

[Martin Kepplinger]

Hi,

Commit

     be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and 
3.1.1 as supported

says firmware version 3.1.1 revision 46072 is contained in 
"firmware-imx-5.4.bin", that's probably

     sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-5.4.bin

How do I use this in order to get a VPU firmware blob that the coda 
platform driver can work with?



(Maybe it'd be worth adding some short documentation on this. There 
doesn't seem to be a
devicetree bindings doc for coda in 
Documentation/devicetree/bindings/media which would
be a good place for documenting how to use these binaries too)

thanks

                                    martin

Re: platform: coda: how to use firmware-imx binary releases?

[Philipp Zabel]

Hi Martin,

On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
> Hi,
> 
> Commit
> 
>      be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 and 3.1.1 as supported
> 
> says firmware version 3.1.1 revision 46072 is contained in 
> "firmware-imx-5.4.bin", that's probably
> 
>      sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-5.4.bin

Yes.

> How do I use this in order to get a VPU firmware blob that the coda 
> platform driver can work with?

These are self-extracting shell scripts with an attached compressed tar
archive. This particular file can be extracted by skipping the first
34087 bytes:

dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xjv

> (Maybe it'd be worth adding some short documentation on this. There 
> doesn't seem to be a devicetree bindings doc for coda in 
> Documentation/devicetree/bindings/media which would
> be a good place for documenting how to use these binaries too)

Thank you for pointing this out, the device tree binding docs for coda
are indeed missing.
I'm not sure the device tree binding docs are the right place to
document driver and firmware though. For that, adding a coda.rst entry
to Documentation/media/v4l-drivers would probably be a better place.

regards
Philipp

Re: platform: coda: how to use firmware-imx binary releases?

[Martin Kepplinger]

Am 04.10.2017 11:22 schrieb Philipp Zabel:
> Hi Martin,
> 
> On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
>> Hi,
>> 
>> Commit
>> 
>>      be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10 
>> and 3.1.1 as supported
>> 
>> says firmware version 3.1.1 revision 46072 is contained in 
>> "firmware-imx-5.4.bin", that's probably
>> 
>>      sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-5.4.bin
> 
> Yes.
> 
>> How do I use this in order to get a VPU firmware blob that the coda 
>> platform driver can work with?
> 
> These are self-extracting shell scripts with an attached compressed tar
> archive. This particular file can be extracted by skipping the first
> 34087 bytes:
> 
> dd if=firmware-imx-5.4.bin bs=34087 skip=1 | tar xjv
> 

thanks!

>> (Maybe it'd be worth adding some short documentation on this. There 
>> doesn't seem to be a devicetree bindings doc for coda in 
>> Documentation/devicetree/bindings/media which would
>> be a good place for documenting how to use these binaries too)
> 
> Thank you for pointing this out, the device tree binding docs for coda
> are indeed missing.
> I'm not sure the device tree binding docs are the right place to
> document driver and firmware though. For that, adding a coda.rst entry
> to Documentation/media/v4l-drivers would probably be a better place.
> 

True. That'd be great. Some firmware-handling and maybe even firmware
version changelogs would definitely be useful.


I'm running a little off-topic here, but with the newest firmware too, 
my
coda driver says "Video Data Order Adapter: Disabled" when started
by video playback via v4l2.

(imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed,
a dev_info "probed" would maybe be useful for others too?)

It supsequently fails with

cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12

which may or may not be related to having the vdoa (is it?), but 
shouldn't
the VDOA module be active by default?

# cat /sys/module/coda/parameters/disable_vdoa
0

thanks

                                 martin

Re: platform: coda: how to use firmware-imx binary releases?

[Philipp Zabel]

Hi Martin,

On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote:
> I'm running a little off-topic here, but with the newest firmware too, 
> my
> coda driver says "Video Data Order Adapter: Disabled" when started
> by video playback via v4l2.

This message is most likely just a result of the VDOA not supporting the
selected capture format. In vdoa_context_configure, you can see that the
VDOA only writes YUYV or NV12.

> (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed,
> a dev_info "probed" would maybe be useful for others too?)
> 
> It supsequently fails with
> 
> cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12

That is -ENOMEM. Is CMA enabled and sufficiently large? For example,

CONFIG_CMA=y
CONFIG_CMA_DEBUGFS=y
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=256
CONFIG_CMA_SIZE_SEL_MBYTES=y

> which may or may not be related to having the vdoa (is it?), but 
> shouldn't the VDOA module be active by default?
> 
> # cat /sys/module/coda/parameters/disable_vdoa
> 0

I think it is not related to VDOA at all. Yes, by default the VDOA
should be activated automatically for any supported format.

regards
Philipp

Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?

[Martin Kepplinger]

Am 05.10.2017 10:19 schrieb Philipp Zabel:
> Hi Martin,
> 
> On Thu, 2017-10-05 at 09:43 +0200, Martin Kepplinger wrote:
>> I'm running a little off-topic here, but with the newest firmware 
>> too, 
>> my
>> coda driver says "Video Data Order Adapter: Disabled" when started
>> by video playback via v4l2.
> 
> This message is most likely just a result of the VDOA not supporting 
> the
> selected capture format. In vdoa_context_configure, you can see that 
> the
> VDOA only writes YUYV or NV12.

ok. I'll have to look into it, and just in case you see a problem on 
first sight:
this is what coda says with debug level 1, when doing

gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 
video-sink=fbdevsink

with the video file being (ffprobe)

Input #0, h264, from 'test2_hd480.h264':
   Duration: N/A, bitrate: N/A
     Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 
fps, 24 tbr, 1200k tbn, 48 tbc


after some s_ctrl: id/val printings:

[   98.833023] coda 2040000.vpu: Created instance 0 (cefc5000)
[   98.837550] coda 2040000.vpu: Releasing instance cefc5000
[   98.839080] coda 2040000.vpu: s_ctrl: id = 9963796, val = 0
[   98.839091] coda 2040000.vpu: s_ctrl: id = 9963797, val = 0
[   98.839100] coda 2040000.vpu: Created instance 0 (ceeb2000)
[   98.842867] coda 2040000.vpu: Releasing instance ceeb2000
[   98.845435] coda 2040000.vpu: s_ctrl: id = 9963796, val = 0
[   98.845447] coda 2040000.vpu: s_ctrl: id = 9963797, val = 0
[   98.845458] coda 2040000.vpu: Created instance 0 (cefc5000)
[   98.851652] coda 2040000.vpu: Setting format for type 2, wxh: 
852x480, fmt: H264 L
[   98.851670] coda 2040000.vpu: Setting format for type 1, wxh: 
852x480, fmt: NV12 T
[   98.854800] coda 2040000.vpu: get 2 buffer(s) of size 819200 each.
[   99.022191] coda 2040000.vpu: get 2 buffer(s) of size 622080 each.
[   99.025904] coda 2040000.vpu: Video Data Order Adapter: Disabled
[   99.025922] coda 2040000.vpu: H264 Profile/Level: High L3
[   99.026214] coda 2040000.vpu: __coda_start_decoding instance 0 now: 
864x480
[   99.036277] coda 2040000.vpu: 0: not ready: need 2 buffers available 
(1, 0)
[   99.063157] coda 2040000.vpu: job ready


so while the video is shown, the VDOA is "disabled".

                           thanks a lot for your help


(it's shown far from fluent yet, almost frame by frame, but that's ok 
for now... I'll still need to
took into the v4l2 interface for the imx6 IPU)


> 
>> (imx6, running linux 4.14-rc3, imx-vdoa is probed and never removed,
>> a dev_info "probed" would maybe be useful for others too?)
>> 
>> It supsequently fails with
>> 
>> cma: cma_alloc: alloc failed, req-size: 178 pages, ret: -12
> 
> That is -ENOMEM. Is CMA enabled and sufficiently large? For example,
> 
> CONFIG_CMA=y
> CONFIG_CMA_DEBUGFS=y
> CONFIG_DMA_CMA=y
> CONFIG_CMA_SIZE_MBYTES=256
> CONFIG_CMA_SIZE_SEL_MBYTES=y
> 

My cma buffer size was indeed just too small.

Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?

[Nicolas Dufresne]

Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit :
> > This message is most likely just a result of the VDOA not supporting 
> > the
> > selected capture format. In vdoa_context_configure, you can see that 
> > the
> > VDOA only writes YUYV or NV12.
> 
> ok. I'll have to look into it, and just in case you see a problem on 
> first sight:
> this is what coda says with debug level 1, when doing
> 
> gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264 
> video-sink=fbdevsink

A bit unrelated, but kmssink remains a better choice here.

Nicolas

Re: platform: coda: how to use firmware-imx binary releases? / how to use VDOA on imx6?

[Martin Kepplinger]

Am 05.10.2017 16:10 schrieb Nicolas Dufresne:
> Le jeudi 05 octobre 2017 à 13:54 +0200, Martin Kepplinger a écrit :
>> > This message is most likely just a result of the VDOA not supporting
>> > the
>> > selected capture format. In vdoa_context_configure, you can see that
>> > the
>> > VDOA only writes YUYV or NV12.
>> 
>> ok. I'll have to look into it, and just in case you see a problem on
>> first sight:
>> this is what coda says with debug level 1, when doing
>> 
>> gst-launch-1.0 playbin uri=file:///data/test2_hd480.h264
>> video-sink=fbdevsink
> 
> A bit unrelated, but kmssink remains a better choice here.
> 

True, but I'm currently not yet interested in the other end of the pipe 
:) Decoding
works in principal. VDOA is still disabled however :( I don't see what I 
can do
about this right now, which is a bit odd. It is definitely probed (and 
not removed).
I see at least a few frames of the video, so I guess the video file is 
fine? Or could
it be a file (or pixel) format that isn't supported? Again, ffprobe says

Stream #0:0: Video: h264 (High), yuv420p(progressive), 852x480, 24 fps, 
24 tbr, 1200k tbn, 48 tbc

                             thanks


After this, I want to have video conversion (color space) via a v4l2 
interface that
in turn uses the imx6 IPU. I guess gst-inspect-1.0 should see a V4L2 
Converter,
which it currently doesn't here:

# gst-inspect-1.0 | grep v4l2
video4linux2:  v4l2video1dec: V4L2 Video Decoder
video4linux2:  v4l2deviceprovider (GstDeviceProviderFactory)
video4linux2:  v4l2radio: Radio (video4linux2) Tuner
video4linux2:  v4l2sink: Video (video4linux2) Sink
video4linux2:  v4l2src: Video (video4linux2) Source

# dmesg | grep ipu
[    1.394717] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops 
0xc07d4b60)
[    1.402258] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops 
0xc07d4b60)
[    1.514984] imx-ipuv3 2400000.ipu: IPUv3H probed

should imx-ipuv3 provide a video4linux2 interface for video conversion? 
At least I don't
see it yet. (or other V4L2 Linux config options than I already have 
enabled)

Re: platform: coda: how to use firmware-imx binary releases?

[Philipp Zabel]

On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
> Hi,
> 
> Commit
> 
>      be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
> and 
> 3.1.1 as supported
> 
> says firmware version 3.1.1 revision 46072 is contained in 
> "firmware-imx-5.4.bin", that's probably
> 
>      sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-
> 5.4.bin
> 
> How do I use this in order to get a VPU firmware blob that the coda 
> platform driver can work with?
> 
> 
> 
> (Maybe it'd be worth adding some short documentation on this. There 
> doesn't seem to be a devicetree bindings doc for coda in 
> Documentation/devicetree/bindings/media 

I was mistaken, Documentation/devicetree/bindings/media/coda.txt exists.
It was added in commit 657eee7d25fb ("media: coda: use genalloc API").

regards
Philipp

Re: platform: coda: how to use firmware-imx binary releases?

[Martin Kepplinger]

On 2017-10-05 17:45, Philipp Zabel wrote:
> On Wed, 2017-10-04 at 10:44 +0200, Martin Kepplinger wrote:
>> Hi,
>>
>> Commit
>>
>>      be7f1ab26f42 media: coda: mark CODA960 firmware versions 2.3.10
>> and 
>> 3.1.1 as supported
>>
>> says firmware version 3.1.1 revision 46072 is contained in 
>> "firmware-imx-5.4.bin", that's probably
>>
>>      sha1  78a416ae88ff01420260205ce1d567f60af6847e  firmware-imx-
>> 5.4.bin
>>
>> How do I use this in order to get a VPU firmware blob that the coda 
>> platform driver can work with?
>>
>>
>>
>> (Maybe it'd be worth adding some short documentation on this. There 
>> doesn't seem to be a devicetree bindings doc for coda in 
>> Documentation/devicetree/bindings/media 
> 
> I was mistaken, Documentation/devicetree/bindings/media/coda.txt exists.
> It was added in commit 657eee7d25fb ("media: coda: use genalloc API").

Right. Not greppable with "coda". If you've also missed it because of
that, it might likely help others when "coda" is mendtioned in it :)