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=WgbaCysxO32y9zz0QuAdPysK2kU5p6SaQ4nFdcRyeWSyqhA@mail.gmail.com>
Date:	Wed, 28 Mar 2012 17:55:25 +0200
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 11:33 AM, Sjur BRENDELAND
<sjur.brandeland@...ricsson.com> wrote:
> 1) Resource descriptors and parameters such as size of vring,
> size of the "carved-out" shared memory

We have that already today - the firmware controls these kind of
parameters (and more).

> as well as proprietary (CAIF specific) parameters

Not sure what exactly do you mean here - can you pls elaborate ?

> should be supported. These parameters
> must be available to the Virtio device-drivers

Virtio configuration is done via the virtio config space, which we
should already be supporting (untested though, because we didn't need
this yet).

> (CAIF interface),
> and to the modem. The resource/parameter configuration has to be
> stored in shared memory before booting the modem.

Yeah, this is what we do today with the resource table.

> 2a) The resource descriptors and configuration parameters are pre-
> formatted in the proprietary binary format.

What does mandate this proprietary binary format ? Can you just
directly use remoteproc's resource table format instead (i.e. an
extensible collection of type-value pairs) ?

> Remoteproc (or it's plugin)
> must then be able to parse this proprietary format, extract
> configuration parameters, and load the binary image into shared memory.
> OR
> 2b) Configuration parameters and firmware can be provided separately.
> The remoteproc (or it's plugin) must be able to format the provided
> configuration parameters in a proprietary format understood by the
> modem boot-loader and store the firmware and configuration in
> shared memory. A user-space API for configuration (e.g. netlink)
> must be supported.
> OR
> 2c) As in 2a, the image in proprietary format containing both firmware
> and parameters could be provided. In addition configuration parameters
> could be provided to remoteproc separately. The binary-image and
> configuration parameters will in this case hold identical configuration
> information. A user-space API for configuration (e.g. netlink)
> must be supported.
>
> In my case, the best solution seems to be 2a). I.e to parse parameters
> from the provided firmware, and avoid any extra configuration parameters
> provided from user-space. It seems to me we could do this by adding a
> callback function to remoteproc that parses the firmware and returns
> a resource table.

You have suggested several possible solutions, but I'd really prefer
to understand the problem first please :)

Can you please explain how do things work for you today ? binary
formats, image/configuration, how things boot/load/get-configured,
etc..

If I'll understand your requirements (hardware, relevant firmware code
which can't be changed and may impose the design, etc..) it will help
me find with you a suitable solution.

> However there might be new requirements we have in common such as:
> buffer pools with different fixed sized buffers, zero-copy handling of
> SKBs (TX), and DMA for (RX). Even if I end up not using rpmsg we should
> definitely look for opportunities for common code. I think we will be
> trying to solve the same type of problems.

The main thing that rpmsg provides over virtio is the multiplexing of
several channels/drivers over the same set of vrings and a simple API
for doing TX/RX.

If you think you will have to implement similar plumbing, then please
consider using rpmsg - it will save you time and effort (any other gap
that rpmsg does not yet provide can be easily solved - I wouldn't
worry about it).

OTOH, if you don't need that aforementioned plumbing, then directly
using virtio does have its merit of course.

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/