[RFC] Passing device-tree to remoteproc?

[RFC] Passing device-tree to remoteproc?

[Yann Sionneau]

Hello,

How interesting to upstream Linux would it be to have a way for Linux 
kernel or user space to pass a device tree blob to remote processor when 
starting a remote proc FW?

For instance we could imagine something like this:

1/ user space does echo -n firmware.elf > 
/sys/class/remoteproc/remoteprocXXX/firmware

2/ user space does echo -n my_dt.dtb > 
/sys/class/remoteproc/remoteprocXXX/dtb

3/ user space does echo start > /sys/class/remoteproc/remoteprocXXX/state

We could also imagine that the kernel could load its own device tree 
into memory and puts the address to this memory zone in a resource of 
the resource table if some resource type is found.

But I think the user space based approach is more flexible as you could 
potentially specify a different DTB from the kernel itself.

What do you think?

Regards,

-- 

Yann

Re: [RFC] Passing device-tree to remoteproc?

[Yann Sionneau]

Hello,

On 1/23/24 14:32, Yann Sionneau wrote:
> Hello,
>
> How interesting to upstream Linux would it be to have a way for Linux 
> kernel or user space to pass a device tree blob to remote processor 
> when starting a remote proc FW?
>
> For instance we could imagine something like this:
>
> 1/ user space does echo -n firmware.elf > 
> /sys/class/remoteproc/remoteprocXXX/firmware
>
> 2/ user space does echo -n my_dt.dtb > 
> /sys/class/remoteproc/remoteprocXXX/dtb
>
> 3/ user space does echo start > /sys/class/remoteproc/remoteprocXXX/state

Any opinion on this proposal?

Thanks!

Regards,

-- 

Yann

Re: [RFC] Passing device-tree to remoteproc?

[Arnaud POULIQUEN]

Hello Yann,

On 1/30/24 11:20, Yann Sionneau wrote:
> Hello,
> 
> On 1/23/24 14:32, Yann Sionneau wrote:
>> Hello,
>>
>> How interesting to upstream Linux would it be to have a way for Linux kernel
>> or user space to pass a device tree blob to remote processor when starting a
>> remote proc FW?
>>
>> For instance we could imagine something like this:
>>
>> 1/ user space does echo -n firmware.elf >
>> /sys/class/remoteproc/remoteprocXXX/firmware
>>
>> 2/ user space does echo -n my_dt.dtb > /sys/class/remoteproc/remoteprocXXX/dtb
>>
>> 3/ user space does echo start > /sys/class/remoteproc/remoteprocXXX/state
> 
> Any opinion on this proposal?


Interesting use case. There is no concrete need in ST, but it raises the
question of providing extra data with the firmware to the remote processor.

In a first approach, my personal feeling is that the ELF and the DTB are
interdependent.
So having a mechanism to ensure coherency between both could be important.

Then it could be interesting to address the need in a more generic way
to be able to transfer extra data, for instance an audio tuning for a DSP.
Adding a specific sysfs for each specific need could not be a good idea in long
term.

Have you looked into some other approaches such as adding the DTB as a specific
section of your ELF file,or adding the support of a new format that packages
everything together (for instance FIP)?

Regards,
Arnaud

> 
> Thanks!
> 
> Regards,
> 

Re: [RFC] Passing device-tree to remoteproc?

[Mathieu Poirier]

Good day Yann,

On Fri, Feb 02, 2024 at 10:14:08AM +0100, Arnaud POULIQUEN wrote:
> Hello Yann,
> 
> On 1/30/24 11:20, Yann Sionneau wrote:
> > Hello,
> > 
> > On 1/23/24 14:32, Yann Sionneau wrote:
> >> Hello,
> >>
> >> How interesting to upstream Linux would it be to have a way for Linux kernel
> >> or user space to pass a device tree blob to remote processor when starting a
> >> remote proc FW?
> >>
> >> For instance we could imagine something like this:
> >>
> >> 1/ user space does echo -n firmware.elf >
> >> /sys/class/remoteproc/remoteprocXXX/firmware
> >>
> >> 2/ user space does echo -n my_dt.dtb > /sys/class/remoteproc/remoteprocXXX/dtb
> >>
> >> 3/ user space does echo start > /sys/class/remoteproc/remoteprocXXX/state
> > 
> > Any opinion on this proposal?
>
> 
> Interesting use case. There is no concrete need in ST, but it raises the
> question of providing extra data with the firmware to the remote processor.
> 

I agree with Arnaud.  From a mechanical point of view it is interesting and
doesn't pause a serious technical challenge.  That said I don't really
understand the motivation behind the idea.  More details the exact problem you
want to fix would be welcomed.

> In a first approach, my personal feeling is that the ELF and the DTB are
> interdependent.
> So having a mechanism to ensure coherency between both could be important.
> 
> Then it could be interesting to address the need in a more generic way
> to be able to transfer extra data, for instance an audio tuning for a DSP.
> Adding a specific sysfs for each specific need could not be a good idea in long
> term.
> 
> Have you looked into some other approaches such as adding the DTB as a specific
> section of your ELF file,or adding the support of a new format that packages
> everything together (for instance FIP)?

Here too I have to agree with Arnaud.

> Regards,
> Arnaud
> 
> > 
> > Thanks!
> > 
> > Regards,
> > 

Re: [RFC] Passing device-tree to remoteproc?

[Yann Sionneau]

Hello Arnaud, Mathieu,

On 2/5/24 22:05, Mathieu Poirier wrote:
> Good day Yann,
>
> On Fri, Feb 02, 2024 at 10:14:08AM +0100, Arnaud POULIQUEN wrote:
>> Hello Yann,
>>
>> On 1/30/24 11:20, Yann Sionneau wrote:
>>> Hello,
>>>
>>> On 1/23/24 14:32, Yann Sionneau wrote:
>>>> Hello,
>>>>
>>>> How interesting to upstream Linux would it be to have a way for Linux kernel
>>>> or user space to pass a device tree blob to remote processor when starting a
>>>> remote proc FW?
>>>>
>>>> For instance we could imagine something like this:
>>>>
>>>> 1/ user space does echo -n firmware.elf >
>>>> /sys/class/remoteproc/remoteprocXXX/firmware
>>>>
>>>> 2/ user space does echo -n my_dt.dtb > /sys/class/remoteproc/remoteprocXXX/dtb
>>>>
>>>> 3/ user space does echo start > /sys/class/remoteproc/remoteprocXXX/state
>>> Any opinion on this proposal?
>> Interesting use case. There is no concrete need in ST, but it raises the
>> question of providing extra data with the firmware to the remote processor.
>>
> I agree with Arnaud.  From a mechanical point of view it is interesting and
> doesn't pause a serious technical challenge.  That said I don't really
> understand the motivation behind the idea.  More details the exact problem you
> want to fix would be welcomed.
>
>> In a first approach, my personal feeling is that the ELF and the DTB are
>> interdependent.
>> So having a mechanism to ensure coherency between both could be important.
>>
>> Then it could be interesting to address the need in a more generic way
>> to be able to transfer extra data, for instance an audio tuning for a DSP.
>> Adding a specific sysfs for each specific need could not be a good idea in long
>> term.
>>
>> Have you looked into some other approaches such as adding the DTB as a specific
>> section of your ELF file,or adding the support of a new format that packages
>> everything together (for instance FIP)?

Our use case: passing the CPU frequency to the remote processor fw (in 
the future we might even need to pass other things like device nodes).

On other use cases we do indeed stuff the dtb into the ELF `.dtb` 
section and it works well, so I think indeed it solves our problem in 
the remoteproc case as well.

However, as you said, it's even cleaner to use FIP or FIT images to 
ensure tight link between the ELF and the dtb (it could even allow to do 
signature verification).

I hope our use case is more clear now :)

Thanks a lot for your answers!

Regards,

-- 

Yann