Enabling IPU on OMAP44xx

Enabling IPU on OMAP44xx

[Jack Mitchell]

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

I've been fighting for a week with trying to get the IPU booted over 
remoteproc on an OMAP4470. I feel like I've got most of the way there 
but I don't get a response from the first kick after boot. Has anyone 
ever had the IPU booted on mainline? Dmesg from remoteproce boot is as 
below:

[   47.430084]  remoteproc0: ipu_c0 is available
[   47.431274]  remoteproc0: Note: remoteproc is still under development 
and considered experimental.
[   47.445312]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[   47.869476]  remoteproc0: unsupported resource 5
[   47.876831]  remoteproc0: registered virtio0 (type 7)
[   47.882385]  remoteproc0: unsupported resource 5
[   47.888244] cma: cma_alloc(cma c1211f98, count 3, align 2)
[   47.897613] cma: cma_alloc(): returned deda7990
[   47.902465] cma: cma_alloc(cma c1211f98, count 3, align 2)
[   47.908813] cma: cma_alloc(): returned deda7a20
[   47.913604]  remoteproc0: powering up ipu_c0
[   47.967895]  remoteproc0: Booting fw image ducati-m3-core0.xem3, size 
14862876
[   47.983947] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[   47.990112] cma: cma_alloc(cma c1211f98, count 1536, align 8)
[   47.997894] cma: cma_alloc(): returned deda9400
[   48.022949] cma: cma_alloc(cma c1211f98, count 58880, align 8)
[   48.047454] cma: cma_alloc(): returned dedb6c00
[   48.762756] cma: cma_alloc(cma c1211f98, count 256, align 8)
[   48.769165] cma: cma_alloc(): returned defbc400
[   48.779113]  remoteproc0: unsupported resource 5
[   48.887756] omap-rproc omap-rproc.1: JACK1
[   48.893157] omap-rproc omap-rproc.1: JACK2
[   48.893157] omap-rproc omap-rproc.1: JACK3
[   48.901794] omap-rproc omap-rproc.1: JACK4
[   48.906097]  remoteproc0: remote processor ipu_c0 is now up
[   48.912231] cma: cma_alloc(cma c1211f98, count 64, align 6)
[   48.922851] cma: cma_alloc(): returned deda8200
[   48.929321] virtio_rpmsg_bus virtio0: rpmsg host is online

What I would expect next (as is the case on my 3.4 TI vendor kernel) is 
something like:

[   13.647338] virtio_rpmsg_bus virtio0: rpmsg host is online
[   15.996520] omap-rproc omap-rproc.1: received echo reply from ipu_c0
[   15.996887] virtio_rpmsg_bus virtio0: creating channel rpmsg-dce addr 
0x2a
[   16.000335] virtio_rpmsg_bus virtio0: creating channel rpmsg-omx1 
addr 0x3c
[   16.000732] rpmsg_omx rpmsg-omx1: new OMX connection srv channel: 
1025 -> 60!
[   16.000915] virtio_rpmsg_bus virtio0: creating channel omaprpc addr 0x3b

I imagine the echo reply is remoteproc, but the other stuff is maybe 
omapdce?

The patch that I've hacked together to get this far is attached. I had 
to comment out some of the zero checking parts as it was failing, saying 
that the reserved memory was not zeroed; could this be the iommu that 
isn't translating properly?

Any input at all on the subject would be much appreciated!

Cheers,
Jack.

[-- Attachment #2: ipu_rproc.patch --]
[-- Type: text/x-patch, Size: 3902 bytes --]

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f5e68a7..b628498 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4792,7 +4792,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
 	&omap44xx_l4_per__i2c4,
 	&omap44xx_l3_main_2__ipu,
 	&omap44xx_l3_main_2__iss,
-	/* &omap44xx_iva__sl2if, */
+	&omap44xx_iva__sl2if,
 	&omap44xx_l3_main_2__iva,
 	&omap44xx_l4_wkup__kbd,
 	&omap44xx_l4_cfg__mailbox,
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index af11511..ad4eacf 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -14,9 +14,11 @@
 #include <linux/kernel.h>
 #include <linux/of_platform.h>
 #include <linux/ti_wilink_st.h>
+#include <linux/dma-contiguous.h>
 
 #include <linux/platform_data/pinctrl-single.h>
 #include <linux/platform_data/iommu-omap.h>
+#include <linux/platform_data/remoteproc-omap.h>
 
 #include "common.h"
 #include "common-board-devices.h"
@@ -243,6 +245,55 @@ static void __init nokia_n900_legacy_init(void)
 	}
 }
 
+static struct platform_device omap4_ducati = {
+        .name   = "omap-rproc",
+        .id     = 1,
+};
+
+static struct omap_rproc_pdata omap4_rproc_data[] = {
+        {
+                .name           = "ipu_c0",
+                .firmware       = "ducati-m3-core0.xem3",
+                .mbox_name      = "mbox_ipu",
+                .oh_name        = "ipu",
+                .oh_name_opt    = "iss",
+                .set_bootaddr   = omap_ctrl_write_dsp_boot_addr,
+		.device_enable  = omap_device_enable,
+        },
+};
+
+static struct omap_iommu_arch_data omap4_ipu_iommu = {
+        .name = "55082000.mmu",
+};
+
+static void __init custboard_legacy_init(void)
+{
+	omap4_ducati.dev.archdata.iommu = &omap4_ipu_iommu;
+	platform_device_register(&omap4_ducati);
+
+	platform_device_add_data(&omap4_ducati,
+                                 &omap4_rproc_data,
+                                 sizeof(struct omap_rproc_pdata));
+
+}
+
 static void __init omap3_tao3530_legacy_init(void)
 {
 	hsmmc2_internal_input_clk();
@@ -361,6 +412,9 @@ static struct pdata_init pdata_quirks[] __initdata = {
 	{ "technexion,omap3-tao3530", omap3_tao3530_legacy_init, },
 #endif
 #ifdef CONFIG_SOC_OMAP5
+	{ "company,board", custboard_legacy_init, },
+#endif
+#ifdef CONFIG_SOC_OMAP5
 	{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
 #endif
 	{ /* sentinel */ },

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index a3d6138..1e445c5 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -276,10 +276,10 @@ rproc_parse_vring(struct rproc_vdev *rvdev, struct fw_rsc_vdev *rsc, int i)
 				i, vring->da, vring->num, vring->align);
 
 	/* make sure reserved bytes are zeroes */
-	if (vring->reserved) {
+/*	if (vring->reserved) {
 		dev_err(dev, "vring rsc has non zero reserved bytes\n");
 		return -EINVAL;
-	}
+	}*/
 
 	/* verify queue size and vring alignment are sane */
 	if (!vring->num || !vring->align) {
@@ -514,10 +514,10 @@ static int rproc_handle_devmem(struct rproc *rproc, struct fw_rsc_devmem *rsc,
 	}
 
 	/* make sure reserved bytes are zeroes */
-	if (rsc->reserved) {
+/*	if (rsc->reserved) {
 		dev_err(dev, "devmem rsc has non zero reserved bytes\n");
 		return -EINVAL;
-	}
+	}*/
 
 	mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
 	if (!mapping) {
@@ -587,10 +587,10 @@ static int rproc_handle_carveout(struct rproc *rproc,
 	}
 
 	/* make sure reserved bytes are zeroes */
-	if (rsc->reserved) {
+/*	if (rsc->reserved) {
 		dev_err(dev, "carveout rsc has non zero reserved bytes\n");
 		return -EINVAL;
-	}
+	}*/
 
 	dev_dbg(dev, "carveout rsc: da %x, pa %x, len %x, flags %x\n",
 			rsc->da, rsc->pa, rsc->len, rsc->flags);

Re: Enabling IPU on OMAP44xx

[Nishanth Menon]

On 04/24/2015 11:21 AM, Jack Mitchell wrote:
> I've been fighting for a week with trying to get the IPU booted over
> remoteproc on an OMAP4470. I feel like I've got most of the way there

we do not have support for OMAP4470 on git.kernel.org.

If you are interested in TI vendor kernel support, please use e2e.ti.com.

...

-- 
Regards,
Nishanth Menon

Re: Enabling IPU on OMAP44xx

[Jack Mitchell]

On 24/04/15 19:34, Nishanth Menon wrote:
> On 04/24/2015 11:21 AM, Jack Mitchell wrote:
>> I've been fighting for a week with trying to get the IPU booted over
>> remoteproc on an OMAP4470. I feel like I've got most of the way there
> we do not have support for OMAP4470 on git.kernel.org.
>
> If you are interested in TI vendor kernel support, please use e2e.ti.com.
>
> ...
>

Hi Nishanth,

I understand; and booting an omap4470 isn't the issue, I've hacked in 
the support for booting it as it's basically the same as 4460; which is 
supported. It's the IPU that I'm trying to get working, which is the 
same across all the 44xx omap SoCs, right? I'm using the latest mainline 
and the logs I posted are from the git HEAD early this morning.

I'm not looking for offical support, just pointers to people who may 
have been using mainline and the IPU, the support seems to be in there 
but none of the plumbing so I assume someone is probably using it 
otherwise it's dead code.

Cheers,
Jack.

Re: Enabling IPU on OMAP44xx

[Jack Mitchell]

On 24/04/15 19:34, Nishanth Menon wrote:
> On 04/24/2015 11:21 AM, Jack Mitchell wrote:
>> I've been fighting for a week with trying to get the IPU booted over
>> remoteproc on an OMAP4470. I feel like I've got most of the way there
> we do not have support for OMAP4470 on git.kernel.org.
>
> If you are interested in TI vendor kernel support, please use e2e.ti.com.
>
> ...
>

Hi Nishanth,

I understand; and booting an omap4470 isn't the issue, I've hacked in 
the support for booting it as it's basically the same as 4460; which is 
supported. It's the IPU that I'm trying to get working, which is the 
same across all the 44xx omap SoCs, right? I'm using the latest mainline 
and the logs I posted are from the git HEAD early this morning.

I'm not looking for offical support, just pointers to people who may 
have been using mainline and the IPU, the support seems to be in there 
but none of the plumbing so I assume someone is probably using it 
otherwise it's dead code.

Cheers,
Jack.

Re: Enabling IPU on OMAP44xx

[Suman Anna]

Hi Jack,

> On 24/04/15 19:34, Nishanth Menon wrote:
>> On 04/24/2015 11:21 AM, Jack Mitchell wrote:
>>> I've been fighting for a week with trying to get the IPU booted over
>>> remoteproc on an OMAP4470. I feel like I've got most of the way there
>> we do not have support for OMAP4470 on git.kernel.org.
>>
>> If you are interested in TI vendor kernel support, please use e2e.ti.com.
>>
>> ...
>>
> 
> Hi Nishanth,
> 
> I understand; and booting an omap4470 isn't the issue, I've hacked in 
> the support for booting it as it's basically the same as 4460; which is 
> supported. It's the IPU that I'm trying to get working, which is the 
> same across all the 44xx omap SoCs, right? I'm using the latest mainline 
> and the logs I posted are from the git HEAD early this morning.
> 
> I'm not looking for offical support, just pointers to people who may 
> have been using mainline and the IPU, the support seems to be in there 
> but none of the plumbing so I assume someone is probably using it 
> otherwise it's dead code.

Yeah, these are indeed used downstream in the TI product kernels, and
it's just that adding the support for them has been progressing slowly
upstream.

There are couple of things that are wrong with your minimal patch,
things that stand out
1. omap_ctrl_write_dsp_boot_addr is for DSP, not for IPU, so you need
not set that.
2. omap_device_enable is not enough to release the processor resets in
general, you can check the PRCM RSTCTRL registers, my bet is the
processor is still in reset.
3. You also need to have an associated CMA pool with the remoteproc, and
the CMA start address needs to match to that of your resource table,
atleast with the current firmware images.

In anycase, to be closer to use mainline sources, you would want to
create a DT-based remoteproc device and not legacy style platform
device. The mailbox and IOMMU support are converted to DT and should
support OMAP4 in mainline already.

FYI, you may want to look at the following TI trees,
http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=shortlog;h=refs/heads/rpmsg-ti-linux-3.14.y
(integrated remoteproc with rpmsg)
or just
http://git.ti.com/gitweb/?p=rpmsg/remoteproc.git;a=shortlog;h=refs/heads/rproc-linux-3.14.y
(remoteproc without any rpmsg pieces)

Those should boot on OMAP4, OMAP5 and DRA7 platforms provided you have
the firmwares with appropriate resource tables.

regards
Suman