linux-kernel - Re: Using remoteproc with ST-Ericsson modem.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK=WgbYz7_syim+LoTM-6MLJ=_8tsEuDQ+=fwOTfzOriPrMAEw@mail.gmail.com>
Date:	Sat, 31 Mar 2012 22:04:41 +0300
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"sjurbren@...il.com" <sjurbren@...il.com>,
	Loic PALLARDY <loic.pallardy@...ricsson.com>,
	Ludovic BARRE <ludovic.barre@...ricsson.com>
Subject: Re: Using remoteproc with ST-Ericsson modem.

Hi Sjur,

On Wed, Mar 28, 2012 at 7:31 PM, Sjur BRENDELAND
<sjur.brandeland@...ricsson.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/