Thread (14 messages) flat view 14 messages, 5 authors, 2022-01-10

Re: [PATCH v1 3/3] remoteproc: Add Renesas rcar driver

From: Julien Massot <hidden>
Date: 2021-11-15 14:42:07
Also in: linux-remoteproc, linux-renesas-soc

Hi Biju,
One question CR7 Can be master boot processor. In that case
How to avoid loading and booting  CR7 processor from Linux?
Reading boot modes??
Thanks for the question.

I did not test this case. There is also other scenarios where the
Cortex-R7 is started by an earlier component such as BL2, u-boot or
OP-Tee.
In these cases Linux should not try to start / stop this remote processor.
One idea could be to read the power status CR7PSTR / PWRSR7, or use
one of the MFIS register as a communication register. STM32 processor
use this last solution to indicate that the remote processor is
already started, in that scenario remoteproc driver starts in 'detached' state
instead of 'offline' state.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/remoteproc.h#n418

In that state, remoteproc driver can initiate communication with
this remote processor but will not try to start or to stop it.

That's something I have in mind, with an existing implementation there
https://github.com/iotbzh/linux/blob/iot/julien/rproc/drivers/remoteproc/rcar_rproc.c#L524
(that is not ready for upstream yet :)).

I guess this issue also exists when one device is dedicated to the secure world, so
the device exists, but not available for Linux. The most obvious (and dirty ?) solution is to keep
the device disabled in dts.

Regards,
Julien
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help