From: Francesco Valla <francesco@valla.it>
To: Chrispine Tinega <dev@chrispinetinega.com>
Cc: andersson@kernel.org, mathieu.poirier@linaro.org,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] remoteproc: k3: Recover a crashed remote core
Date: Tue, 10 Nov 2026 00:55:54 +0100 [thread overview]
Message-ID: <avJbc4Aebflkjgap@bywater> (raw)
In-Reply-To: <20261109160431.720498-1-dev@chrispinetinega.com>
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.
>
> Copy samples/subsys/ipc/openamp_rsc_table, add src/crash.c below, and
> list it in CMakeLists.txt:
>
> target_sources(app PRIVATE src/main_remote.c src/crash.c)
>
> Build it:
>
> west build -b beagley_ai/j722s/main_r5f0_0 path/to/the/copy
>
> Load build/zephyr/zephyr_openamp_rsc_table.elf as the main R5F's
> firmware. After 20 s, check the state:
>
> cat /sys/class/remoteproc/remoteprocN/state
> dmesg | grep -i crash
>
> To bring the core back:
>
> echo stop > /sys/class/remoteproc/remoteprocN/state
> echo start > /sys/class/remoteproc/remoteprocN/state
>
> It will crash again 20 s after each start. That is a quick way to check
> that a second crash is handled as well.
>
> --- src/crash.c ---
> /*
> * Report a fatal error to Linux as RP_MBOX_CRASH, then force one.
> */
> #include <zephyr/kernel.h>
> #include <zephyr/drivers/ipm.h>
> #include <zephyr/fatal.h>
> #include <zephyr/logging/log_ctrl.h>
>
> #define RP_MBOX_CRASH 0xFFFFFF02U
> #define CRASH_AFTER_S 20
>
> static const struct device *const crash_ipm =
> DEVICE_DT_GET(DT_CHOSEN(zephyr_ipc));
>
> void k_sys_fatal_error_handler(unsigned int reason,
> const struct arch_esf *esf)
> {
> uint32_t crash = RP_MBOX_CRASH;
>
> ARG_UNUSED(reason);
> ARG_UNUSED(esf);
>
> LOG_PANIC();
> /* The FIFO can be briefly full of vring kicks. */
> for (int i = 0; i < 100; i++) {
> if (ipm_send(crash_ipm, 0, 0, &crash, sizeof(crash)) != -EBUSY)
> break;
> k_busy_wait(100);
> }
> (void)arch_irq_lock();
> for (;;)
> arch_cpu_idle();
> }
>
> static void crash_thread(void *a, void *b, void *c)
> {
> k_sleep(K_SECONDS(CRASH_AFTER_S));
> k_oops();
> }
>
> K_THREAD_DEFINE(crash_tid, 1024, crash_thread, NULL, NULL, NULL,
> K_PRIO_PREEMPT(10), 0, 0);
> --- end ---
>
> Regards,
> Chrispine
>
Regards,
Francesco
prev parent reply other threads:[~2026-11-09 23:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 5:48 [PATCH 0/2] remoteproc: k3: Recover a crashed remote core Chrispine Tinega
2026-11-09 5:48 ` [PATCH 1/2] remoteproc: k3: Report a remote crash to the remoteproc core Chrispine Tinega
2026-11-11 22:21 ` Francesco Valla
2026-11-12 12:39 ` Chrispine Tinega
2026-11-09 5:48 ` [PATCH 2/2] remoteproc: k3-m4: Leave crash recovery enabled Chrispine Tinega
2026-11-09 6:59 ` [PATCH 0/2] remoteproc: k3: Recover a crashed remote core Francesco Valla
2026-11-09 16:04 ` Chrispine Tinega
2026-11-09 23:55 ` Francesco Valla [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avJbc4Aebflkjgap@bywater \
--to=francesco@valla.it \
--cc=andersson@kernel.org \
--cc=dev@chrispinetinega.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.