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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Julien,

> Subject: Re: [PATCH v1 3/3] remoteproc: Add Renesas rcar driver
> 
> 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. 

OK.

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.


OK. But Linux can check whether CR7 is alive at frequent interval and issue
Soft-reboot, if there is a  hang.

> One idea could be to read the power status CR7PSTR / PWRSR7, or use one of
> the MFIS register as a communication register.

I know MFIS is used for communication between CR7 and CA-57. But don't know
much details.

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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2F
> include%2Flinux%2Fremoteproc.h%23n418&data=04%7C01%7Cbiju.das.jz%40bp.
> renesas.com%7C945a25980e5a49cc361a08d9a846020c%7C53d82571da1947e49cb4625a1
> 66a4a2a%7C0%7C0%7C637725840924834250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yXH
> 2qBpmUI2YtZRnApFdWt6iONcFKDPSPa45AirThBw%3D&reserved=0
> 
> 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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Fiotbzh%2Flinux%2Fblob%2Fiot%2Fjulien%2Frproc%2Fdrivers%2Fremoteproc%2
> Frcar_rproc.c%23L524&data=04%7C01%7Cbiju.das.jz%40bp.renesas.com%7C945
> a25980e5a49cc361a08d9a846020c%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7
> C637725840924834250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WYKygEUiXyliOmX2CUxk
> Yfj5pq2QOmZC%2BGtXRAlB%2Bws%3D&reserved=0
> (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. 

May be for prototyping activity, if some one wants to run an RTOS on CR7.
This will be a good solution. Linux will load and boot CR7 which
Run an RTOS which communicates with Linux. Once communication established
Linux can check the health of CR7 at frequent intervals and take necessary action.

Regards,
Biju


The most obvious
> (and dirty ?) solution is to keep the device disabled in dts.
> 
> Regards,
> Julien





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux