- Openamp-rp - lists.openampproject.org

Re: [PATCH v2 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver

by Shenwei Wang

Hi Arnaud, > -----Original Message----- > From: Arnaud POULIQUEN <arnaud.pouliquen(a)foss.st.com> > Sent: Friday, October 3, 2025 2:40 AM > To: Shenwei Wang <shenwei.wang(a)nxp.com>; Bjorn Andersson > <andersson(a)kernel.org>; Mathieu Poirier <mathieu.poirier(a)linaro.org>; Rob > Herring <robh(a)kernel.org>; Krzysztof Kozlowski <krzk+dt(a)kernel.org>; Conor > Dooley <conor+dt(a)kernel.org>; Shawn Guo <shawnguo(a)kernel.org>; Sascha > Hauer <s.hauer(a)pengutronix.de>; Linus Walleij <linus.walleij(a)linaro.org>; > Bartosz Golaszewski <brgl(a)bgdev.pl> > Cc: Pengutronix Kernel Team <kernel(a)pengutronix.de>; Fabio Estevam > <festevam(a)gmail.com>; Peng Fan <peng.fan(a)nxp.com>; linux- > remoteproc(a)vger.kernel.org; devicetree(a)vger.kernel.org; imx(a)lists.linux.dev; > > These processors communicate via the RPMSG protocol. > > The driver implements the standard GPIO interface, allowing the Linux > > side to control GPIO controllers which reside in the remote processor > > via RPMSG protocol. > > What about my request in previous version to make this driver generic? > The only platform-dependent part of this driver is the layout of the message packet, which defines the communication protocol between the host and the remote processor. It would be challenging to require other vendors to follow our protocol and conform to the expected behavior. > In ST we have similar driver in downstream, we would be interested in reusing it if > generic. Indeed we need some rpmsg mechanism for gpio-interrupt. Today we > have a downstream rpmsg driver [1][2] that could migrate on a generic rpmsg- > gpio driver. > > > + > > +#include <linux/err.h> > > +#include <linux/gpio/driver.h> > > +#include <linux/rpmsg/imx_rpmsg.h> > > +#include <linux/init.h> > > +#include <linux/irqdomain.h> > > +#include <linux/of.h> > > +#include <linux/platform_device.h> > > +#include <linux/rpmsg.h> > > + > > +#define IMX_RPMSG_GPIO_PER_PORT 32 > > +#define RPMSG_TIMEOUT 1000 > > + > > +enum gpio_input_trigger_type { > > + GPIO_RPMSG_TRI_IGNORE, > > + GPIO_RPMSG_TRI_RISING, > > + GPIO_RPMSG_TRI_FALLING, > > + GPIO_RPMSG_TRI_BOTH_EDGE, > > + GPIO_RPMSG_TRI_LOW_LEVEL, > > + GPIO_RPMSG_TRI_HIGH_LEVEL, > > +}; > What about taking inspiration from the|IRQ_TYPE|bitfield defined in|irq.h|? > For instance: > GPIO_RPMSG_TRI_BOTH_EDGE = GPIO_RPMSG_TRI_FALLING | > GPIO_RPMSG_TRI_RISING, Yes, the suggestion is better. > > + > > +enum gpio_rpmsg_header_type { > > + GPIO_RPMSG_SETUP, > > + GPIO_RPMSG_REPLY, > > + GPIO_RPMSG_NOTIFY, > > +}; > > + > > +enum gpio_rpmsg_header_cmd { > > + GPIO_RPMSG_INPUT_INIT, > > + GPIO_RPMSG_OUTPUT_INIT, > > + GPIO_RPMSG_INPUT_GET, > > +}; > > + > > +struct gpio_rpmsg_data { > > + struct imx_rpmsg_head header; > > + u8 pin_idx; > > + u8 port_idx; > > + union { > > + u8 event; > > + u8 retcode; > > + u8 value; > > + } out; > > + union { > > + u8 wakeup; > > + u8 value; > nitpicking put "value" field out of union as common I'm afraid we can't make it common, as the two 'value' fields serve different purposes-one is used for outgoing messages and the other for incoming messages-and they are located in different parts of the packet. > > + } in; > > +} __packed __aligned(8); > > Any reason to pack it an align it? > This structure will be copied in the RPMSg payload, right? > Yes. The message will then be transmitted via the MU hardware to the remote processor, so proper alignment is required. > I also wonder if that definition should not be in a header file with double licensing > that the DT. Indeed this need to be common with the remote side > implementation that can be non GPL implementation. > > > + > > +struct imx_rpmsg_gpio_pin { > > + u8 irq_shutdown; > > + u8 irq_unmask; > > + u8 irq_mask; > > + u32 irq_wake_enable; > > + u32 irq_type; > > + struct gpio_rpmsg_data msg; > > +}; > > + > > +struct imx_gpio_rpmsg_info { > > + struct rpmsg_device *rpdev; > > + struct gpio_rpmsg_data *notify_msg; > > + struct gpio_rpmsg_data *reply_msg; > > + struct completion cmd_complete; > > + struct mutex lock; > > + msg->pin_idx = gpio; > > + msg->port_idx = port->idx; > > + > > + ret = gpio_send_message(port, msg, true); > > + if (!ret) > > + ret = !!port->gpio_pins[gpio].msg.in.value; > Does this code is save? !! return a boolean right? > why not force to 1 if greater that 1? > This approach is intended to simplify the implementation. Forcing to 1 would introduce an additional condition check. I'm open to changing it if that's considered standard practice. > > + > > + return ret; > > +} > > + > > +static int imx_rpmsg_gpio_direction_input(struct gpio_chip *gc, > > + unsigned int gpio) { > > + struct imx_rpmsg_gpio_port *port = gpiochip_get_data(gc); > > + struct gpio_rpmsg_data *msg = NULL; > > + > > + guard(mutex)(&port->info.lock); > > + > > + msg = gpio_get_pin_msg(port, gpio); > > + msg->header.cate = IMX_RPMSG_GPIO; > Do you use a single rpmsg channel for several feature? > Any reason to not use one rpmsg channel per feature category? > The current implementation on the remote side uses a single channel to handle all GPIO controllers. However, this driver itself does not have that limitation. > > + msg->header.major = IMX_RMPSG_MAJOR; > > + msg->header.minor = IMX_RMPSG_MINOR; > > + msg->header.type = GPIO_RPMSG_SETUP; > > + msg->header.cmd = GPIO_RPMSG_INPUT_INIT; > > + msg->pin_idx = gpio; > > + msg->port_idx = port->idx; > > + > > + msg->out.event = GPIO_RPMSG_TRI_IGNORE; > > + msg->in.wakeup = 0; > > + > > + return gpio_send_message(port, msg, true); } > > + > > +static inline void imx_rpmsg_gpio_direction_output_init(struct gpio_chip *gc, > > + unsigned int gpio, int val, struct gpio_rpmsg_data *msg) > > + > > +static struct platform_driver imx_rpmsg_gpio_driver = { > > + .driver = { > > + .name = "gpio-imx-rpmsg", > > + .of_match_table = imx_rpmsg_gpio_dt_ids, > > + }, > > + .probe = imx_rpmsg_gpio_probe, > > +}; > > + > > +module_platform_driver(imx_rpmsg_gpio_driver); > This implementation seems strange to me. > You have a platform driver, but your RPMsg driver appears split between this > driver and the remoteproc driver, especially regarding the > imx_rpmsg_endpoint_probe() function. > See my reply below. > From my point of view, this driver should declare both a platform_driver and an > rpmsg_driver structures. > > Your imx_rpmsg_gpio_driver platform driver should be probed by your > remoteproc platform. > This platform driver would be responsible for: > - Parsing the device tree node > - Registering the RPMsg driver > > Then, the RPMsg device should be probed either by the remote processor using > the name service announcement mechanism or if not possible by your > remoteproc driver. > The idea is to probe the GPIO driver successfully only after the remote processor is online and has sent the name service announcement. Until then, the GPIO driver will remain in a deferred state, ensuring that all consumers of the associated GPIOs are also deferred. The implementation you provided below does not guarantee that the related consumers will be properly deferred. This is the most important behavior for a GPIO/I2C controllers. Thanks, Shenwei > To better understand my proposal you can have a look to [1]and [2]. > Here is another example for an rpmsg_i2c( ST downstream implementation): > https://github.co/ > m%2FSTMicroelectronics%2Flinux%2Fblob%2Fv6.6- > stm32mp%2Fdrivers%2Fi2c%2Fbusses%2Fi2c- > rpmsg.c&data=05%7C02%7Cshenwei.wang%40nxp.com%7C22a9c88be60b474e > 391008de02502ec7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63 > 8950740622597592%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=6lCk20Qhb%2F0MTw0NFtto7tj7EFYwZ%2BlOR1F3 > Qk7kQn8%3D&reserved=0 > https://github.co/ > m%2FSTMicroelectronics%2Flinux%2Fblob%2Fv6.6- > stm32mp%2FDocumentation%2Fdevicetree%2Fbindings%2Fi2c%2Fi2c- > rpmsg.yaml&data=05%7C02%7Cshenwei.wang%40nxp.com%7C22a9c88be60b4 > 74e391008de02502ec7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7 > C638950740622612512%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=4Gva%2FpqP2u8T57XDxSDaoHhvDeJ%2Fo5HtAB > L9TY5gbDI%3D&reserved=0 > > Thanks and Regards, > Arnaud > > > + > > +MODULE_AUTHOR("NXP Semiconductor"); > > +MODULE_DESCRIPTION("NXP i.MX SoC rpmsg gpio driver"); > > +MODULE_LICENSE("GPL");

2 months, 1 week

1
0
0 0

Linux upstream work on RPMSG GPIO driver

by Chan King Choy, Nathalie

[Public] Hi members of openamp-rp list, Relaying a message from Linus W. that was submitted as a GitHub issue to the OpenAMP website. (for future reference, https://github.com/OpenAMP/open-amp is where the folks interested in RPMSG are) === I don't see any other way to communicate with the OpenAMP project than to file an issue here. There is an RPMSG-based GPIO driver submitted to the Linux kernel: https://lore.kernel.org/linux-remoteproc/20250922200413.309707-1-shenwei.wa… Please participate in the discussion if you are interested. BR Linus Walleij === With the message relayed, I will close the GitHub issue that is filed against the website. Best regards, Nathalie Chan King Choy Open Source Program Manager [Public] Hi members of openamp-rp list, Relaying a message from Linus W. that was submitted as a GitHub issue to the OpenAMP website. (for future reference, [1]https://github.com/OpenAMP/open-amp is where the folks interested in RPMSG are) === I don't see any other way to communicate with the OpenAMP project than to file an issue here. There is an RPMSG-based GPIO driver submitted to the Linux kernel: [2]https://lore.kernel.org/linux-remoteproc/20250922200413.309707-1-she nwei.wang(a)nxp.com/ Please participate in the discussion if you are interested. BR Linus Walleij === With the message relayed, I will close the GitHub issue that is filed against the website. Best regards, Nathalie Chan King Choy Open Source Program Manager References 1. https://github.com/OpenAMP/open-amp 2. https://lore.kernel.org/linux-remoteproc/20250922200413.309707-1-shenwei.wa…

2 months, 2 weeks

1
0
0 0

Re: Openamp-rp Digest, Vol 72, Issue 1

by Maarten Koning

leave On Wed, Sep 24, 2025 at 8:00 PM <openamp-rp-request(a)lists.openampproject.org> wrote: > Send Openamp-rp mailing list submissions to > openamp-rp(a)lists.openampproject.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > openamp-rp-request(a)lists.openampproject.org > > You can reach the person managing the list at > openamp-rp-owner(a)lists.openampproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openamp-rp digest..."Today's Topics: > > 1. [OpenAMP/open-amp] ad39b4: README: remove example related information > (Tanmay) > > > > ---------- Forwarded message ---------- > From: Tanmay <noreply(a)github.com> > To: openamp-rp(a)lists.openampproject.org > Cc: > Bcc: > Date: Wed, 24 Sep 2025 09:44:35 -0700 > Subject: [Openamp-rp] [OpenAMP/open-amp] ad39b4: README: remove example > related information > Branch: refs/heads/main > Home: https://github.com/OpenAMP/open-amp > Commit: ad39b4e740717cc8204e7e655e365b816334422b > > https://github.com/OpenAMP/open-amp/commit/ad39b4e740717cc8204e7e655e365b81… > Author: Tanmay Shah <tanmay.shah(a)amd.com> > Date: 2025-09-24 (Wed, 24 Sep 2025) > > Changed paths: > M README.md > > Log Message: > ----------- > README: remove example related information > > Update README file with latest information about demos and its > documentation. > > Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> > > > > To unsubscribe from these emails, change your notification settings at > https://github.com/OpenAMP/open-amp/settings/notifications > Openamp-rp mailing list -- openamp-rp(a)lists.openampproject.org > To unsubscribe send an email to openamp-rp-leave(a)lists.openampproject.org > leave On Wed, Sep 24, 2025 at 8:00 PM <[1]openamp-rp-request(a)lists.openampproject.org> wrote: Send Openamp-rp mailing list submissions to [2]openamp-rp(a)lists.openampproject.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to [3]openamp-rp-request(a)lists.openampproject.org You can reach the person managing the list at [4]openamp-rp-owner(a)lists.openampproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Openamp-rp digest..."Today's Topics: 1. [OpenAMP/open-amp] ad39b4: README: remove example related information (Tanmay) ---------- Forwarded message ---------- From: Tanmay <[5]noreply(a)github.com> To: [6]openamp-rp(a)lists.openampproject.org Cc: Bcc: Date: Wed, 24 Sep 2025 09:44:35 -0700 Subject: [Openamp-rp] [OpenAMP/open-amp] ad39b4: README: remove example related information Branch: refs/heads/main Home: [7]https://github.com/OpenAMP/open-amp Commit: ad39b4e740717cc8204e7e655e365b816334422b [8]https://github.com/OpenAMP/open-amp/commit/ad39b4e740717cc8204e7e 655e365b816334422b Author: Tanmay Shah <[9]tanmay.shah(a)amd.com> Date: 2025-09-24 (Wed, 24 Sep 2025) Changed paths: M README.md Log Message: ----------- README: remove example related information Update README file with latest information about demos and its documentation. Signed-off-by: Tanmay Shah <[10]tanmay.shah(a)amd.com> To unsubscribe from these emails, change your notification settings at [11]https://github.com/OpenAMP/open-amp/settings/notifications Openamp-rp mailing list -- [12]openamp-rp(a)lists.openampproject.org To unsubscribe send an email to [13]openamp-rp-leave(a)lists.openampproject.org References 1. mailto:openamp-rp-request@lists.openampproject.org 2. mailto:openamp-rp@lists.openampproject.org 3. mailto:openamp-rp-request@lists.openampproject.org 4. mailto:openamp-rp-owner@lists.openampproject.org 5. mailto:noreply@github.com 6. mailto:openamp-rp@lists.openampproject.org 7. https://github.com/OpenAMP/open-amp 8. https://github.com/OpenAMP/open-amp/commit/ad39b4e740717cc8204e7e655e365b81… 9. mailto:tanmay.shah@amd.com 10. mailto:tanmay.shah@amd.com 11. https://github.com/OpenAMP/open-amp/settings/notifications 12. mailto:openamp-rp@lists.openampproject.org 13. mailto:openamp-rp-leave@lists.openampproject.org

2 months, 2 weeks

2
1
0 0

[OpenAMP/open-amp] ad39b4: README: remove example related information

by Tanmay

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: ad39b4e740717cc8204e7e655e365b816334422b https://github.com/OpenAMP/open-amp/commit/ad39b4e740717cc8204e7e655e365b81… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-09-24 (Wed, 24 Sep 2025) Changed paths: M README.md Log Message: ----------- README: remove example related information Update README file with latest information about demos and its documentation. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/open-amp/settings/notifications

2 months, 3 weeks

1
0
0 0

OpenAMP release 2025.10: code freeze on October 18th

by Arnaud POULIQUEN

Hello, The v2025.10 release of the OpenAMP project repositories is scheduled for the end of next month. Please note that the feature freeze will take effect on October 18th. After this date, only bug fixes will be accepted until the release. To ensure sufficient time for the review process, please submit your pull requests at least two weeks before the feature freeze date. Thanks and regards, Arnaud Pouliquen

2 months, 3 weeks

1
0
0 0

[OpenAMP/openamp-system-reference] 575135: west: Update to Zephyr 4.2

by Iulia Prodan

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: 5751358ac27d07ff44e5f233161a59ce8bb4afca https://github.com/OpenAMP/openamp-system-reference/commit/5751358ac27d07ff… Author: Iuliana Prodan <iuliana.prodan(a)nxp.com> Date: 2025-08-25 (Mon, 25 Aug 2025) Changed paths: M west.yml Log Message: ----------- west: Update to Zephyr 4.2 Update to latest Zephyr release, 4.2. Signed-off-by: Iuliana Prodan <iuliana.prodan(a)nxp.com> Commit: daa61d6096e268ea6393532cd15494163ba0f927 https://github.com/OpenAMP/openamp-system-reference/commit/daa61d6096e268ea… Author: Iuliana Prodan <iuliana.prodan(a)nxp.com> Date: 2025-08-25 (Mon, 25 Aug 2025) Changed paths: A examples/zephyr/rpmsg_multi_services/boards/imx95_evk_mimx9596_m7.conf A examples/zephyr/rpmsg_multi_services/boards/imx95_evk_mimx9596_m7.overlay Log Message: ----------- examples: add support for i.MX95 M7 core in rpmsg_multi_services Add the dts and config overlay for imx95_evk_mimx9596_m7 board in order to have the rpmsg_multi_services sample working on ARM Cortex-M7 core from i.MX95. Signed-off-by: Iuliana Prodan <iuliana.prodan(a)nxp.com> Commit: 1922b2a4230f381cf94cc4e298fc53644db6d87d https://github.com/OpenAMP/openamp-system-reference/commit/1922b2a4230f381c… Author: Iuliana Prodan <iuliana.prodan(a)nxp.com> Date: 2025-08-25 (Mon, 25 Aug 2025) Changed paths: M examples/zephyr/rpmsg_multi_services/README.rst Log Message: ----------- examples: Zephyr: update rpmsg-multi-service readme Update README file to include NXP i.MX95 M7 board support. Signed-off-by: Iuliana Prodan <iuliana.prodan(a)nxp.com> Commit: 1a11089bf356e2aec4b657051b5c0d38fa437573 https://github.com/OpenAMP/openamp-system-reference/commit/1a11089bf356e2ae… Author: Iuliana Prodan <iuliana.prodan(a)nxp.com> Date: 2025-08-25 (Mon, 25 Aug 2025) Changed paths: M examples/zephyr/rpmsg_multi_services/src/main_remote.c Log Message: ----------- examples: zephyr: replace struct fw_resource_table with void This fixes the following warning: passing argument 1 of 'rsc_table_get' from incompatible pointer type. Signed-off-by: Iuliana Prodan <iuliana.prodan(a)nxp.com> Compare: https://github.com/OpenAMP/openamp-system-reference/compare/cc353a29db02...… To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

3 months, 3 weeks

1
0
0 0

[OpenAMP/openamp-system-reference] cc353a: legacy_apps: zynqmp_r5: Fix compilation issues for...

by ben

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: cc353a29db02a96376ed5e1b57a06f8c30bde988 https://github.com/OpenAMP/openamp-system-reference/commit/cc353a29db02a963… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-08-25 (Mon, 25 Aug 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt M examples/legacy_apps/machine/zynqmp_r5/generic/gic_init.c M examples/legacy_apps/machine/zynqmp_r5/helper.c M examples/legacy_apps/machine/zynqmp_r5/linker_large_text.ld M examples/legacy_apps/machine/zynqmp_r5/linker_remote.ld M examples/legacy_apps/machine/zynqmp_r5/platform_info.c M examples/legacy_apps/machine/zynqmp_r5/platform_info.h M examples/legacy_apps/machine/zynqmp_r5/rsc_table.c M examples/legacy_apps/machine/zynqmp_r5/rsc_table.h M examples/legacy_apps/machine/zynqmp_r5/zynqmp_r5_a53_rproc.c M examples/legacy_apps/system/freertos/suspend.c M examples/legacy_apps/system/generic/CMakeLists.txt R examples/legacy_apps/system/generic/machine/CMakeLists.txt R examples/legacy_apps/system/generic/machine/microblaze_generic/CMakeLists.txt R examples/legacy_apps/system/generic/machine/microblaze_generic/helper.c R examples/legacy_apps/system/generic/machine/microblaze_generic/linker_remote.ld R examples/legacy_apps/system/generic/machine/zynqmp_r5/CMakeLists.txt M examples/legacy_apps/system/generic/suspend.c Log Message: ----------- legacy_apps: zynqmp_r5: Fix compilation issues for baremetal and RPU target apps Fix linker scripts, C files and Cmake to ensure upstream works with latest BSP. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

3 months, 3 weeks

1
0
0 0

[OpenAMP/open-amp] 98ba93: doc: copy design document images from open-amp rep...

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 98ba93cfabf0a5398e2671b230f94c7cb8b3bef7 https://github.com/OpenAMP/open-amp/commit/98ba93cfabf0a5398e2671b230f94c7c… Author: Sipke Vriend <sipke(a)direktembedded.com> Date: 2025-08-25 (Mon, 25 Aug 2025) Changed paths: R doc/data-structure.md R doc/img-src/coprocessor-rpmsg-ns-dynamic.gv R doc/img-src/coprocessor-rpmsg-ns.gv R doc/img-src/coprocessor-rpmsg-static-ep.gv R doc/img-src/gen-graph.py R doc/img-src/rproc-lcm-state-machine.gv R doc/img/coprocessor-rpmsg-ns-dynamic.png R doc/img/coprocessor-rpmsg-ns.png R doc/img/coprocessor-rpmsg-static-ep.png R doc/img/rproc-lcm-state-machine.png R doc/remoteproc-design.md R doc/rpmsg-design.md Log Message: ----------- doc: copy design document images from open-amp repository These design documents and images are being moved to openamp-docs Decided with Bill and Arnaud to move all the design documentation from the https://github.com/OpenAMP/open-amp repository doc folder to the https://github.com/OpenAMP/openamp-docs repository docs folder The main reason being that the breathe and doxylink integration is already in openamp-docs, so can be used for the design doc. Signed-off-by: Sipke Vriend <sipke(a)direktembedded.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/open-amp/settings/notifications

3 months, 3 weeks

1
0
0 0

[OpenAMP/openamp-system-reference] 7863e7: examples: legacy_apps: Fix add default routines fo...

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: 7863e739985bb64da2ba391978ef02fcc89954ec https://github.com/OpenAMP/openamp-system-reference/commit/7863e739985bb64d… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2025-08-01 (Fri, 01 Aug 2025) Changed paths: M examples/legacy_apps/system/linux/machine/generic/platform_info.c Log Message: ----------- examples: legacy_apps: Fix add default routines for suspend/resume Fix following build warning introduced by: 89f56feaec6d ("examples: legacy_apps: Add default routines for suspend/resume") system/linux/machine/generic/platform_info.c:546:3: warning: implicit declaration of function ‘system_suspend’ [-Wimplicit-function-declaration] 546 | system_suspend(); | ^~~~~~~~~~~~~~ Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

4 months, 2 weeks

1
0
0 0

[OpenAMP/libmetal] 16493b: lib: system: remove xlnx BSP specific code

by Tanmay

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: 16493b179fb480e6ff5d9378cf24b8b78859fd7f https://github.com/OpenAMP/libmetal/commit/16493b179fb480e6ff5d9378cf24b8b7… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-07-29 (Tue, 29 Jul 2025) Changed paths: M lib/system/freertos/sys.h R lib/system/freertos/template/CMakeLists.txt R lib/system/freertos/template/sys.c R lib/system/freertos/template/sys.h R lib/system/freertos/xlnx/CMakeLists.txt R lib/system/freertos/xlnx/irq.c R lib/system/freertos/xlnx/sys.c R lib/system/freertos/xlnx/sys.h M lib/system/generic/sys.h R lib/system/generic/template/CMakeLists.txt R lib/system/generic/template/sys.c R lib/system/generic/template/sys.h R lib/system/generic/xlnx/CMakeLists.txt R lib/system/generic/xlnx/irq.c R lib/system/generic/xlnx/microblaze_generic/CMakeLists.txt R lib/system/generic/xlnx/microblaze_generic/sys.c R lib/system/generic/xlnx/sys.c R lib/system/generic/xlnx/sys.h R lib/system/generic/xlnx/sys_devicetree.h Log Message: ----------- lib: system: remove xlnx BSP specific code libmetal is abstraction layer and vendor specific code should not be maintained as part of libmetal. Instead common interfaces provided by libmetal should be implemented by vendor BSP in downstream repos. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

4 months, 2 weeks

1
0
0 0

[OpenAMP/openamp-system-reference] 75c158: legacy_apps: zynqmp_r5: restore initial resources

by Tanmay

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: 75c158b008d6d758c39870814dbf8a92cc084867 https://github.com/OpenAMP/openamp-system-reference/commit/75c158b008d6d758… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-07-23 (Wed, 23 Jul 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/helper.c M examples/legacy_apps/machine/zynqmp_r5/platform_info.c M examples/legacy_apps/machine/zynqmp_r5/rsc_table.c M examples/legacy_apps/machine/zynqmp_r5/rsc_table.h Log Message: ----------- legacy_apps: zynqmp_r5: restore initial resources Resource table can get corrupted during un-controlled reboot of host. This can cause crash when attach happens after reboot. Restore initial good version of resource table before re-creating virtio devices. As part of this, first the server takes the resource table snapshot to before any IPC events are in place to prevent this issue during system-init. Secondly helper.c will call get_resource_table so that the future call to restore_initial_rsc_table will have the resource set up. Otherwise the snapshot can still fail if the resource is not set up. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: 29232c244a8ef3136205031f891c361fdfb44472 https://github.com/OpenAMP/openamp-system-reference/commit/29232c244a8ef313… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-07-23 (Wed, 23 Jul 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/linker_large_text.ld M examples/legacy_apps/machine/zynqmp_r5/linker_remote.ld M examples/legacy_apps/machine/zynqmp_r5/rsc_table.c M examples/legacy_apps/machine/zynqmp_r5/rsc_table.h Log Message: ----------- legacy_apps: zynqmp_r5: add rsc table metadata section During attach detach operation, resource table needs to be retrieved by host. In such case firmware is expected to provided metadata by host. This metadata is expected by firmware at the start address of shared memory beteween host and remote. Add padding to ensure no section overlap. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Compare: https://github.com/OpenAMP/openamp-system-reference/compare/49d74fec0b50...… To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

4 months, 3 weeks

1
0
0 0

[OpenAMP/libmetal] a19cfb: lib: system: linux: Remove redundant malloc'd addr...

by Huichun Feng

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: a19cfb3ff3b23dd84043c660748f7892abe6029d https://github.com/OpenAMP/libmetal/commit/a19cfb3ff3b23dd84043c660748f7892… Author: Huichun Feng <foxhoundsk.tw(a)gmail.com> Date: 2025-07-15 (Tue, 15 Jul 2025) Changed paths: M lib/system/linux/device.c Log Message: ----------- lib: system: linux: Remove redundant malloc'd addr release check As the code path suggests, the pointer, ldev, at this point, can be free'd directly w/o a check. Remove the redundant check. Signed-off-by: Huichun Feng <foxhoundsk.tw(a)gmail.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

5 months

1
0
0 0

[OpenAMP/libmetal] fdc85e: lib: system: linux: Remove redundant memory validn...

by Huichun Feng

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: fdc85ec742a03dc401167df4bffa49cae6ec8db5 https://github.com/OpenAMP/libmetal/commit/fdc85ec742a03dc401167df4bffa49ca… Author: Fox Feng <foxhoundsk.tw(a)gmail.com> Date: 2025-07-15 (Tue, 15 Jul 2025) Changed paths: M lib/system/linux/device.c Log Message: ----------- lib: system: linux: Remove redundant memory validness check In the function prologue, "ldev" has already been assigned a malloc'd address, and a check has also been performed. Remove this redundant pointer validness check during each iteration. The second check was also inherently misplaced because the it was not enclosed in the malloc if-branch. Signed-off-by: Fox Feng <foxhoundsk.tw(a)gmail.com> Signed-off-by: Huichun Feng <foxhoundsk.tw(a)gmail.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

5 months

1
0
0 0

Re: Testing on attach-detach recovery

by Tanmay Shah

On 7/3/25 2:49 AM, Arnaud POULIQUEN wrote: > > > On 7/2/25 19:00, Tanmay Shah wrote: >> >> >> On 7/2/25 10:47 AM, Arnaud POULIQUEN wrote: >>> >>> >>> On 7/2/25 17:23, Tanmay Shah wrote: >>>> >>>> >>>> On 7/2/25 2:18 AM, Arnaud POULIQUEN wrote: >>>>> >>>>> >>>>> On 7/1/25 23:19, Tanmay Shah wrote: >>>>>> >>>>>> >>>>>> On 7/1/25 1:06 PM, Tanmay Shah wrote: >>>>>>> >>>>>>> >>>>>>> On 7/1/25 12:56 PM, Tanmay Shah wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 7/1/25 12:18 PM, Arnaud POULIQUEN wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/1/25 17:16, Tanmay Shah wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/1/25 3:07 AM, Arnaud POULIQUEN wrote: >>>>>>>>>>> Hi Tanmay, >>>>>>>>>>> >>>>>>>>>>> On 6/27/25 23:29, Tanmay Shah wrote: >>>>>>>>>>>> Hello all, >>>>>>>>>>>> >>>>>>>>>>>> I am implementing remoteproc recovery on attach-detach use case. >>>>>>>>>>>> I have implemented the feature in the platform driver, and it works for >>>>>>>>>>>> boot >>>>>>>>>>>> recovery. >>>>>>>>>>> >>>>>>>>>>> Few questions to better understand your use case. >>>>>>>>>>> >>>>>>>>>>> 1) The linux remoteproc firmware attach to a a remote processor, and you >>>>>>>>>>> generate a crash of the remote processor, right? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes correct. >>>>>>>>>> >>>>>>>>>>> 1) How does the remoteprocessor reboot? On a remoteproc request or it >>>>>>>>>>> is an >>>>>>>>>>> autoreboot independent from the Linux core? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It is auto-reboot independent from the linux core. >>>>>>>>>> >>>>>>>>>>> 2) In case of auto reboot, when does the remoteprocessor send an even to >>>>>>>>>>> the >>>>>>>>>>> Linux remoteproc driver ? beforeor after the reset? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Right now, when Remote reboots, it sends crash event to remoteproc driver >>>>>>>>>> after >>>>>>>>>> reboot. >>>>>>>>>> >>>>>>>>>>> 3) Do you expect to get core dump on crash? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No coredump expected as of now, but only recovery. Eventually will >>>>>>>>>> implement >>>>>>>>>> coredump functionality as well. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> However, I am stuck at the testing phase. >>>>>>>>>>>> >>>>>>>>>>>> When should firmware report the crash ? After reboot ? or during some >>>>>>>>>>>> kind of >>>>>>>>>>>> crash handler ? >>>>>>>>>>>> >>>>>>>>>>>> So far, I am reporting crash after rebooting remote processor, but it >>>>>>>>>>>> doesn't >>>>>>>>>>>> seem to work i.e. I don't see rpmsg devices created after recovery.> >>>>>>>>>>>> What should be the correct process to test this feature ? How other >>>>>>>>>>>> platforms >>>>>>>>>>>> are testing this? >>>>>>>>>>> >>>>>>>>>>> I have never tested it on ST board. As a first analysis, in case of >>>>>>>>>>> autoreboot >>>>>>>>>>> of the remote processor, it look like you should detach and reattach to >>>>>>>>>>> recover. >>>>>>>>>> >>>>>>>>>> That is what's done from the remoteproc framework. >>>>>>>>>> >>>>>>>>>>> - On detach the rpmsg devices should be unbind >>>>>>>>>>> - On attach the remote processor should request RPmsg channels using >>>>>>>>>>> the NS >>>>>>>>>>> announcement mechanism >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Main issue is, Remote firmware needs to wait till all above happens. Then >>>>>>>>>> only >>>>>>>>>> initialize virtio devices. Currently we don't have any way to notify >>>>>>>>>> recovery >>>>>>>>>> progress from linux to remote fw in the remoteproc framework. So I might >>>>>>>>>> have to >>>>>>>>>> introduce some platform specific mechanism in remote firmware to wait for >>>>>>>>>> recovery to complete successfully. >>>>>>>>> >>>>>>>>> I guess the rproc->clean_table contains a copy of the resource table >>>>>>>>> that is >>>>>>>>> reapplied on attach, and the virtio devices should be re-probed, right? >>>>>>>>> >>>>>>>>> During the virtio device probe, the vdev status in the resource table is >>>>>>>>> updated >>>>>>>>> to 7 when virtio is ready to communicate. Virtio should then call >>>>>>>>> rproc_virtio_notify() to inform the remote processor of the status update. >>>>>>>>> At this stage, your remoteproc driver should be able to send a mailbox >>>>>>>>> message >>>>>>>>> to inform the remote side about the recovery completion. >>>>>>>>> >>>>>>>> >>>>>>>> I think I spot the problem now. >>>>>>>> >>>>>>>> Linux side: file: remoteproc_core.c >>>>>>>> rproc_attach_recovery >>>>>>>> __rproc_detach >>>>>>>> cleans up the resource table and re-loads it >>>>>>>> __rproc_attach >>>>>>>> stops and re-starts subdevices >>>>>>>> >>>>>>>> >>>>>>>> Remote side: >>>>>>>> Remote re-boots after crash >>>>>>>> Detects crash happened previously >>>>>>>> notify crash to Linux >>>>>>>> (Linux is executing above flow meanwhile) >>>>>>>> starts creating virtio devices >>>>>>>> **rproc_virtio_create_vdev - parse vring & create vdev device** >>>>>>>> **rproc_virtio_wait_remote_ready - wait for remote ready** [1] >>>>>>>> >>>>>>>> I think Remote should wait on DRIVER_OK bit, before creating virtio devices. >>>>>>>> The temporary solution I implemented was to make sure vrings addresses are >>>>>>>> not 0xffffffff like following: >>>>>>>> >>>>>>>> while(rsc->rpmsg_vring0.da == FW_RSC_U32_ADDR_ANY || >>>>>>>> rsc->rpmsg_vring1.da == FW_RSC_U32_ADDR_ANY) { >>>>>>>> usleep(100); >>>>>>>> metal_cache_invalidate(rsc, rproc->rsc_len); >>>>>>>> } >>>>>>>> >>>>>>>> Above works, but I think better solution is to change sequence where remote >>>>>>>> waits before creating virtio devices. >>>>>>> >>>>>>> I am sorry, I should have said, remote should wait before parsing and >>>>>>> assigning vrings to virtio device. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] https://github.com/OpenAMP/open-amp/ >>>>>>>> blob/391671ba24840833d882c1a75c5d7307703b1cf1/lib/remoteproc/ >>>>>>>> remoteproc.c#L994 >>>>>>>> >>>>>> >>>>>> Actually upon further checking, I think above code is okay. I see that >>>>>> wait_remote_ready is called before vrings are setup on remote fw side. >>>>>> >>>>>> However, during recovery time on remote side, somehow I still have to >>>>>> implement >>>>>> platform specific wait for vrings to setup correctly. >>>>>> >>>>>> From linux side, DRIVER_OK bit is set before vrings are setup correctly. >>>>>> Because of that, when remote firmware sets up wrong vring addresses and then >>>>>> rpmsg channels are not created. >>>>>> >>>>>> I am investigating on this further. >>>>> >>>>> Do you reset the vdev status as requested by the virtio spec? >>>>> https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html… >>>>> >>>>> Regards, >>>>> Arnaud >>>>> >>>> >>>> Yes I do. I am actually restoring deafult resource table on firmware side, which >>>> will set rpmsg_vdev status to 0. >>>> >>>> However, when printing vrings right before wait_remote_ready, I see vrings are >>>> not set correctly from linux side: >>>> >>>> `vring0 = 0xFFFFFFFF, vring1 = 0xFFFFFFFF` >>> >>> That makes sense if values corresponds to the initial values of the resource >>> table >>> rproc->clean_table should contain a copy of these initial values. >>> >>>> >>>> However, the rproc state was still moved to attach when checked from remoteproc >>>> sysfs. >>> >>> Does the rproc_handle_resources() is called before going back in attached state? >> >> You are right. I think __rproc_attach() isn't calling rproc_handle_resources(). >> >> But recovery is supported by other platforms so I think recovery should work >> without calling rproc_handle_resources(). > > Right. Having taken a deeper look at the code, it seems that there is an issue. > In rproc_reset_rsc_table_on_detach(), we clean the resource table without > calling rproc_resource_cleanup(). > > It seems to me that rproc_reset_rsc_table_on_detach() should not be called in > __rproc_detach() but rather in rproc_detach() after calling > rproc_resource_cleanup(). > > Arnaud, I can confirm above is correct. After moving rsc_table_on_detach out of __rproc_detach the recovery works. I will send patch to fix that when I add recovery support on AMD-Xilinx platform driver. Thank you so much for looking into this. Tanmay >> >> May be re-storing resource table from firmware side after reboot isn't a good >> idea. I will try without it. >> >>> >>>> >>>> `cat /sys/class/remoteproc/remoteproc0/state` >>>> attached >>>> >>>> Somehow the sync between remote fw and linux isn't right. >>>> >>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tanmay >>>>>>>>> Regards >>>>>>>>> Arnaud >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Arnaud >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tanmay >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>

5 months, 1 week

1
0
0 0

Re: Testing on attach-detach recovery

by Tanmay Shah

On 7/3/25 2:49 AM, Arnaud POULIQUEN wrote: > > > On 7/2/25 19:00, Tanmay Shah wrote: >> >> >> On 7/2/25 10:47 AM, Arnaud POULIQUEN wrote: >>> >>> >>> On 7/2/25 17:23, Tanmay Shah wrote: >>>> >>>> >>>> On 7/2/25 2:18 AM, Arnaud POULIQUEN wrote: >>>>> >>>>> >>>>> On 7/1/25 23:19, Tanmay Shah wrote: >>>>>> >>>>>> >>>>>> On 7/1/25 1:06 PM, Tanmay Shah wrote: >>>>>>> >>>>>>> >>>>>>> On 7/1/25 12:56 PM, Tanmay Shah wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 7/1/25 12:18 PM, Arnaud POULIQUEN wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/1/25 17:16, Tanmay Shah wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/1/25 3:07 AM, Arnaud POULIQUEN wrote: >>>>>>>>>>> Hi Tanmay, >>>>>>>>>>> >>>>>>>>>>> On 6/27/25 23:29, Tanmay Shah wrote: >>>>>>>>>>>> Hello all, >>>>>>>>>>>> >>>>>>>>>>>> I am implementing remoteproc recovery on attach-detach use case. >>>>>>>>>>>> I have implemented the feature in the platform driver, and it works for >>>>>>>>>>>> boot >>>>>>>>>>>> recovery. >>>>>>>>>>> >>>>>>>>>>> Few questions to better understand your use case. >>>>>>>>>>> >>>>>>>>>>> 1) The linux remoteproc firmware attach to a a remote processor, and you >>>>>>>>>>> generate a crash of the remote processor, right? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes correct. >>>>>>>>>> >>>>>>>>>>> 1) How does the remoteprocessor reboot? On a remoteproc request or it >>>>>>>>>>> is an >>>>>>>>>>> autoreboot independent from the Linux core? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It is auto-reboot independent from the linux core. >>>>>>>>>> >>>>>>>>>>> 2) In case of auto reboot, when does the remoteprocessor send an even to >>>>>>>>>>> the >>>>>>>>>>> Linux remoteproc driver ? beforeor after the reset? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Right now, when Remote reboots, it sends crash event to remoteproc driver >>>>>>>>>> after >>>>>>>>>> reboot. >>>>>>>>>> >>>>>>>>>>> 3) Do you expect to get core dump on crash? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No coredump expected as of now, but only recovery. Eventually will >>>>>>>>>> implement >>>>>>>>>> coredump functionality as well. >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> However, I am stuck at the testing phase. >>>>>>>>>>>> >>>>>>>>>>>> When should firmware report the crash ? After reboot ? or during some >>>>>>>>>>>> kind of >>>>>>>>>>>> crash handler ? >>>>>>>>>>>> >>>>>>>>>>>> So far, I am reporting crash after rebooting remote processor, but it >>>>>>>>>>>> doesn't >>>>>>>>>>>> seem to work i.e. I don't see rpmsg devices created after recovery.> >>>>>>>>>>>> What should be the correct process to test this feature ? How other >>>>>>>>>>>> platforms >>>>>>>>>>>> are testing this? >>>>>>>>>>> >>>>>>>>>>> I have never tested it on ST board. As a first analysis, in case of >>>>>>>>>>> autoreboot >>>>>>>>>>> of the remote processor, it look like you should detach and reattach to >>>>>>>>>>> recover. >>>>>>>>>> >>>>>>>>>> That is what's done from the remoteproc framework. >>>>>>>>>> >>>>>>>>>>> - On detach the rpmsg devices should be unbind >>>>>>>>>>> - On attach the remote processor should request RPmsg channels using >>>>>>>>>>> the NS >>>>>>>>>>> announcement mechanism >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Main issue is, Remote firmware needs to wait till all above happens. Then >>>>>>>>>> only >>>>>>>>>> initialize virtio devices. Currently we don't have any way to notify >>>>>>>>>> recovery >>>>>>>>>> progress from linux to remote fw in the remoteproc framework. So I might >>>>>>>>>> have to >>>>>>>>>> introduce some platform specific mechanism in remote firmware to wait for >>>>>>>>>> recovery to complete successfully. >>>>>>>>> >>>>>>>>> I guess the rproc->clean_table contains a copy of the resource table >>>>>>>>> that is >>>>>>>>> reapplied on attach, and the virtio devices should be re-probed, right? >>>>>>>>> >>>>>>>>> During the virtio device probe, the vdev status in the resource table is >>>>>>>>> updated >>>>>>>>> to 7 when virtio is ready to communicate. Virtio should then call >>>>>>>>> rproc_virtio_notify() to inform the remote processor of the status update. >>>>>>>>> At this stage, your remoteproc driver should be able to send a mailbox >>>>>>>>> message >>>>>>>>> to inform the remote side about the recovery completion. >>>>>>>>> >>>>>>>> >>>>>>>> I think I spot the problem now. >>>>>>>> >>>>>>>> Linux side: file: remoteproc_core.c >>>>>>>> rproc_attach_recovery >>>>>>>> __rproc_detach >>>>>>>> cleans up the resource table and re-loads it >>>>>>>> __rproc_attach >>>>>>>> stops and re-starts subdevices >>>>>>>> >>>>>>>> >>>>>>>> Remote side: >>>>>>>> Remote re-boots after crash >>>>>>>> Detects crash happened previously >>>>>>>> notify crash to Linux >>>>>>>> (Linux is executing above flow meanwhile) >>>>>>>> starts creating virtio devices >>>>>>>> **rproc_virtio_create_vdev - parse vring & create vdev device** >>>>>>>> **rproc_virtio_wait_remote_ready - wait for remote ready** [1] >>>>>>>> >>>>>>>> I think Remote should wait on DRIVER_OK bit, before creating virtio devices. >>>>>>>> The temporary solution I implemented was to make sure vrings addresses are >>>>>>>> not 0xffffffff like following: >>>>>>>> >>>>>>>> while(rsc->rpmsg_vring0.da == FW_RSC_U32_ADDR_ANY || >>>>>>>> rsc->rpmsg_vring1.da == FW_RSC_U32_ADDR_ANY) { >>>>>>>> usleep(100); >>>>>>>> metal_cache_invalidate(rsc, rproc->rsc_len); >>>>>>>> } >>>>>>>> >>>>>>>> Above works, but I think better solution is to change sequence where remote >>>>>>>> waits before creating virtio devices. >>>>>>> >>>>>>> I am sorry, I should have said, remote should wait before parsing and >>>>>>> assigning vrings to virtio device. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] https://github.com/OpenAMP/open-amp/ >>>>>>>> blob/391671ba24840833d882c1a75c5d7307703b1cf1/lib/remoteproc/ >>>>>>>> remoteproc.c#L994 >>>>>>>> >>>>>> >>>>>> Actually upon further checking, I think above code is okay. I see that >>>>>> wait_remote_ready is called before vrings are setup on remote fw side. >>>>>> >>>>>> However, during recovery time on remote side, somehow I still have to >>>>>> implement >>>>>> platform specific wait for vrings to setup correctly. >>>>>> >>>>>> From linux side, DRIVER_OK bit is set before vrings are setup correctly. >>>>>> Because of that, when remote firmware sets up wrong vring addresses and then >>>>>> rpmsg channels are not created. >>>>>> >>>>>> I am investigating on this further. >>>>> >>>>> Do you reset the vdev status as requested by the virtio spec? >>>>> https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html… >>>>> >>>>> Regards, >>>>> Arnaud >>>>> >>>> >>>> Yes I do. I am actually restoring deafult resource table on firmware side, which >>>> will set rpmsg_vdev status to 0. >>>> >>>> However, when printing vrings right before wait_remote_ready, I see vrings are >>>> not set correctly from linux side: >>>> >>>> `vring0 = 0xFFFFFFFF, vring1 = 0xFFFFFFFF` >>> >>> That makes sense if values corresponds to the initial values of the resource >>> table >>> rproc->clean_table should contain a copy of these initial values. >>> >>>> >>>> However, the rproc state was still moved to attach when checked from remoteproc >>>> sysfs. >>> >>> Does the rproc_handle_resources() is called before going back in attached state? >> >> You are right. I think __rproc_attach() isn't calling rproc_handle_resources(). >> >> But recovery is supported by other platforms so I think recovery should work >> without calling rproc_handle_resources(). > > Right. Having taken a deeper look at the code, it seems that there is an issue. > In rproc_reset_rsc_table_on_detach(), we clean the resource table without > calling rproc_resource_cleanup(). > > It seems to me that rproc_reset_rsc_table_on_detach() should not be called in > __rproc_detach() but rather in rproc_detach() after calling > rproc_resource_cleanup(). > > Yes that sounds correct. It's long-weekend here in US. So, I will try this next week and update. Thanks, Tanmay >> >> May be re-storing resource table from firmware side after reboot isn't a good >> idea. I will try without it. >> >>> >>>> >>>> `cat /sys/class/remoteproc/remoteproc0/state` >>>> attached >>>> >>>> Somehow the sync between remote fw and linux isn't right. >>>> >>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tanmay >>>>>>>>> Regards >>>>>>>>> Arnaud >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Arnaud >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tanmay >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>

5 months, 2 weeks

1
0
0 0

Re: Testing on attach-detach recovery

by Tanmay Shah

On 7/2/25 10:47 AM, Arnaud POULIQUEN wrote: > > > On 7/2/25 17:23, Tanmay Shah wrote: >> >> >> On 7/2/25 2:18 AM, Arnaud POULIQUEN wrote: >>> >>> >>> On 7/1/25 23:19, Tanmay Shah wrote: >>>> >>>> >>>> On 7/1/25 1:06 PM, Tanmay Shah wrote: >>>>> >>>>> >>>>> On 7/1/25 12:56 PM, Tanmay Shah wrote: >>>>>> >>>>>> >>>>>> On 7/1/25 12:18 PM, Arnaud POULIQUEN wrote: >>>>>>> >>>>>>> >>>>>>> On 7/1/25 17:16, Tanmay Shah wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 7/1/25 3:07 AM, Arnaud POULIQUEN wrote: >>>>>>>>> Hi Tanmay, >>>>>>>>> >>>>>>>>> On 6/27/25 23:29, Tanmay Shah wrote: >>>>>>>>>> Hello all, >>>>>>>>>> >>>>>>>>>> I am implementing remoteproc recovery on attach-detach use case. >>>>>>>>>> I have implemented the feature in the platform driver, and it works for >>>>>>>>>> boot >>>>>>>>>> recovery. >>>>>>>>> >>>>>>>>> Few questions to better understand your use case. >>>>>>>>> >>>>>>>>> 1) The linux remoteproc firmware attach to a a remote processor, and you >>>>>>>>> generate a crash of the remote processor, right? >>>>>>>>> >>>>>>>> >>>>>>>> Yes correct. >>>>>>>> >>>>>>>>> 1) How does the remoteprocessor reboot? On a remoteproc request or it is an >>>>>>>>> autoreboot independent from the Linux core? >>>>>>>>> >>>>>>>> >>>>>>>> It is auto-reboot independent from the linux core. >>>>>>>> >>>>>>>>> 2) In case of auto reboot, when does the remoteprocessor send an even to >>>>>>>>> the >>>>>>>>> Linux remoteproc driver ? beforeor after the reset? >>>>>>>>> >>>>>>>> >>>>>>>> Right now, when Remote reboots, it sends crash event to remoteproc driver >>>>>>>> after >>>>>>>> reboot. >>>>>>>> >>>>>>>>> 3) Do you expect to get core dump on crash? >>>>>>>>> >>>>>>>> >>>>>>>> No coredump expected as of now, but only recovery. Eventually will implement >>>>>>>> coredump functionality as well. >>>>>>>> >>>>>>>>>> >>>>>>>>>> However, I am stuck at the testing phase. >>>>>>>>>> >>>>>>>>>> When should firmware report the crash ? After reboot ? or during some >>>>>>>>>> kind of >>>>>>>>>> crash handler ? >>>>>>>>>> >>>>>>>>>> So far, I am reporting crash after rebooting remote processor, but it >>>>>>>>>> doesn't >>>>>>>>>> seem to work i.e. I don't see rpmsg devices created after recovery.> >>>>>>>>>> What should be the correct process to test this feature ? How other >>>>>>>>>> platforms >>>>>>>>>> are testing this? >>>>>>>>> >>>>>>>>> I have never tested it on ST board. As a first analysis, in case of >>>>>>>>> autoreboot >>>>>>>>> of the remote processor, it look like you should detach and reattach to >>>>>>>>> recover. >>>>>>>> >>>>>>>> That is what's done from the remoteproc framework. >>>>>>>> >>>>>>>>> - On detach the rpmsg devices should be unbind >>>>>>>>> - On attach the remote processor should request RPmsg channels using the NS >>>>>>>>> announcement mechanism >>>>>>>>> >>>>>>>> >>>>>>>> Main issue is, Remote firmware needs to wait till all above happens. Then >>>>>>>> only >>>>>>>> initialize virtio devices. Currently we don't have any way to notify >>>>>>>> recovery >>>>>>>> progress from linux to remote fw in the remoteproc framework. So I might >>>>>>>> have to >>>>>>>> introduce some platform specific mechanism in remote firmware to wait for >>>>>>>> recovery to complete successfully. >>>>>>> >>>>>>> I guess the rproc->clean_table contains a copy of the resource table that is >>>>>>> reapplied on attach, and the virtio devices should be re-probed, right? >>>>>>> >>>>>>> During the virtio device probe, the vdev status in the resource table is >>>>>>> updated >>>>>>> to 7 when virtio is ready to communicate. Virtio should then call >>>>>>> rproc_virtio_notify() to inform the remote processor of the status update. >>>>>>> At this stage, your remoteproc driver should be able to send a mailbox >>>>>>> message >>>>>>> to inform the remote side about the recovery completion. >>>>>>> >>>>>> >>>>>> I think I spot the problem now. >>>>>> >>>>>> Linux side: file: remoteproc_core.c >>>>>> rproc_attach_recovery >>>>>> __rproc_detach >>>>>> cleans up the resource table and re-loads it >>>>>> __rproc_attach >>>>>> stops and re-starts subdevices >>>>>> >>>>>> >>>>>> Remote side: >>>>>> Remote re-boots after crash >>>>>> Detects crash happened previously >>>>>> notify crash to Linux >>>>>> (Linux is executing above flow meanwhile) >>>>>> starts creating virtio devices >>>>>> **rproc_virtio_create_vdev - parse vring & create vdev device** >>>>>> **rproc_virtio_wait_remote_ready - wait for remote ready** [1] >>>>>> >>>>>> I think Remote should wait on DRIVER_OK bit, before creating virtio devices. >>>>>> The temporary solution I implemented was to make sure vrings addresses are >>>>>> not 0xffffffff like following: >>>>>> >>>>>> while(rsc->rpmsg_vring0.da == FW_RSC_U32_ADDR_ANY || >>>>>> rsc->rpmsg_vring1.da == FW_RSC_U32_ADDR_ANY) { >>>>>> usleep(100); >>>>>> metal_cache_invalidate(rsc, rproc->rsc_len); >>>>>> } >>>>>> >>>>>> Above works, but I think better solution is to change sequence where remote >>>>>> waits before creating virtio devices. >>>>> >>>>> I am sorry, I should have said, remote should wait before parsing and >>>>> assigning vrings to virtio device. >>>>> >>>>>> >>>>>> >>>>>> [1] https://github.com/OpenAMP/open-amp/ >>>>>> blob/391671ba24840833d882c1a75c5d7307703b1cf1/lib/remoteproc/ >>>>>> remoteproc.c#L994 >>>>>> >>>> >>>> Actually upon further checking, I think above code is okay. I see that >>>> wait_remote_ready is called before vrings are setup on remote fw side. >>>> >>>> However, during recovery time on remote side, somehow I still have to implement >>>> platform specific wait for vrings to setup correctly. >>>> >>>> From linux side, DRIVER_OK bit is set before vrings are setup correctly. >>>> Because of that, when remote firmware sets up wrong vring addresses and then >>>> rpmsg channels are not created. >>>> >>>> I am investigating on this further. >>> >>> Do you reset the vdev status as requested by the virtio spec? >>> https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html… >>> >>> Regards, >>> Arnaud >>> >> >> Yes I do. I am actually restoring deafult resource table on firmware side, which >> will set rpmsg_vdev status to 0. >> >> However, when printing vrings right before wait_remote_ready, I see vrings are >> not set correctly from linux side: >> >> `vring0 = 0xFFFFFFFF, vring1 = 0xFFFFFFFF` > > That makes sense if values corresponds to the initial values of the resource table > rproc->clean_table should contain a copy of these initial values. > >> >> However, the rproc state was still moved to attach when checked from remoteproc >> sysfs. > > Does the rproc_handle_resources() is called before going back in attached state? You are right. I think __rproc_attach() isn't calling rproc_handle_resources(). But recovery is supported by other platforms so I think recovery should work without calling rproc_handle_resources(). May be re-storing resource table from firmware side after reboot isn't a good idea. I will try without it. > >> >> `cat /sys/class/remoteproc/remoteproc0/state` >> attached >> >> Somehow the sync between remote fw and linux isn't right. >> >>>> >>>>>> >>>>>> Thanks, >>>>>> Tanmay >>>>>>> Regards >>>>>>> Arnaud >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Arnaud >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tanmay >>>>>>>> >>>>>> >>>>> >>>> >>

5 months, 2 weeks

1
0
0 0

Re: Testing on attach-detach recovery

by Tanmay Shah

On 7/2/25 2:18 AM, Arnaud POULIQUEN wrote: > > > On 7/1/25 23:19, Tanmay Shah wrote: >> >> >> On 7/1/25 1:06 PM, Tanmay Shah wrote: >>> >>> >>> On 7/1/25 12:56 PM, Tanmay Shah wrote: >>>> >>>> >>>> On 7/1/25 12:18 PM, Arnaud POULIQUEN wrote: >>>>> >>>>> >>>>> On 7/1/25 17:16, Tanmay Shah wrote: >>>>>> >>>>>> >>>>>> On 7/1/25 3:07 AM, Arnaud POULIQUEN wrote: >>>>>>> Hi Tanmay, >>>>>>> >>>>>>> On 6/27/25 23:29, Tanmay Shah wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> I am implementing remoteproc recovery on attach-detach use case. >>>>>>>> I have implemented the feature in the platform driver, and it works for boot >>>>>>>> recovery. >>>>>>> >>>>>>> Few questions to better understand your use case. >>>>>>> >>>>>>> 1) The linux remoteproc firmware attach to a a remote processor, and you >>>>>>> generate a crash of the remote processor, right? >>>>>>> >>>>>> >>>>>> Yes correct. >>>>>> >>>>>>> 1) How does the remoteprocessor reboot? On a remoteproc request or it is an >>>>>>> autoreboot independent from the Linux core? >>>>>>> >>>>>> >>>>>> It is auto-reboot independent from the linux core. >>>>>> >>>>>>> 2) In case of auto reboot, when does the remoteprocessor send an even to the >>>>>>> Linux remoteproc driver ? beforeor after the reset? >>>>>>> >>>>>> >>>>>> Right now, when Remote reboots, it sends crash event to remoteproc driver >>>>>> after >>>>>> reboot. >>>>>> >>>>>>> 3) Do you expect to get core dump on crash? >>>>>>> >>>>>> >>>>>> No coredump expected as of now, but only recovery. Eventually will implement >>>>>> coredump functionality as well. >>>>>> >>>>>>>> >>>>>>>> However, I am stuck at the testing phase. >>>>>>>> >>>>>>>> When should firmware report the crash ? After reboot ? or during some >>>>>>>> kind of >>>>>>>> crash handler ? >>>>>>>> >>>>>>>> So far, I am reporting crash after rebooting remote processor, but it >>>>>>>> doesn't >>>>>>>> seem to work i.e. I don't see rpmsg devices created after recovery.> >>>>>>>> What should be the correct process to test this feature ? How other >>>>>>>> platforms >>>>>>>> are testing this? >>>>>>> >>>>>>> I have never tested it on ST board. As a first analysis, in case of >>>>>>> autoreboot >>>>>>> of the remote processor, it look like you should detach and reattach to >>>>>>> recover. >>>>>> >>>>>> That is what's done from the remoteproc framework. >>>>>> >>>>>>> - On detach the rpmsg devices should be unbind >>>>>>> - On attach the remote processor should request RPmsg channels using the NS >>>>>>> announcement mechanism >>>>>>> >>>>>> >>>>>> Main issue is, Remote firmware needs to wait till all above happens. Then only >>>>>> initialize virtio devices. Currently we don't have any way to notify recovery >>>>>> progress from linux to remote fw in the remoteproc framework. So I might >>>>>> have to >>>>>> introduce some platform specific mechanism in remote firmware to wait for >>>>>> recovery to complete successfully. >>>>> >>>>> I guess the rproc->clean_table contains a copy of the resource table that is >>>>> reapplied on attach, and the virtio devices should be re-probed, right? >>>>> >>>>> During the virtio device probe, the vdev status in the resource table is >>>>> updated >>>>> to 7 when virtio is ready to communicate. Virtio should then call >>>>> rproc_virtio_notify() to inform the remote processor of the status update. >>>>> At this stage, your remoteproc driver should be able to send a mailbox message >>>>> to inform the remote side about the recovery completion. >>>>> >>>> >>>> I think I spot the problem now. >>>> >>>> Linux side: file: remoteproc_core.c >>>> rproc_attach_recovery >>>> __rproc_detach >>>> cleans up the resource table and re-loads it >>>> __rproc_attach >>>> stops and re-starts subdevices >>>> >>>> >>>> Remote side: >>>> Remote re-boots after crash >>>> Detects crash happened previously >>>> notify crash to Linux >>>> (Linux is executing above flow meanwhile) >>>> starts creating virtio devices >>>> **rproc_virtio_create_vdev - parse vring & create vdev device** >>>> **rproc_virtio_wait_remote_ready - wait for remote ready** [1] >>>> >>>> I think Remote should wait on DRIVER_OK bit, before creating virtio devices. >>>> The temporary solution I implemented was to make sure vrings addresses are >>>> not 0xffffffff like following: >>>> >>>> while(rsc->rpmsg_vring0.da == FW_RSC_U32_ADDR_ANY || >>>> rsc->rpmsg_vring1.da == FW_RSC_U32_ADDR_ANY) { >>>> usleep(100); >>>> metal_cache_invalidate(rsc, rproc->rsc_len); >>>> } >>>> >>>> Above works, but I think better solution is to change sequence where remote >>>> waits before creating virtio devices. >>> >>> I am sorry, I should have said, remote should wait before parsing and >>> assigning vrings to virtio device. >>> >>>> >>>> >>>> [1] https://github.com/OpenAMP/open-amp/ >>>> blob/391671ba24840833d882c1a75c5d7307703b1cf1/lib/remoteproc/ remoteproc.c#L994 >>>> >> >> Actually upon further checking, I think above code is okay. I see that >> wait_remote_ready is called before vrings are setup on remote fw side. >> >> However, during recovery time on remote side, somehow I still have to implement >> platform specific wait for vrings to setup correctly. >> >> From linux side, DRIVER_OK bit is set before vrings are setup correctly. >> Because of that, when remote firmware sets up wrong vring addresses and then >> rpmsg channels are not created. >> >> I am investigating on this further. > > Do you reset the vdev status as requested by the virtio spec? > https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html… > > Regards, > Arnaud > Yes I do. I am actually restoring deafult resource table on firmware side, which will set rpmsg_vdev status to 0. However, when printing vrings right before wait_remote_ready, I see vrings are not set correctly from linux side: `vring0 = 0xFFFFFFFF, vring1 = 0xFFFFFFFF` However, the rproc state was still moved to attach when checked from remoteproc sysfs. `cat /sys/class/remoteproc/remoteproc0/state` attached Somehow the sync between remote fw and linux isn't right. >> >>>> >>>> Thanks, >>>> Tanmay >>>>> Regards >>>>> Arnaud >>>>> >>>>> >>>>>> >>>>>>> Regards, >>>>>>> Arnaud >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tanmay >>>>>> >>>> >>> >>

5 months, 2 weeks

1
0
0 0

Re: Testing on attach-detach recovery

by Tanmay Shah

On 7/1/25 12:18 PM, Arnaud POULIQUEN wrote: > > > On 7/1/25 17:16, Tanmay Shah wrote: >> >> >> On 7/1/25 3:07 AM, Arnaud POULIQUEN wrote: >>> Hi Tanmay, >>> >>> On 6/27/25 23:29, Tanmay Shah wrote: >>>> Hello all, >>>> >>>> I am implementing remoteproc recovery on attach-detach use case. >>>> I have implemented the feature in the platform driver, and it works for boot >>>> recovery. >>> >>> Few questions to better understand your use case. >>> >>> 1) The linux remoteproc firmware attach to a a remote processor, and you >>> generate a crash of the remote processor, right? >>> >> >> Yes correct. >> >>> 1) How does the remoteprocessor reboot? On a remoteproc request or it is an >>> autoreboot independent from the Linux core? >>> >> >> It is auto-reboot independent from the linux core. >> >>> 2) In case of auto reboot, when does the remoteprocessor send an even to the >>> Linux remoteproc driver ? beforeor after the reset? >>> >> >> Right now, when Remote reboots, it sends crash event to remoteproc driver after >> reboot. >> >>> 3) Do you expect to get core dump on crash? >>> >> >> No coredump expected as of now, but only recovery. Eventually will implement >> coredump functionality as well. >> >>>> >>>> However, I am stuck at the testing phase. >>>> >>>> When should firmware report the crash ? After reboot ? or during some kind of >>>> crash handler ? >>>> >>>> So far, I am reporting crash after rebooting remote processor, but it doesn't >>>> seem to work i.e. I don't see rpmsg devices created after recovery.> >>>> What should be the correct process to test this feature ? How other platforms >>>> are testing this? >>> >>> I have never tested it on ST board. As a first analysis, in case of autoreboot >>> of the remote processor, it look like you should detach and reattach to recover. >> >> That is what's done from the remoteproc framework. >> >>> - On detach the rpmsg devices should be unbind >>> - On attach the remote processor should request RPmsg channels using the NS >>> announcement mechanism >>> >> >> Main issue is, Remote firmware needs to wait till all above happens. Then only >> initialize virtio devices. Currently we don't have any way to notify recovery >> progress from linux to remote fw in the remoteproc framework. So I might have to >> introduce some platform specific mechanism in remote firmware to wait for >> recovery to complete successfully. > > I guess the rproc->clean_table contains a copy of the resource table that is > reapplied on attach, and the virtio devices should be re-probed, right? > > During the virtio device probe, the vdev status in the resource table is updated > to 7 when virtio is ready to communicate. Virtio should then call > rproc_virtio_notify() to inform the remote processor of the status update. > At this stage, your remoteproc driver should be able to send a mailbox message > to inform the remote side about the recovery completion. > I think I spot the problem now. Linux side: file: remoteproc_core.c rproc_attach_recovery __rproc_detach cleans up the resource table and re-loads it __rproc_attach stops and re-starts subdevices Remote side: Remote re-boots after crash Detects crash happened previously notify crash to Linux (Linux is executing above flow meanwhile) starts creating virtio devices **rproc_virtio_create_vdev - parse vring & create vdev device** **rproc_virtio_wait_remote_ready - wait for remote ready** [1] I think Remote should wait on DRIVER_OK bit, before creating virtio devices. The temporary solution I implemented was to make sure vrings addresses are not 0xffffffff like following: while(rsc->rpmsg_vring0.da == FW_RSC_U32_ADDR_ANY || rsc->rpmsg_vring1.da == FW_RSC_U32_ADDR_ANY) { usleep(100); metal_cache_invalidate(rsc, rproc->rsc_len); } Above works, but I think better solution is to change sequence where remote waits before creating virtio devices. [1] https://github.com/OpenAMP/open-amp/blob/391671ba24840833d882c1a75c5d730770… Thanks, Tanmay > Regards > Arnaud > > >> >>> Regards, >>> Arnaud >>> >>>> >>>> >>>> Thanks, >>>> Tanmay >>

5 months, 2 weeks

1
2
0 0

Re: Testing on attach-detach recovery

by Tanmay Shah

On 7/1/25 3:07 AM, Arnaud POULIQUEN wrote: > Hi Tanmay, > > On 6/27/25 23:29, Tanmay Shah wrote: >> Hello all, >> >> I am implementing remoteproc recovery on attach-detach use case. >> I have implemented the feature in the platform driver, and it works for boot >> recovery. > > Few questions to better understand your use case. > > 1) The linux remoteproc firmware attach to a a remote processor, and you > generate a crash of the remote processor, right? > Yes correct. > 1) How does the remoteprocessor reboot? On a remoteproc request or it is an > autoreboot independent from the Linux core? > It is auto-reboot independent from the linux core. > 2) In case of auto reboot, when does the remoteprocessor send an even to the > Linux remoteproc driver ? beforeor after the reset? > Right now, when Remote reboots, it sends crash event to remoteproc driver after reboot. > 3) Do you expect to get core dump on crash? > No coredump expected as of now, but only recovery. Eventually will implement coredump functionality as well. >> >> However, I am stuck at the testing phase. >> >> When should firmware report the crash ? After reboot ? or during some kind of >> crash handler ? >> >> So far, I am reporting crash after rebooting remote processor, but it doesn't >> seem to work i.e. I don't see rpmsg devices created after recovery.> >> What should be the correct process to test this feature ? How other platforms >> are testing this? > > I have never tested it on ST board. As a first analysis, in case of autoreboot > of the remote processor, it look like you should detach and reattach to recover. That is what's done from the remoteproc framework. > - On detach the rpmsg devices should be unbind > - On attach the remote processor should request RPmsg channels using the NS > announcement mechanism > Main issue is, Remote firmware needs to wait till all above happens. Then only initialize virtio devices. Currently we don't have any way to notify recovery progress from linux to remote fw in the remoteproc framework. So I might have to introduce some platform specific mechanism in remote firmware to wait for recovery to complete successfully. > Regards, > Arnaud > >> >> >> Thanks, >> Tanmay

5 months, 2 weeks

1
0
0 0

[OpenAMP/libmetal] 35c65e: cmake: add public header files for CMake shared an...

by aelray

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: 35c65e05b9c3f62713cf865c547287e5c8e3942f https://github.com/OpenAMP/libmetal/commit/35c65e05b9c3f62713cf865c547287e5… Author: Adel El-Rayyes <aelray(a)gmail.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: M lib/CMakeLists.txt Log Message: ----------- cmake: add public header files for CMake shared and static lib targets For consumers who don't want to install libmetal it's more convenient to use the CMake targets metal-static or metal-shared. However, they currently don't bring the necessary include directories (In contrast to the Zephyr version where the include directories are already exported via `zephyr_include_directories(...)` Signed-off-by: Adel El-Rayyes <aelray(a)gmail.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

5 months, 2 weeks

1
0
0 0

[OpenAMP/openamp-system-reference] 4a5842: examples: legacy_apps: zynqmp_r5: Move linker file...

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: 4a5842466f46847438a441446d9dd75d665a810f https://github.com/OpenAMP/openamp-system-reference/commit/4a5842466f468474… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt A examples/legacy_apps/machine/zynqmp_r5/linker_large_text.ld A examples/legacy_apps/machine/zynqmp_r5/linker_remote.ld M examples/legacy_apps/system/generic/machine/zynqmp_r5/CMakeLists.txt R examples/legacy_apps/system/generic/machine/zynqmp_r5/linker_large_text.ld R examples/legacy_apps/system/generic/machine/zynqmp_r5/linker_remote.ld Log Message: ----------- examples: legacy_apps: zynqmp_r5: Move linker file logic to machine/zynqmp_r5 As prep to support multiple OS's move the logic to be in area common for all RPU based OpenAMP applications. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: 9b5617141dc86b501f1a03223d3d35a84ccb8fd7 https://github.com/OpenAMP/openamp-system-reference/commit/9b5617141dc86b50… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt A examples/legacy_apps/machine/zynqmp_r5/generic/gic_init.c A examples/legacy_apps/machine/zynqmp_r5/helper.c M examples/legacy_apps/system/generic/machine/zynqmp_r5/CMakeLists.txt R examples/legacy_apps/system/generic/machine/zynqmp_r5/helper.c Log Message: ----------- examples: legacy_apps: zynqmp_r5: move GIC setup logic to baremetal area As the GIC initialization logic is specific to baremetal R5, move to that location. The logging is common though so keep it in common area. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: 4220a50955b831038895a106da1d06b295c3532e https://github.com/OpenAMP/openamp-system-reference/commit/4220a50955b83103… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: M examples/legacy_apps/examples/echo/CMakeLists.txt A examples/legacy_apps/examples/echo/generic/main.c M examples/legacy_apps/examples/echo/rpmsg-echo.c M examples/legacy_apps/examples/echo/rpmsg-echo.h M examples/legacy_apps/examples/matrix_multiply/CMakeLists.txt A examples/legacy_apps/examples/matrix_multiply/generic/main.c M examples/legacy_apps/examples/matrix_multiply/matrix_multiply.h M examples/legacy_apps/examples/matrix_multiply/matrix_multiplyd.c M examples/legacy_apps/examples/rpc_demo/CMakeLists.txt A examples/legacy_apps/examples/rpc_demo/generic/main.c M examples/legacy_apps/examples/rpc_demo/rpc_demo.c M examples/legacy_apps/examples/rpc_demo/rpmsg-rpc-demo.h Log Message: ----------- examples: legacy_apps: Prepare legacy demos to support other OS's In the original OpenAMP Remote files define main as weak and then provide strong main routines to separate files for echo, matrix and rpc_demo examples so that other OS's can be added too. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: d0696e30ca11f9acc47ad3c70ac00b9c9ea994b2 https://github.com/OpenAMP/openamp-system-reference/commit/d0696e30ca11f9ac… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt Log Message: ----------- examples: legacy_apps: zynqmp_r5: Move library dependency logic Move library dependency logic to zynqmp_r5 common area to ensure all OS targets will pick up dependencies. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: c3e2349c6a30d057d6782bcb57da371c525cbe3b https://github.com/OpenAMP/openamp-system-reference/commit/c3e2349c6a30d057… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: A examples/legacy_apps/examples/echo/freertos/main.c A examples/legacy_apps/examples/matrix_multiply/freertos/main.c A examples/legacy_apps/examples/rpc_demo/freertos/main.c Log Message: ----------- examples: legacy_apps: Add main routines for FreeRTOS OS for echo, matrix and rpc_demo Add main routine implementations for echo, matrix and rpc_demo examples for FreeRTOS OS. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: e0c9828a0c52f00320a7e932360b416bcfc992fd https://github.com/OpenAMP/openamp-system-reference/commit/e0c9828a0c52f003… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: A examples/legacy_apps/system/freertos/CMakeLists.txt Log Message: ----------- examples: legacy_apps: freertos: Add link dependency for library Add link dependency to ensure that library is found for FreeRTOS applications Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: 019186f66d6ae55d4c33acef03a1faef345e4ebc https://github.com/OpenAMP/openamp-system-reference/commit/019186f66d6ae55d… Author: Ben Levinsky <ben.levinsky(a)amd.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: A examples/legacy_apps/machine/zynqmp_r5/freertos/gic_init.c Log Message: ----------- examples: legacy_apps: freertos: implement GIC setup Introduce GIC initializatio nusing AMD FreeRTOS BSP API to connect GIC to libmetal ISR and application IRQ. Signed-off-by: Ben Levinsky <ben.levinsky(a)amd.com> Commit: 49d74fec0b509cba50f34a353e0a639b80a270f9 https://github.com/OpenAMP/openamp-system-reference/commit/49d74fec0b509cba… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2025-06-30 (Mon, 30 Jun 2025) Changed paths: M examples/legacy_apps/machine/zynqmp/platform_info.c M examples/legacy_apps/machine/zynqmp_r5/platform_info.c M examples/legacy_apps/machine/zynqmp_r5/zynqmp_r5_a53_rproc.c M examples/legacy_apps/system/CMakeLists.txt M examples/legacy_apps/system/freertos/CMakeLists.txt A examples/legacy_apps/system/freertos/suspend.c M examples/legacy_apps/system/generic/CMakeLists.txt A examples/legacy_apps/system/generic/suspend.c M examples/legacy_apps/system/linux/CMakeLists.txt M examples/legacy_apps/system/linux/machine/generic/platform_info.c A examples/legacy_apps/system/linux/suspend.c A examples/legacy_apps/system/suspend.h Log Message: ----------- examples: legacy_apps: Add default routines for suspend/resume The application or the CPU can be suspended and resumed while waiting for new RPMsg messages from the remote processor. This commit introduces `system_suspend` and `system_resume` functions, along with their implementations for different systems. - FreeRTOS: The suspend/resume functionality involves suspending and resuming the application. - Linux and Baremetal: By default, `metal_cpu_yield()` is called. However, these functions can be redefined in the machine layer if needed. The application can be suspended and resume waiting from new rpmsg from the remote. Add system_suspend and system_resume functions and associated implementation for the different system. For the FreeRTOS the suspend/resume consist in suspending resuming the application For Linux and baremetal metal_cpu_yield() is called by default, but some functions can be redefined in the machine on need Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Compare: https://github.com/OpenAMP/openamp-system-reference/compare/d0546027cd32...… To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

5 months, 2 weeks

1
0
0 0

Testing on attach-detach recovery

by Tanmay Shah

Hello all, I am implementing remoteproc recovery on attach-detach use case. I have implemented the feature in the platform driver, and it works for boot recovery. However, I am stuck at the testing phase. When should firmware report the crash ? After reboot ? or during some kind of crash handler ? So far, I am reporting crash after rebooting remote processor, but it doesn't seem to work i.e. I don't see rpmsg devices created after recovery. What should be the correct process to test this feature ? How other platforms are testing this? Thanks, Tanmay

5 months, 2 weeks

1
0
0 0

[RFC]: remoteproc state definition discrepancy in openamp library and Linux kernel framework

by Tanmay Shah

Hello all, I found out that there is discrepancy between remoteproc state definition in kernel and open-amp library: Linux kernel side definition: https://github.com/torvalds/linux/blob/52da431bf03b5506203bca27fe14a97895c8… enum rproc_state { RPROC_OFFLINE = 0, RPROC_SUSPENDED = 1, RPROC_RUNNING = 2, RPROC_CRASHED = 3, RPROC_DELETED = 4, RPROC_ATTACHED = 5, RPROC_DETACHED = 6, RPROC_LAST = 7, }; open-amp library side definition: https://github.com/OpenAMP/open-amp/blob/391671ba24840833d882c1a75c5d730770… /** * @brief Remote processor states */ enum remoteproc_state { /** Remote is offline */ RPROC_OFFLINE = 0, /** Remote is configured */ RPROC_CONFIGURED = 1, /** Remote is ready to start */ RPROC_READY = 2, /** Remote is up and running */ RPROC_RUNNING = 3, /** Remote is suspended */ RPROC_SUSPENDED = 4, /** Remote is has error; need to recover */ RPROC_ERROR = 5, /** Remote is stopped */ RPROC_STOPPED = 6, /** Just keep this one at the end */ RPROC_LAST = 7, }; IIUC, both side state definition should match, so that if remote needs to report crash error, it can use same name and mapped int value in the code. Please let me know if I am missing something in this understanding. Should we fix this? If so, I believe it should be library side. I am looking for suggestion to fix this without breaking backward compatibility: Approach 1: deprecate library side remoteproc_state definition. deprecate current enum (with __deprecated attribute or add comment) and introduce new one with same definition as in linux kernel. Then after 2 year (as per code of conduct policy) we can remove remoteproc_state. Approach 2: Platform driver uses library side remoteproc state definition. If we don't want to fix this, then another approach is, platform driver in linux kernel should have library-side remoteproc state definition and convert interprete it to kernel side remoteproc definition. With this second approach we don't have to deprecate anything, but platform drivers are responsible to maintain different remoteproc_state definition. (Might create confusion). I am open to any other suggestion regarding this. Thanks, Tanmay

5 months, 3 weeks

3
4
0 0

[RFC] Proposal to add mailbox interface

by Levinsky, Ben

[AMD Official Use Only - AMD Internal Distribution Only] Hello All, Presently for the OpenAMP Legacy Demos available in the community system reference repo the interrupt mechanism involves Libmetal APIs directly writing to control registers. This is an issue because it is clearly coupling the demos to vendor-specific logic. If we could instead have a refactor of demos without the vendor-specific interrupt register writes this would be a code clean up. [1] In one of the Libmetal-supported OS's, Zephyr there is already IPM support, though it is being deprecated as we have been told upstream. [2][3] That being said, there is already mailbox support in Zephyr and AMD is upstreaming support for this too. In order to (a) clean up the vendor-specific register writes and (b) add a generic mailbox support to Libmetal libraries below is a proposal for a patch series. 1. Add mailbox support - lib/mbox.h - descripe APIs for init, deinit, send and receive. 2. Add stubs for baremetal for the above APIs 3. Add stubs for freertos for the above APIs. 4. Add implementation for Zephyr with: - init - As Zephyr OS statically defines mailbox structures today based on device tree, this will simply store the mailbox structure [4] - deinit - free mailbox - send/receive will simply wrap around the Zephyr APIs for mbox send/receive 1. https://github.com/OpenAMP/libmetal/tree/main/lib/system/zephyr 2. https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/mbox 3. (pull request pending) 4. https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/mbox

5 months, 3 weeks

2
1
0 0

[OpenAMP/libmetal] 41c83b: lib: Remove system specific irq.h files

by Andrew Davis

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: 41c83bcffd61b36d4e2dc3d083bc5b98c1682f5e https://github.com/OpenAMP/libmetal/commit/41c83bcffd61b36d4e2dc3d083bc5b98… Author: Andrew Davis <afd(a)ti.com> Date: 2025-06-20 (Fri, 20 Jun 2025) Changed paths: M lib/irq.h M lib/system/freertos/CMakeLists.txt R lib/system/freertos/irq.h M lib/system/generic/CMakeLists.txt R lib/system/generic/irq.h M lib/system/linux/device.c M lib/system/nuttx/CMakeLists.txt M lib/system/nuttx/init.c M lib/system/nuttx/irq.c M lib/system/zephyr/CMakeLists.txt R lib/system/zephyr/irq.h Log Message: ----------- lib: Remove system specific irq.h files Many of the system specific irq.h files are empty, and those that are not are only used by the internal IRQ handling functions. Remove the empty ones and do not expose the contents of the internal ones outside of the compilation unit that uses them. Signed-off-by: Andrew Davis <afd(a)ti.com> Commit: a2bf06dc3ee878edcad282d41d06e5b9c049f0e5 https://github.com/OpenAMP/libmetal/commit/a2bf06dc3ee878edcad282d41d06e5b9… Author: Andrew Davis <afd(a)ti.com> Date: 2025-06-20 (Fri, 20 Jun 2025) Changed paths: M lib/log.h M lib/system/freertos/CMakeLists.txt R lib/system/freertos/log.h M lib/system/generic/CMakeLists.txt R lib/system/generic/log.h M lib/system/linux/CMakeLists.txt R lib/system/linux/log.h M lib/system/nuttx/CMakeLists.txt R lib/system/nuttx/log.h M lib/system/nuttx/sys.h M lib/system/zephyr/sys.h Log Message: ----------- lib: Remove system specific log.h files Most of the system specific log.h files are empty, and those that are not are only used by the internal log handling functions. Remove the empty ones and do not expose the contents of the internal ones outside of the compilation unit that uses them. Signed-off-by: Andrew Davis <afd(a)ti.com> Compare: https://github.com/OpenAMP/libmetal/compare/96c7cd26dca9...a2bf06dc3ee8 To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

5 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

Openamp-rp