Messages in this thread | | | From | Ohad Ben-Cohen <> | Date | Sat, 31 Mar 2012 22:04:41 +0300 | Subject | Re: Using remoteproc with ST-Ericsson modem. |
| |
Hi Sjur,
On Wed, Mar 28, 2012 at 7:31 PM, Sjur BRENDELAND <sjur.brandeland@stericsson.com> 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 particular).
> 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 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 ?
Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |