Re: remoteproc: Load coprocessor code to the specific main memorylocation

From: Michal Simek
Date: Mon Feb 20 2012 - 09:22:15 EST


Ohad Ben-Cohen wrote:
On Thu, Feb 16, 2012 at 9:21 PM, Michal Simek <monstr@xxxxxxxxx> wrote:
IRC in init part Linux kick rtos which send which services are available.in
any format which is unknown to me.

Check out struct rpmsg_ns_msg - that's the exact format of the name
service notification messages (it's also mentioned by
Documentation/rpmsg.txt).

Of course, these messages, like any other message that is sent across,
need to begin with the usual rpmsg header. Its format is defined by
struct rpmsg_hdr.

To send the message from the rtos to Linux, you then need to grab a
buffer from the available ring (of the vring which is used by Linux to
receive messages), fill it with the message, put it in the used ring,
and kick the Linux side.

ok. Will try.


Please also correct me if I read the code wrongly. that mailbox in omap
driver is used just to say which buffer contains that message. Is it
correct?

We're using the mailbox payload in order to indicate which vring has
pending buffers.

ok.


I can create 15 sw signals to tell rtos which buffer contains message.

You can also just use a single interrupt and then, when it is
triggered, check both vrings for pending buffers. It's just another if
statement and shouldn't be too much of an overhead.

Will be help if I clear my code and send it to you for review? Maybe you
will see where the problem is.

I'm not sure I'll have the time to review it, but let's try to
progress this way and see how it goes.

Sorry I couldn't answer faster this week - I'm in ELC and was a bit
away from emails. I'll soon be flying back and that will keep me away
from emails again, but b/o next week I'll be online again.

that's ok. I will be out of office next week and then I will have panda board
to check how it works on working sample. Unfortunately I don't have enough time
to play with rpmsg this week too.
IRC you mentioned somewhere that you maybe will have firmware which is possible to
compiled by gcc and which doesn't required that TI tools. Am I correct or that was
something totally different?

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/