Alternate Ducati firmware images?

[JB]

Some of my colleagues are trying to write applications using TI's OpenMAX interface to the Ducati subsystem on the Panda ES.  Our Pandaboard is running Ubuntu Core and the hardware acceleration works correctly with gstreamer (with everything from the October 2012 update post in this list).  Someone in the team (far better with Linux than me) seems to think that the Ducati firmware image (/lib/firmware/ducati-m3-core0.xem3) is not opening the OpenMAX communication channel with syslink the way it does for gstreamer.  Therefore the OpenMAX calls are not able to use Ducati.  This person suggested looking for a different Ducati firmware image, since the source is only available from TI via a licensing agreement.

From dmesg:
[    9.802337] rproc remoteproc0: dsp_c0 is available                     

[    9.802337] rproc remoteproc0: Note: remoteproc is still under development and considered experimental.                                                                          
[    9.802337] rproc remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.                                                          
[    9.802703] rproc remoteproc1: ipu_c0 is available                                                                                                                               
[    9.802703] rproc remoteproc1: Note: remoteproc is still under development and considered experimental.                                                                          
[    9.802734] rproc remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.                                                          
[    9.826202] OMAPRPC: Registration of OMAPRPC rpmsg service returned 0! debug=0                                                                                                   
[   14.022277] rproc remoteproc1: powering up ipu_c0                                                                                                                                
[   14.056823] rproc remoteproc1: Booting fw image ducati-m3-core0.xem3, size 3618829                                                                                               
[   14.291412] rproc remoteproc1: unsupported resource 5                                                                                                                            
[   14.309661] rproc remoteproc1: remote processor ipu_c0 is now up                                                                                                                 
[   14.311920] virtio_rpmsg_bus virtio0: rpmsg host is online                                                                                                                       
[   14.311950] rproc remoteproc1: registered virtio0 (type 7)                                                                                                                       
[   14.679443] omap-rproc omap-rproc.1: received echo reply from ipu_c0                                                                                                             
[   14.680145] virtio_rpmsg_bus virtio0: creating channel rpmsg-dce addr 0x2a                                                                                                       
[   14.680725] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x32                                                                                             
[   14.680999] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x33  

Looks like there would need to be another channel for OpenMAX?

Does anyone have more insight on this, or know where I could find other Ducati firmware images for Pandaboard?

Jared

[JB]

I saw this line in someone else's dmesg here:

[    5.941802] virtio_rpmsg_bus virtio0: creating channel rpmsg-omx2 addr 0x3c

How did they get that?

[JB]

In the post "libdce problem" I saw this:

My kernel config contains these [relevant] settings:

CONFIG_DRM_OMAP=y

CONFIG_DRM_OMAP_NUM_CRTCS=2

CONFIG_RPC_OMAP=y

CONFIG_DRM_OMAP_DCE=y

# CONFIG_OMAP_RPMSG_RDAEMON is not set

CONFIG_REMOTEPROC=y

CONFIG_OMAP_REMOTEPROC=y

CONFIG_OMAP_REMOTEPROC_IPU=y

CONFIG_OMAP_REMOTEPROC_DSP=y

# CONFIG_OMAP_REMOTEPROC_WATCHDOG is not set

CONFIG_OMAP4_IPU_CMA_SIZE=0x6500000

CONFIG_OMAP5_IPU_CMA_SIZE=0xA100000

CONFIG_OMAP_DSP_CMA_SIZE=0x400000

CONFIG_RPMSG=y

CONFIG_RPMSG_RESMGR_FWK=y

CONFIG_RPMSG_RESMGR=y

CONFIG_OMAP_RPMSG_RESMGR=y

CONFIG_RPMSG_OMX=y

Perhaps I need to rebuilt the kernel with that last option "CONFIG_RPMSG_OMX=y"?

[Nicolas Dechesne]

well, it isn't as simple as that ...

first if you are interested in the topic, i strongly recommend to have
a deep look at:

http://www.omappedia.com/wiki/Category:RPMsg

and the linked pages. it gives some details about the IPC architecture
used in OMAP 'modern' releases (it used to be different). the same IPC
is used for recent android and ubuntu releases.

so rpmsg is a 'messaging infrastructure', it basically creates a
'virtual messaging channel' between the MPU running Linux and the
Ducati subsystem (running TI RTOS) or the DSP.

on top of the rpmsg 'framework' there are 'services' or 'clients' that
use it. DCE is one such rpmsg client, like OMX.

when the firmware is loaded (by the remoteproc layer) it will 'expose'
the list of services it contains to the MPU side. At that point in the
linux kernel, the rpmsg framework will try to find a 'suitable' rpmsg
driver for each service that the firmware contains. To register a
'rpmsg driver' in the kernel, you need to use register_rpmsg_driver()
function.

if you enable the flag you've found what you are doing is that you are
building the OMX rpmsg client driver in the kernel. However as OMX is
'distributed' the linux s/w is just a proxy that calls into the ducati
side OMX s/w. So even if you enable that flag, you need to make sure
that you have the appropriate OMX s/w in the firmware.

In the TI Ubuntu PPA, we do not release firmware with OMX, only with
DCE. In fact OMX is not quite well supported with the non Android
releases. We have added some OMX support for OMX camera, but not for
video codecs. If your goal is really to use OMX, you would better
start with an Android release (disclaimer: i am not familiar with
android releases whether from TI or Linaro.. so I am not even sure
what is released).

To make things a bit more obscure ... there is another problematic
component: DOMX. This is a user space 'shim' layer that is doing some
buffer allocation and memory management for OMX clients. That
component was initially released for Android and was using some
Android specific APIs such as ION or Gralloc. We have done a port of
DOMX for 'linux' (as of Linux is not Android) to enable OMX camera use
case. That port is using libdrm and dmabuf (underneath) for memory
allocation and management. source is available here:
http://gitorious.org/gstreamer-omap/domx in case you want to check it
out.

[JB]

Thanks SO much for that response.  It really clears things up for us and now we know Android would be a better option :)

Jared