Re: Using remoteproc with ST-Ericsson modem.

From: Ohad Ben-Cohen
Date: Sat Mar 31 2012 - 15:05:47 EST

Hi Sjur,

On Wed, Mar 28, 2012 at 7:31 PM, Sjur BRENDELAND
<sjur.brandeland@xxxxxxxxxxxxxx> wrote:
> Hm, my impression was that Virtio only supported single bits for
> configuration information.

You probably refer to virtio's features bitmap, which is how virtio
peers synchronize the features they both support.

Virtio also supports device-specific variable-length configuration
fields - take a look at struct virtio_config_ops (get/set in

> I'm afraid not. I cannot change the layout for the modem boot loader.
> The boot image start with a "table of contents" defining the content
> of the image.

What binary format is the boot image itself ? ELF ? something else ?

> The startup sequence run something like this (simplified).
> a) configuration data related to channels are sent from user-space
>   to the kernel module modem_shm via gen-netlink
>   (see
> b) The firmware image (containing TOC and the executable) is sent to
>   kernel via firmware framework.
> c) when all channels have been sent to modem_shm, configuration data
>   for each channel is processed and location of each channel in
>   shared memory is calculated. The "kick" bits are also assigned
>   to each channel.
> d) The modem-image starts with a table (TOC). A new pointer to a
>   IPC-TOC containing channel configuration is added to the TOC.
>   The executable and channel configuration needed by the modem
>   is stored in shared memory.
>   (See
> e) devices for the different channels are instantiated. Each device
>   is given similar configuration information to what is store in
>   shared memory. (See
> f) User space turns the modem ON, and boots using the initial
>   firmware from shared-memory.
> g) modem's boot stage-2 starts, additional modem binaries are loaded
>   using stream channels.
> h) when boot stage-2 is complete, the CAIF device is enabled.

Cool, thanks for the details!

> The current memory layout is something like this:
> +------------+
> |       TOC      |----+
> |            |--+ |
> +------------+  | |
> | Boot IMG       |<-+ |
> +------------+    |
> | RX Data        |    |
> +------------+    |
> | IPC TOC        |<---+
> +------------+
> | RX Ch Decr |
> +------------+
> | TX Ch Decr |
> +------------+
> | TX Data        |
> +------------+

Which parts of this are set in stone ? only the TOC or additional
regions as well ?

> This is the same thing CAIF does, so multiplexing is not something I'm
> looking for.

I saw you created an SHM bus, which matches SHM drivers to SHM devices
(i.e. channels). I guess you did that because you have some code in
common which all SHM drivers/devices use ? maybe some low level
transport layer ?

This sounds similar to rpmsg in hindsight, but I couldn't find yet the
relevant code to really tell: Most of shm_bus.c looks like very
minimal boilerplate bus code. Maybe the genio_* API is the shared code
(though I could only find a dummy version of that API in linux next) ?

> I like the attitude :-), what new features have you planned for rpmsg?

Anything you need :)

Some of the obvious stuff might be zero copy I/O, user space API,
static channel configuration, runtime PM, recovery, etc.. (there's
more). Sometimes it's a pure rpmsg feature, and sometimes it's
involved with remoteproc.

But we really just evolve according to requirements - we don't have a
rigid roadmap.

> Yes, I tend to think I should use virtio directly, but I have not made up
> mind. I'll probably come back to this later.

What's the vrings layout you will be using (off the top of your head)
? Separate vrings per driver/device or shared vrings ?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at