Forums

Hi John,

john3909

This is exactly the same patch I applied to my kernel

Just to be clear here...

The SysLink-supplied patch for the 2.6.32 kernel would not merge (or "apply" in patch terminology) correctly with the 3.0.28 kernel.  For one reason, the patch applies to the file arch/arm/mach-omap2/omap3-iommu.c and that file does not exist in 3.0.28.  For another reason, the "diff" in the patch mentions replacing the line:
    -#if defined(CONFIG_MPU_BRIDGE_IOMMU)
with a commented-out copy of that line:
    +/*#if defined(CONFIG_MPU_BRIDGE_IOMMU)*/
but the 3.0.28-equivalent file omap-iommu.c doesn't have the original line.  I assume that you have then simply commented out this line from 3.0.28's omap-iommu.c (line 40):
    #if defined(CONFIG_OMAP_IOMMU_IVA2)
and its corresponding #endif.  Is that correct?

Regards,

- Rob

Robert Tivy

The SysLink-supplied patch for the 2.6.32 kernel would not merge (or "apply" in patch terminology) correctly with the 3.0.28 kernel.  For one reason, the patch applies to the file arch/arm/mach-omap2/omap3-iommu.c and that file does not exist in 3.0.28.  For another reason, the "diff" in the patch mentions replacing the line:

    -#if defined(CONFIG_MPU_BRIDGE_IOMMU)
with a commented-out copy of that line:
    +/*#if defined(CONFIG_MPU_BRIDGE_IOMMU)*/
but the 3.0.28-equivalent file omap-iommu.c doesn't have the original line.  I assume that you have then simply commented out this line from 3.0.28's omap-iommu.c (line 40):
    #if defined(CONFIG_OMAP_IOMMU_IVA2)
and its corresponding #endif.  Is that correct?

That is correct. Because syslink_2_10_05_26 is qualified to work with 2.6.37 on the DM816x processor, I had inadvertently compared the 3.0.28 kernel with the 2.6.37 kernel and omap-iommu.c does exist and is identical to the file in 3.0.28. You are correct, the patch as defined will not apply so I made the changes manually and commented out the $if defined line as well as the corresponding #endif line.

Regards,

John

Hi Rob,

I opened a new thread for this issue:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/194647.aspx

Thank you again for all your help.

Robert Tivy

I have since been informed that OMAP3530 ELF support is broken (and was only preliminary support at that, COFF is the validated format for OMAP3530).  Can you try chainging LOADER = COFF and see how that goes?

We have a new SysLink 2.10.06 release in the works, which should be coming out next week.  That release will have (fixed) ELF support for OMAP3530, so if you *need* to use ELF (perhaps due to other components available only in ELF) then you should have that option available next week.

I downloaded syslink_2_10_6_28 and I can confirm that the ELF loader is now working.

Thank your for all your help.

Regards,

John

The problem is that as from Linux Kernel 3.1 the generic IOMMU API has to be used. This means that the iommu_put()/iommu_get() functions (as used in omap3530_hal_mmu.c) are not available anymore. It would be great if you could help updating omap3530_hal_mmu.c to use the new generic IOMMU API.

I checked this with syslink version 2.20.00.14, with Linux Kernel 3.4.7. Errors similar like this one occur when compiling syslink-driver:

/home/dirk/nonSynced/gumstixTesting/syslink_2_20_00_14/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl/omap3530/omap3530dsp/Linux/omap3530_hal_mmu.c: In function ‘_OMAP3530_halMmuEnable’:
/home/dirk/nonSynced/gumstixTesting/syslink_2_20_00_14/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/family/hlos/knl/omap3530/omap3530dsp/Linux/omap3530_hal_mmu.c:362:9: error: implicit declaration of function ‘iommu_put’ [-Werror=implicit-function-declaration]

The SysLink product generally supports the kernels provided by the DVSDK/EZSDKs, and these haven't moved to the newer 3.x kernel versions yet.

So, there are currently no plans to update SysLink 2 to the Linux 3.x kernel.  

Should you make a patch to get SysLink 2 / OMAP3 working with the generic IOMMU subsystem in Kernel v 3.x, please consider posting it here so others can benefit.

Regards,

- Gil

HI Dirk,

If you are looking at using the 3.4 kernel, you might want to consider RPMSG which is also known as SysLink3. There are several benefits to using RPMSG, one of those being support for VirtualIO. Currently this only works on OMAP4, but several developers are looking at adding support for OMAP3. I'm seriously considering the use of RPMSG because I'm TI just doesn't have the bandwidth to update SysLink2 so that it works with the V3.x kernel.

Regards,

John

It would be very interesting to add OMAP3 support to RPMSG. Especially because VirtIO and the better interface, as this simplifies the development of applications.

Did anyone already start making RPMSG compatible with the OMAP3? I think all developers who are interested in this should work together to avoid doing duplicate work.

Hi Dirk,

Best place to coordinate this is IRC (channel #rpmsg on Freenode). I spoke to Ohad Ben-Cohen and he said there is another developer who is interested in working on an OMAP3 port but nothing is in the works currently. I would be willing to help but I'm not that familiar with XDC. Ohad thinks the port would be fairly easy.

Regards,

John.