Re: [PATCH 0/2] remoteproc: k3: Recover a crashed remote core

[Francesco Valla <francesco@valla.it>]

Hi Chrispine,

On Tue, Nov 10, 2026 at 12:55:54AM +0100, Francesco Valla wrote:
> Hi Chrispine,
> 
> On Mon, Nov 09, 2026 at 07:04:30PM +0300, Chrispine Tinega wrote:
> > Hi Francesco,
> > 
> > On Mon, 9 Nov 2026, Francesco Valla wrote:
> > > If you share details on the Zephyr side of things, I can test this
> > > against rproc-next on a AM67A (BeagleY-AI).
> > 
> > Thank you, that would help. The AM67A has no M4F, so patch 2 does not
> > apply there. Patch 1 does: the R5F driver uses the same mailbox
> > callback, and it keeps recovery disabled. So on the main R5F I would
> > expect this:
> > 
> > - Without the series, the crash is only logged, and the core stays in
> >   "running" until the next boot.
> > - With the series, the core moves to "crashed", the crash is counted,
> >   and it can be stopped and started again through sysfs.
> > 
> > The Zephyr side is upstream's openamp_rsc_table sample with one file
> > added. The handler sends RP_MBOX_CRASH over the mailbox before it
> > halts, and a thread forces a fault 20 s after boot. This builds on
> > Zephyr v4.5.0 for beagley_ai/j722s/main_r5f0_0, but I have not run it
> > on that board.
> 
> I did run it on the "MCU" R5F, and I think I found a bug... in the Zephyr
> ti_dmtimer code! With that fixed, the functionality seems to be working
> as expected, but I'll stress it a bit before declaring a Tested-by.
> 

An update on this. Recovery is definitley _not_ working on R5F remote
cores in case of crash, because the reset action that is required from
them to re-start correctly is in do_unprepare(), which the recovery
action does not call (while sysfs does). This is of course out of the
scope of your patch set, but has to be considered (maybe deserves a
note in the commit message?).

Regards,
Francesco