Re: Using remoteproc with ST-Ericsson modem.
From: Ohad Ben-Cohen
Date: Sat Mar 31 2012 - 15:05:47 EST
On Wed, Mar 28, 2012 at 7:31 PM, Sjur BRENDELAND
> 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 https://lkml.org/lkml/2012/1/11/162)
> 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 https://lkml.org/lkml/2012/1/11/167)
> e) devices for the different channels are instantiated. Each device
> is given similar configuration information to what is store in
> shared memory. (See https://lkml.org/lkml/2012/1/11/163)
> 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
> 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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/