libdce problem

[Gary Thomas]

I've been running a kernel based on the Ubuntu 12.04 setup

  repo: git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git

  tag: ti-ubuntu-3.4-1485.7

I'm running gst-ducati so I need the Ducati processors running, using libdce

This was all working great, including the gst-ducati stuff.

Here's what it looks like when I boot:

[    5.593658] rproc remoteproc1: powering up ipu_c0

[    5.615020] rproc remoteproc0: Booting fw image tesla-dsp.xe64T, size 481512

[    5.622650] omap-iommu omap-iommu.0: dsp: version 2.0

[    5.714447] rproc remoteproc0: remote processor dsp_c0 is now up

[    5.721343] rproc remoteproc1: Booting fw image ducati-m3-core0.xem3, size 3134213

[    5.729888] omap-iommu omap-iommu.1: ipu: version 2.1

[    5.739105] virtio_rpmsg_bus virtio0: rpmsg host is online

[    5.745361] rproc remoteproc0: registered virtio0 (type 7)

[    5.902709] omap-rproc omap-rproc.0: received echo reply from dsp_c0

[    5.919799] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x32

[    5.928710] virtio_rpmsg_bus virtio0: creating channel rpmsg-client-sample addr 0x33

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

[    5.949981] rpmsg_omx rpmsg-omx2: new OMX connection srv channel: 1024 -> 60!

[    6.088287] rproc remoteproc1: remote processor ipu_c0 is now up

[    6.100219] virtio_rpmsg_bus virtio1: rpmsg host is online

[    6.107269] rproc remoteproc1: registered virtio1 (type 7)

[    6.261962] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

[    6.555572] omap-rproc omap-rproc.1: received echo reply from ipu_c0

[    6.562408] virtio_rpmsg_bus virtio1: creating channel rpmsg-dce addr 0x2a

[    6.570587] virtio_rpmsg_bus virtio1: creating channel rpmsg-client-sample addr 0x32

[    6.579559] virtio_rpmsg_bus virtio1: creating channel rpmsg-client-sample addr 0x33

Today, I tried upgrading to a newer kernel version.  I merged my kernel with

ti-ubuntu-3.4-1486.10 and now the Ducati processors no longer come up.

Now, when  I boot, I get these messages when bringing up the DSP processors:

[    5.976135] rproc remoteproc0: powering up dsp_c0

[    5.989074] rproc remoteproc0: Booting fw image tesla-dsp.xe64T, size 481512

[    5.997436] omap-iommu omap-iommu.0: dsp: version 2.0

[    6.026794] rproc remoteproc0: remote processor dsp_c0 is now up

[    6.035705] virtio_rpmsg_bus virtio0: rpmsg host is online

[    6.041534] rproc remoteproc0: registered virtio0 (type 7)

[    6.071075] omap-rproc omap-rproc.0: received echo reply from dsp_c0

[    6.687103] rproc remoteproc1: powering up ipu_c0

[    6.723724] rproc remoteproc1: Booting fw image ducati-m3-core0.xem3, size 3134213

[    6.732482] omap-iommu omap-iommu.1: ipu: version 2.1

[    7.033416] rproc remoteproc1: remote processor ipu_c0 is now up

[    7.042785] virtio_rpmsg_bus virtio1: rpmsg host is online

[    7.048614] rproc remoteproc1: registered virtio1 (type 7)

[    7.498840] omap-rproc omap-rproc.1: received echo reply from ipu_c0

[   11.034973] omap_iommu_update_latency Requested latency -1 but limiting  DSP latency to 300 due to buggy firmware

Notice, no virtual channels created.  When I try to run the gst-ducati code, I now

get this error:

libdce.c:459:   init    error: could not get plugin ioctl base: -22

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

Only the two commented out options are different between the two kernel versions (these options are new).

Any ideas what I'm missing?  Why don't the virtual channels get created?

 

Note: I did change my bootargs to remove the hole in this latest version, so I'm booting with mem=1G@0x80000000

[Xavier Boudet]

Hi Gary,

Can you clarify which ducati FW you are using?
The kernel config changed on ti-ubuntu-3.4-1486.10 for CMA sizes, please check commit: 78a226b9a9305a15453cb21c83400bdfacb11198
Apparently you did not update your config accordingly.
I advise you to review the changes on debian.ti-omap4/config/config.common.ubuntu each time you switch to a new kernel.
Another question: why don't you switch to ti-ubuntu-3.4-1487.6?

Hope it will help...

Regards, Xavier Boudet

[Nicolas Dechesne]

did you filter our some messages from the boot log?

also can you send "cat
/sys/kernel/debug/remoteproc/remoteproc1/trace0" it's the ducati side
trace buffer.

i would suspect that it's a firmware misalignment.. but looking at the
kernel log it's not obvious that it's the case... from the log it
seems that you are using the same firmware with both kernel, right?

[Nicolas Dechesne]

On Wed, Oct 24, 2012 at 8:54 AM, Xavier Boudet <x-bo...@ti.com> wrote:
> Hi Gary,
>
> Can you clarify which ducati FW you are using?
> The kernel config changed on ti-ubuntu-3.4-1486.10 for CMA sizes, please
> check commit: 78a226b9a9305a15453cb21c83400bdfacb11198

argh... right... so now I see an obvious issue in the kernel log ;-)

i don't think the problem is because the size changed, that should be
fine (as the size were increased), but the problem is because of this
one:

commit e4f1f70f9f171bc4b79b994ac1c289460df10f4a
Author: Suman Anna <s-a...@ti.com>
Date: Wed Jun 20 21:54:31 2012 -0500

omap: remoteproc: adjust CMA base addresses to be within 512MB


so clearly, a firmware that works without that patch, won't work anymore.

[Gary Thomas]

On Wednesday, October 24, 2012 12:54:43 AM UTC-6, Xavier Boudet wrote:

Hi Gary,

Can you clarify which ducati FW you are using?
The kernel config changed on ti-ubuntu-3.4-1486.10 for CMA sizes, please check commit: 78a226b9a9305a15453cb21c83400bdfacb11198
Apparently you did not update your config accordingly.
I advise you to review the changes on debian.ti-omap4/config/config.common.ubuntu each time you switch to a new kernel.

Thanks for this pointer.  I missed those CMA size changes.

 

Another question: why don't you switch to ti-ubuntu-3.4-1487.6?

I actually did with no difference in the ducati stuff.  I'll try it some more, but my first experiment with that kernel

gave me some problems with DMA when I played some audio files.

[Gary Thomas]

Nothing obvious (to me) there.

 # cat /sys/kernel/debug/remoteproc/remoteproc1/trace0

[0][      0.000] 15 IpcMemory entries at 0x3000

[0][      0.000] DEH: Watchdog disabled

[0][      0.000] CORE0 starting..

[0][      0.000] dce.c:590:     dce_init        info: Creating DCE server thread...

[1][      0.000] copyTask 50: Entered...:

[0][      0.000] dce.c:541:     dce_main        info: Creating DCE MessageQ...

[0][      0.000] registering rpmsg-dce service on 42 with HOST

[1][      0.000] registering rpmsg-client-sample service on 50 with HOST

[1][      0.000] loadTask: started

[0][      0.000] copyTask 51: Entered...:

[1][      0.000]   SLEEP_TICKS: 1000

[1][      0.000]   Load_hwiEnabled: 0

[0][      0.000] registering rpmsg-client-sample service on 51 with HOST

[1][      0.000]   Load_swiEnabled: 0

[1][      0.000]   Load_taskEnabled: 1

[1][      0.000]   Load_updateInIdle: 1

[1][      0.000]   Load_windowInMs: 11

[0][      1.001] loadTask: cpu load = 19%

[0][      2.001] loadTask: cpu load = 22%

i would suspect that it's a firmware misalignment.. but looking at the
kernel log it's not obvious that it's the case... from the log it
seems that you are using the same firmware with both kernel, right?

What firmware (package name/revision) should I be using?  Is this firmware

backwards compatible?

Thanks

 

[Nicolas Dechesne]

On Wed, Oct 24, 2012 at 12:35 PM, Gary Thomas <samoh...@gmail.com> wrote:
> What firmware (package name/revision) should I be using? Is this firmware
> backwards compatible?

whatever is in the tiomap-dep/release PPA should work. this is not
backward compatible. changing the CMA start address is actually
changing the memory map on the ducati side, and that is not backward
(nor forward) compatible, at least for now.

[Gary Thomas]

I think I have the latest stuff from tiomap4-syslink-mm-firmware_2.x.10.1+dce1+2.1

This is the package mentioned on https://launchpad.net/~tiomap-dev/+archive/release/+packages

with kernel 3.4.0-1487.6 (which I'm now using)

Here's the firmware that is being downloaded:

415214b65f6364973eac55ceb1c9f0a8  /lib/firmware/ducati-m3-core0.xem3

9aecba2459ac2c7d77be5258afed82fa  /lib/firmware/ducati-mm-core0.xem3

What else can I look at to figure out what's happening? 

[Xavier Boudet]

OK, the package was renamed, please check: ti-firmware-ipu-dce - 1.6+121009+114852+git5c3f2bc
https://launchpad.net/~tiomap-dev/+archive/omap-trunk/+sourcepub/2708330/+listing-archive-extra

Regards, Xavier Boudet

[Gary Thomas]

On Wednesday, October 24, 2012 7:58:34 AM UTC-6, Xavier Boudet wrote:

OK, the package was renamed, please check: ti-firmware-ipu-dce - 1.6+121009+114852+git5c3f2bc
https://launchpad.net/~tiomap-dev/+archive/omap-trunk/+sourcepub/2708330/+listing-archive-extra

OK, I replaced ti-omap4-syslink-mm-firmware_2.x.10.1+dce1+2.1 with that package and gst-ducati works again :-)

Thanks

Now I get this error:

[    7.933868] rproc remoteproc0: error -2 requesting firmware tesla-dsp.xe64T

What package does that come from now?

[Xavier Boudet]

This is not a problem, tesla-dsp fw is optional.

Regards, Xavier Boudet