From: Leonard Crestez <cdleonard@gmail.com> To: Mathieu Poirier <mathieu.poirier@linaro.org>, Tanmay Shah <tanmay.shah@amd.com> Cc: Bjorn Andersson <andersson@kernel.org>, Michal Simek <michal.simek@amd.com>, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] remoteproc: zynqmp: Add coredump support Date: Thu, 28 Mar 2024 10:17:13 +0200 [thread overview] Message-ID: <07183fd8-a5a1-4cae-b317-d703ef7c1de1@gmail.com> (raw) In-Reply-To: <ZfhxUJjrcYfqt9Nd@p14s> On 3/18/24 18:52, Mathieu Poirier wrote: > Hi Leonard, > > I have queued patches for this driver that will break this patch. Please > re-submit when v6.9-rc1 is out and rproc-next has been updated, which should be > around the middle of next week. Hello, It's been a while - v6.9-rc1 is out and rproc-next has been rebased on top of it. But the coredump patch still applies? I expected some unrelated xlnx_r5_remoteproc patches to cause conflicts but there's nothing there. It seems to me that the patch can be applied as-is and no resend is required. Am I missing something? -- Regards, Leonard > On Sat, Mar 16, 2024 at 08:16:42PM +0200, Leonard Crestez wrote: >> Supporting remoteproc coredump requires the platform-specific driver to >> register coredump segments to be dumped. Do this by calling >> rproc_coredump_add_segment for every carveout. >> >> Also call rproc_coredump_set_elf_info when then rproc is created. If the >> ELFCLASS parameter is not provided then coredump fails with an error. >> Other drivers seem to pass EM_NONE for the machine argument but for me >> this shows a warning in gdb. Pass EM_ARM because this is an ARM R5. >> >> Signed-off-by: Leonard Crestez <cdleonard@gmail.com> >> --- >> >> Tests were done by triggering an deliberate crash using remoteproc >> debugfs: echo 2 > /sys/kernel/debug/remoteproc/remoteproc0/crash >> >> This was tested using RPU apps which use RAM for everything so TCM dump >> was not verified. The freertos-gdb script package showed credible data: >> >> https://github.com/espressif/freertos-gdb >> >> The R5 cache is not flushed so RAM might be out of date which is >> actually very bad because information most relevant to determining the >> cause of a crash is lost. Possible workaround would be to flush caches >> in some sort of R5 crash handler? I don't think Linux can do anything >> about this limitation. >> >> The generated coredump doesn't contain registers, this seems to be a >> limitation shared with other rproc coredumps. It's not clear how the apu >> could access rpu registers on zynqmp, my only idea would be to use the >> coresight dap but that sounds difficult. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Leonard Crestez <cdleonard@gmail.com> To: Mathieu Poirier <mathieu.poirier@linaro.org>, Tanmay Shah <tanmay.shah@amd.com> Cc: Bjorn Andersson <andersson@kernel.org>, Michal Simek <michal.simek@amd.com>, linux-remoteproc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] remoteproc: zynqmp: Add coredump support Date: Thu, 28 Mar 2024 10:17:13 +0200 [thread overview] Message-ID: <07183fd8-a5a1-4cae-b317-d703ef7c1de1@gmail.com> (raw) In-Reply-To: <ZfhxUJjrcYfqt9Nd@p14s> On 3/18/24 18:52, Mathieu Poirier wrote: > Hi Leonard, > > I have queued patches for this driver that will break this patch. Please > re-submit when v6.9-rc1 is out and rproc-next has been updated, which should be > around the middle of next week. Hello, It's been a while - v6.9-rc1 is out and rproc-next has been rebased on top of it. But the coredump patch still applies? I expected some unrelated xlnx_r5_remoteproc patches to cause conflicts but there's nothing there. It seems to me that the patch can be applied as-is and no resend is required. Am I missing something? -- Regards, Leonard > On Sat, Mar 16, 2024 at 08:16:42PM +0200, Leonard Crestez wrote: >> Supporting remoteproc coredump requires the platform-specific driver to >> register coredump segments to be dumped. Do this by calling >> rproc_coredump_add_segment for every carveout. >> >> Also call rproc_coredump_set_elf_info when then rproc is created. If the >> ELFCLASS parameter is not provided then coredump fails with an error. >> Other drivers seem to pass EM_NONE for the machine argument but for me >> this shows a warning in gdb. Pass EM_ARM because this is an ARM R5. >> >> Signed-off-by: Leonard Crestez <cdleonard@gmail.com> >> --- >> >> Tests were done by triggering an deliberate crash using remoteproc >> debugfs: echo 2 > /sys/kernel/debug/remoteproc/remoteproc0/crash >> >> This was tested using RPU apps which use RAM for everything so TCM dump >> was not verified. The freertos-gdb script package showed credible data: >> >> https://github.com/espressif/freertos-gdb >> >> The R5 cache is not flushed so RAM might be out of date which is >> actually very bad because information most relevant to determining the >> cause of a crash is lost. Possible workaround would be to flush caches >> in some sort of R5 crash handler? I don't think Linux can do anything >> about this limitation. >> >> The generated coredump doesn't contain registers, this seems to be a >> limitation shared with other rproc coredumps. It's not clear how the apu >> could access rpu registers on zynqmp, my only idea would be to use the >> coresight dap but that sounds difficult.
next prev parent reply other threads:[~2024-03-28 8:17 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-16 18:16 [PATCH] remoteproc: zynqmp: Add coredump support Leonard Crestez 2024-03-16 18:16 ` Leonard Crestez 2024-03-18 16:52 ` Mathieu Poirier 2024-03-18 16:52 ` Mathieu Poirier 2024-03-28 8:17 ` Leonard Crestez [this message] 2024-03-28 8:17 ` Leonard Crestez 2024-03-28 14:53 ` Mathieu Poirier 2024-03-28 14:53 ` Mathieu Poirier 2024-04-04 20:14 ` Tanmay Shah 2024-04-04 20:14 ` Tanmay Shah 2024-04-06 18:28 ` Leonard Crestez 2024-04-06 18:28 ` Leonard Crestez 2024-04-08 16:57 ` Mathieu Poirier 2024-04-08 16:57 ` Mathieu Poirier
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=07183fd8-a5a1-4cae-b317-d703ef7c1de1@gmail.com \ --to=cdleonard@gmail.com \ --cc=andersson@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=mathieu.poirier@linaro.org \ --cc=michal.simek@amd.com \ --cc=tanmay.shah@amd.com \ /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: linkBe 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.