On 01/02/2018 02:59 PM, Adam Ford wrote:
> On Tue, Jan 2, 2018 at 2:17 PM, Suman Anna <s-anna@xxxxxx> wrote:
>> Hi Adam,
>>
>> On 12/27/2017 08:04 AM, Adam Ford wrote:
>>> I am struggling trying to get the DSP on an OMAP3630/3730 running. I
>>> am looking at the remote proc functions and comparing omap, keystone
>>> and davinci's implementation, and it appears as if we need to set
>>> aside some shared memory as part of the DSP container which the omap3
>>> device tree is currently missing.
>>
>> What stack are you trying to run on the DSPs (DSP/Bridge or SysLink)?
>> DSP/Bridge driver was removed from mainline as it was not being
>> maintained, and SysLink support was completely out of tree.
>
> I am open to whatever is the path of least resistance. I was hoping
> to use the TI IPC tools which appear to use remoteproc, but I'll take
> whatever I can get.
>
>>
>> Keystone remoteproc driver was added with DT support to begin with, and
>> I have recently extended the DT support to Davinci remoteproc driver.
>> The OMAP remoteproc driver was originally written for OMAP4 and beyond
>> for non-DT devices, and it still lacks the DT support on mainline
>> (blocked on various DT conversion dependencies - most of them are in and
>> it's currently blocked on the hwmod cleanup).
>
> That makes sense. I assumed this was being either orphaned or
> abandoned which is why I e-mailed.
No, it is not abandoned as the OMAP remoteproc driver will be reused for
the DSPs and IPUs (Dual-Cortex M3s or M4s) for the current AM57xx/DRA7xx
SoCs as well.
>>
>>> Adding these to the device tree looks like it's only part of it. When
>>> I look at the davinci and keystone remote proc drivers, they are also
>>> looking for specific 'compatible' DSP's. The omap3.dtsi file
>>> references the ti,omap3-c64, but I can't find any references to it, so
>>> it seems like there quite a bit missing to make remote proc work with
>>> the OMAP3.
>>
>> Yes, these compatibles were originally added as part of a PM support in
>> core mach-omap2 layers but without the necessary backing drivers
>> (remoteproc or otherwise) in commit 476b679a5d785 ("arm/dts: OMAP3+: Add
>> mpu, dsp and iva nodes"). Technically, the current compatible is
>> incorrect for OMAP4, as the OMAP4 DSP is not the same as the OMAP3 DSP.
>
> Can the OMAP4 or L-138 DSP stuff be adapted to the OMAP35/36.37? I
> know they are all technically different, but I don't know how
> different they are.
The clocking and reset SoC integration on OMAP-L138 is very different
from OMAP4. Ideally, any OMAP3 support would be reusing the OMAP
remoteproc driver because of the common underlying PRCM and hwmod
infrastructure. The Linux-side is relatively easy, since you only need
to hook in the appropriate platform pieces (reset, timers, boot vector
programming etc), but the DSP-side is difficult since the ISAs are all
different between OMAP3, OMAP4, OMAP-L138, so you need the necessary
support from the chosen RTOS. Any IPC modules/libraries would look
similar though because of the common functional behavior of OMAP
mailboxes, virtio transports.
>
>> Do note that the PM init code was removed as part of the legacy non-DT
>> code cleanup in cb6675d6a868 ("ARM: OMAP2+: Remove legacy PM init").
>>
>>>
>>> Might someone (like Anna or someone from TI) have a code stub or a
>>> starting point that I might be able to use to try and finish the job
>>> of getting the DSP working with a modern kernel?
>>
>> I have the DT support on downstream TI kernels for OMAP4+ SoCs, and it
>> is easy to extend that to OMAP3 but it will depend on what stack you are
>> planning to use on the DSP-side. Most recent reference I have is
>> http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=shortlog;h=refs/heads/rpmsg-ti-linux-4.9.y.
>> I will be porting to 4.14 within the next 30 days and should be
>> available on the same tree.
>
> Once the device tree side is complete, what would be required to make
> a simple 'hello world' demo to show the DSP is communicating?
A simple 'hello world' can be achieved if using the proper TI BIOS
versions, and adding a new platform to some of the existing rpmsg-based
RTOS-side IPC code bases present in public trees. I have to double
check, but I believe the latest TI tools (SYS/BIOS, XDC etc) have
dropped the support for the C64P family (DSPs present in OMAP3, OMAP4
and OMAP5), so you would have to play around with some older versions of
the RTOS and IPC code bases to get going on OMAP3.
regards
Suman
>
>>
>> Do note that the rpmsg transport was never added to the OMAP3 DSP so
>> extending OMAP remoteproc driver with virtio rpmsg support will require
>> some work on the DSP-side s/w. Also, DSP/Bridge stack was never ported
>> to use the OMAP remoteproc driver either. But if it is only the DT
>> portions that you are looking for, the above tree should have the
>> necessary stuff for you to get started.
>
> We sell System-On-Modules based on the OMAP35, DM37 and L-138. At
> this point, any DSP functionality is better than nothing. We have
> customers who want to buy SOM's but are questioning the age and
> support since much of the DSP and 3D acceleration support seems to
> have stopped on the TI side. Any support you can provide is greatly
> appreciated.
>
> adam
>>
>> regards
>> Suman
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
