linux-kernel - 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]

Date:	Tue, 27 Mar 2012 15:15:57 +0200
From:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
To:	Arnd Bergmann <arnd@...db.de>, Ohad Ben-Cohen <ohad@...ery.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"sjurbren@...il.com" <sjurbren@...il.com>
Subject: Using remoteproc with ST-Ericsson modem. 

Hi Ohad,

[Arnd]
>Remoteproc and rpmsg are now in the arm-soc tree and will be merged
>upstream for v3.4, I suggest you discuss with Ohad how to best hook in
>there.

I would like to discuss with how to use remoteproc for the ST-Ericsson
modem. For a while, I have been working on a shared memory interface
for ST-Ericsson modems. I already have one version in linux-next, but
I'm planning on redoing parts of the implementation. As part of this, I
want to investigate if I can use remoteproc for handling the start-up
of our modem. One solution could be to make firmware and resource handling
pluggable.

The principles for remoteproc and modem_shm are not so different.
 a) We have a number of channels in shared memory, and the shm-address is
   predefined.
 b) Boot images are copied into shared memory before start.

However, we have a couple of requirements that are different.
- We don't use a ELF binary for resource definition. We have resource
  definitions in a binary format outside the binary. (I'm afraid I'm
  not able to change this).
- We need user-space to access sequential data streams.
- We use CAIF (a muxing protocol) implemented in the networking subsystem.

In order to use remoteproc, I think it could be a good idea to make the
firmware, resource and possible Virtio handling pluggable. E.g:

static struct rproc_ops rproc_ops = {
      ...
       .fw_sanity_check = fw_sanity_check,
       .fw_resource_handler = fw_resource_handler,
       .fw_load = fw_load,
       .fw_config_virtio = fw_config_virtio,
};

I think we need to be able to launch other Virtio device types than
VIRTIO_ID_RPMSG as well. Most likely, I need to make a CAIF specific
VIRTIO type due to the fact that I need RX direction to be reversed
(modem must be able to post it's payload buffer to Virtio ring).

[Sjur:]
>> For the stream interface it's tempting to reuse the ring buffer interface
>> to the modem from last time. But perhaps the Virtio-console could be as the
>> user-space interface...
[Arnd:]
>sounds doable, but again Ohad may have better suggestions as well.

We also define stream channels. As mentioned, I'm considering the possibility
of reusing Virtio console.

So, I'd really like to get your viewpoint and ideas for how we could use
remoteproc to manage the ST-Ericsson modem.

Regards,
Sjur