Re: [PATCH 1/1] remoteproc: extend customized fw loader to cover request and release

Re: [PATCH 1/1] remoteproc: extend customized fw loader to cover request and release

[Ohad Ben-Cohen]

Hi Tzu-Jung Lee,

On Mon, Aug 6, 2012 at 10:24 AM, Tzu-Jung Lee <roylee17@gmail.com> wrote:
> Previously, the remoteproc mandates an actual ELF firmware in order to
> parse the resource table and boot the remoteproc.
>
> An fw loader abstraction was added in v3.61-rc1 to make the ELF as a
> "default" handler, and allows firmwares in other formats to be loaded.
>
> However, in our use cases, we don't actually have a firmware for linux
> to load. The remote processor always boots first, and then boots the
> rest of processors that running linux.

Can you describe your use case some more ?

What parts in remoteproc are actually helpful for you (not much I
guess if Linux doesn't control the life cycle of the remote processor
in your case) ?

Do you use rpmsg ?

> In this case, forging an binary firmware just for the resource table
> creates a burden for maintenence.
> Allowing the firmware request/release function to be customized gives
> developers to construct the reqource table in memory, instead of loading
> one from filesystem.

I'm not sure this is an ideal abstraction though.

The problem you describe is architectural and not necessarily related
with a specific binary format, which this patch ties it up with (by
abstracting it away in rproc_fw_ops). It seems that a
binary-format-agnostic solution is preferable, because it could then
be utilized by any platform, regardless of the binary format it uses.

In general we prefer not to adopt a solution that puts the resource
table in the kernel, because that means redundant churn and
compatibility issues, as the resource table is inherently coupled with
the software running on the remote processor, and not with the Linux
kernel.

An easy solution is to allow loading an external stand-alone resource
table from the filesystem. We've discussed this in the past and
several parties showed interest. Will it help you ?

Another possible solution is to allow the low level rproc driver to
provide the remoteproc framework a pointer to an in-memory resource
table. This may prove useful in case the remote processor is already
up when Linux boots, and the resource table is already loaded to
memory.

> Change-Id: I0aa071dc1bd775eed6ea0822cff0fe2fc1b12b45

PS - no need to provide these tags when sending patches upstream.

Thanks,
Ohad.

Re: [PATCH 1/1] remoteproc: extend customized fw loader to cover request and release

[Tzu-Jung Lee]

Hi Ohad,

On Mon, Aug 6, 2012 at 10:16 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Hi Tzu-Jung Lee,
>
> On Mon, Aug 6, 2012 at 10:24 AM, Tzu-Jung Lee <roylee17@gmail.com> wrote:
>> Previously, the remoteproc mandates an actual ELF firmware in order to
>> parse the resource table and boot the remoteproc.
>>
>> An fw loader abstraction was added in v3.61-rc1 to make the ELF as a
>> "default" handler, and allows firmwares in other formats to be loaded.
>>
>> However, in our use cases, we don't actually have a firmware for linux
>> to load. The remote processor always boots first, and then boots the
>> rest of processors that running linux.
>
> Can you describe your use case some more ?

It's three processors AMP SoC, the first powered on processors runs
 an RTOS and boots up the other two which run linux.

> What parts in remoteproc are actually helpful for you (not much I
> guess if Linux doesn't control the life cycle of the remote processor
> in your case) ?
>
> Do you use rpmsg ?

Yes, I'm using rpmsg.
And actually the remoteproc provides a good abstraction and the generic
facilities sysfs/debugfs handling, resource format, vring allocation, etc...
And the start/stop/kick API also serves as good place for handshaking
with the remote processors. Overall, most of the framework works well with
our platform, and the difference can be hidden in the platform priv
data structure.

>> In this case, forging an binary firmware just for the resource table
>> creates a burden for maintenence.
>> Allowing the firmware request/release function to be customized gives
>> developers to construct the reqource table in memory, instead of loading
>> one from filesystem.
>
> I'm not sure this is an ideal abstraction though.

Agree.
The patch may not solve this, but it should address some issues I'm having.

> The problem you describe is architectural and not necessarily related
> with a specific binary format, which this patch ties it up with (by
> abstracting it away in rproc_fw_ops). It seems that a
> binary-format-agnostic solution is preferable, because it could then
> be utilized by any platform, regardless of the binary format it uses.

> In general we prefer not to adopt a solution that puts the resource
> table in the kernel, because that means redundant churn and
> compatibility issues, as the resource table is inherently coupled with
> the software running on the remote processor, and not with the Linux
> kernel.

Yes, that's the point.

The format issue has been addressed by the fw format handler.
But we still need to address where the data come from.
Even it is in ELF format, it may not necessarily come from root file system.
It can be loaded from MTD partition or constructed/derived from the cmdline.

> An easy solution is to allow loading an external stand-alone resource
> table from the filesystem. We've discussed this in the past and
> several parties showed interest. Will it help you ?

Actually, I've been using the this approach for the past few weeks.
I forged an ELF file containing the resource table, and dummy loadable
sections, otherwise it  failed the sanity checks. Until yesterday I merged
and found the fw format handler support in v3.6-rc1, and wondered if we
can just extend it a little bit to not load (bypass) the firmware at all.

> Another possible solution is to allow the low level rproc driver to
> provide the remoteproc framework a pointer to an in-memory resource
> table. This may prove useful in case the remote processor is already
> up when Linux boots, and the resource table is already loaded to
> memory.

That's what I'm trying to do, and it has two things needs to be address.

  1)  Make the firmware loading step "optional" in the booting process.

  2)  Allow the remoteproc use an customized handler to get the resource table.

Thanks,
Roy

Re: [PATCH 1/1] remoteproc: extend customized fw loader to cover request and release

[Ohad Ben-Cohen]

Hi Roy,

On Mon, Aug 6, 2012 at 7:43 PM, Tzu-Jung Lee <roylee17@gmail.com> wrote:
> That's what I'm trying to do, and it has two things needs to be address.
>
>   1)  Make the firmware loading step "optional" in the booting process.
>
>   2)  Allow the remoteproc use an customized handler to get the resource table.

Before we start digging into this, can you please tell which platform
are you working with ? is it upstream yet ?

Last we talked you couldn't yet disclose the platform identity. If
it's not upstream yet, we might prefer to postpone these discussions
until it is, to avoid unnecessary churn.

Thanks,
Ohad.