On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark mgro...@ti.com wrote:
2. We added a special section (resource table) that is interpreted as part
of the loading process. The tool that generates our simple format just
recognizes a named section (.resource_table), so perhaps that could be
done
On Tue, Jun 28, 2011 at 4:26 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark mgro...@ti.com wrote:
2. We added a special section (resource table) that is interpreted as part
of the loading process. The tool that generates our simple format just
From: Ohad Ben-Cohen
Sent: Saturday, June 25, 2011 6:12 PM
Hi Stephen,
On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd sb...@codeaurora.org wrote:
Instead of devising a new firmware format, we decided
to just stick with elf and parse the headers in the kernel because we
needed them
Hi Stephen,
On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd sb...@codeaurora.org wrote:
This sounds a lot like SMD (shared memory driver) on MSM. The main
difference I see is that SMD uses the platform bus instead of the virtio
bus and it has its own protocol for channel allocation.
Yeah,
On Sat, Jun 25, 2011 at 6:11 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Hi Stephen,
On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd sb...@codeaurora.org wrote:
This sounds a lot like SMD (shared memory driver) on MSM. The main
difference I see is that SMD uses the platform bus instead of the
On 06/21/2011 12:18 AM, Ohad Ben-Cohen wrote:
* Rpmsg: a virtio-based messaging bus that allows kernel drivers to
communicate with remote processors available on the system. In turn,
drivers could then expose appropriate user space interfaces, if needed
(tasks running on remote processors
On 6/21/2011 3:18 AM, Ohad Ben-Cohen wrote:
Modern SoCs typically employ a central symmetric multiprocessing (SMP)
application processor running Linux, with several other asymmetric
multiprocessing (AMP) heterogeneous processors running different instances
of operating system, whether Linux or
From: Michael Williamson
Sent: Thursday, June 23, 2011 5:23 AM
...
I'd like to kick the tires on this with a da850 based platform (MityDSP-L138).
Any chance you might be able to share the stuff you did on the remote side
(DSP/BIOS adaptations for rpmsg, utils for ELF or COFF conversion to
On Thursday 23 June 2011 18:27:10 Grosen, Mark wrote:
First, we are not abandoning DSPLINK. We have many users of this, even
though it is out-of-tree, and we will continue to support it. That said, we
do intend to make this new design the basis for DSPLINK-like
functionality. It's designed to
From: Arnd Bergmann
Sent: Thursday, June 23, 2011 11:47 AM
Subject: Re: [RFC 0/8] Introducing a generic AMP/IPC framework
On Thursday 23 June 2011 18:27:10 Grosen, Mark wrote:
First, we are not abandoning DSPLINK. We have many users of this, even
though it is out-of-tree, and we
Hi Arnd,
On Tue, Jun 21, 2011 at 5:20 PM, Arnd Bergmann a...@arndb.de wrote:
This looks really nice overall, but I don't currently have time for a
more in-depth review. My feeling is that you are definitely on the right
track here, and the plans you list as TODO to continue are all good.
On Wednesday 22 June 2011, Ohad Ben-Cohen wrote:
One point I noticed is the use of debugfs, which you should probably
replace at some point with a stable API, e.g. your own debugfs-like
file system, but there is no hurry to do that now.
debugfs is only being used to expose debugging info
On Wed, Jun 22, 2011 at 4:05 PM, Arnd Bergmann a...@arndb.de wrote:
Ok, I see. In that case I agree that using debugfs is fine, but I would
recommend trying to use fewer macros and just open-coding the file
operations for better readability.
Sure thing. It didn't end up saving much code
Modern SoCs typically employ a central symmetric multiprocessing (SMP)
application processor running Linux, with several other asymmetric
multiprocessing (AMP) heterogeneous processors running different instances
of operating system, whether Linux or any other flavor of real-time OS.
OMAP4, for
On Tue, Jun 21, 2011 at 10:50 AM, Ohad Ben-Cohen o...@wizery.com wrote:
root@omap4430-panda:~# cat /debug/remoteproc/omap-rproc.1/state
running (2)
At this point, the two remote M3 cores also start dumping trace logs to
shared memory buffers, which are exposed by debugfs entries:
Hi Ohad,
On Tuesday 21 June 2011, Ohad Ben-Cohen wrote:
This patch set adds a generic AMP/IPC framework which makes it possible to
control (power on, boot, power off) and communicate (simply send and receive
messages) with those remote processors.
This looks really nice overall, but I don't
On Tue, Jun 21, 2011 at 8:20 AM, Arnd Bergmann a...@arndb.de wrote:
Hi Ohad,
On Tuesday 21 June 2011, Ohad Ben-Cohen wrote:
This patch set adds a generic AMP/IPC framework which makes it possible to
control (power on, boot, power off) and communicate (simply send and receive
messages) with
17 matches
Mail list logo
