- Openamp-rp - lists.openampproject.org

[OpenAMP/open-amp] 9c4ad7: virtqueue: add more virtqueue apis for the virtio ...

by Bowen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 9c4ad74ab4e31f4b74be78a69900d683cbd43680 https://github.com/OpenAMP/open-amp/commit/9c4ad74ab4e31f4b74be78a69900d683… Author: Bowen Wang <wangbowen6(a)xiaomi.com> Date: 2025-10-16 (Thu, 16 Oct 2025) Changed paths: M lib/include/openamp/virtqueue.h M lib/rpmsg/rpmsg_virtio.c M lib/virtio/virtqueue.c Log Message: ----------- virtqueue: add more virtqueue apis for the virtio device side In virtio device side, we always need to get the next avaiable buffer based on current buffer index. So add these two APIs for convinience use. For example, virtio blk driver origanize the buffer: +----------+ | Reqeust | (Flags: Read | Next) +----------+ | Buffer | (Flags: Read/Write | Next) +----------+ | Response | (Flags: Write) +----------+ For the virtio blk device size, we need get the Buffer and Response buffer based on the Request buffer index. So add api virtqueue_get_next_avail_buffer() to get the next available buffer based on the first buffer index. And rename the virtqueue_get_available_buffer() to virtqueue_get_first_avail_buffer() Signed-off-by: Bowen Wang <wangbowen6(a)xiaomi.com> Signed-off-by: Yongrong Wang <wangyongrong(a)xiaomi.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/open-amp/settings/notifications

1 month, 4 weeks

1
0
0 0

[OpenAMP/libmetal] 71c2fb: libmetal/nuttx: Update function prototype changes

by archer

Branch: refs/heads/main Home: https://github.com/OpenAMP/libmetal Commit: 71c2fb3643461e93b6638c3e7add97a2ed9d3e07 https://github.com/OpenAMP/libmetal/commit/71c2fb3643461e93b6638c3e7add97a2… Author: chao an <anchao.archer(a)bytedance.com> Date: 2025-10-16 (Thu, 16 Oct 2025) Changed paths: M lib/system/nuttx/time.c Log Message: ----------- libmetal/nuttx: Update function prototype changes clock_systime_timespec() always returns 0, so there is no need to check the return value in the caller code, let us remove the return value directly. From: int clock_systime_timespec(FAR struct timespec *ts) To: void clock_systime_timespec(FAR struct timespec *ts) Fix build break: libmetal/lib/system/nuttx/time.c: In function ‘metal_get_timestamp’: libmetal/lib/system/nuttx/time.c:21:11: error: void value not ignored as it ought to be 21 | r = clock_systime_timespec(&tp); | ^ make[1]: *** [Makefile:46: libmetal/lib/system/nuttx/time.o] Error 1 Signed-off-by: chao an <anchao.archer(a)bytedance.com> To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/libmetal/settings/notifications

1 month, 4 weeks

1
0
0 0

[OpenAMP/openamp-system-reference] 93d41c: legacy_apps: zynqmp_r5: use new xlnx extension module

by Tanmay

Branch: refs/heads/main Home: https://github.com/OpenAMP/openamp-system-reference Commit: 93d41caaf0da66d3c78614047f6abc526e6a78f3 https://github.com/OpenAMP/openamp-system-reference/commit/93d41caaf0da66d3… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-10-15 (Wed, 15 Oct 2025) Changed paths: M examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt M examples/legacy_apps/machine/zynqmp_r5/freertos/gic_init.c M examples/legacy_apps/machine/zynqmp_r5/generic/gic_init.c R 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/platform_info.h Log Message: ----------- legacy_apps: zynqmp_r5: use new xlnx extension module xlnx bsp implementation of some libmetal interfaces was moved from libmetal library repo to vendor repo. Application should use this new vendor specific library via libmetal API for platform specific configuration. For example, GIC configuration on cortex-R cores on xlnx platforms. Do required changes in legacy apps to use this new extension module for xlnx cortex-R port. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Commit: 78b2a197f0294e49098f7953f9c4d6b88e0336d2 https://github.com/OpenAMP/openamp-system-reference/commit/78b2a197f0294e49… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-10-15 (Wed, 15 Oct 2025) Changed paths: A examples/legacy_apps/cmake/platforms/cross_freertos_gcc.cmake M examples/legacy_apps/cmake/platforms/zynqmp_r5_generic.cmake M examples/legacy_apps/examples/echo/freertos/main.c M examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt M examples/legacy_apps/machine/zynqmp_r5/freertos/gic_init.c M examples/legacy_apps/system/freertos/CMakeLists.txt M examples/legacy_apps/system/freertos/suspend.c Log Message: ----------- legacy_apps: zynqmp_r5: fix freertos support Add cmake file for freertos. This assigns project system variable. Current build on freertos fails due to undefined API used. Also, suspend.c file declares extern variable that is not found during compile time. Solve this by getting current task handle in suspend resume APIs instead passing an argument to the function. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Commit: c34e3396de9f1eb0bc81f194a2874ea8faa9bb00 https://github.com/OpenAMP/openamp-system-reference/commit/c34e3396de9f1eb0… Author: Tanmay Shah <tanmay.shah(a)amd.com> Date: 2025-10-15 (Wed, 15 Oct 2025) Changed paths: M examples/legacy_apps/cmake/options.cmake M examples/legacy_apps/cmake/platforms/cross_freertos_gcc.cmake M examples/legacy_apps/cmake/platforms/cross_generic_gcc.cmake M examples/legacy_apps/cmake/platforms/cross_linux_gcc.cmake Log Message: ----------- legacy_apps: cmake: fix PROJECT_SYSTEM variable PROJECT_SYSTEM variable was added based on CMAKE_SYSTEM_NAME, however cmake doesn't support some RTOS names such as FreeRTOS. So, PROJECT_SYSTEM value can be different than CMAKE_SYSTEM_NAME. Toolchain file includes these cmake files. So PROJECT_SYSTEM variable assignment from options.cmake can be removed safely. Instead assign value to PROJECT_SYSTEM variable in relative OS cmake file. If PROJECT_SYSTEM is not passed by user via toolchain file, only then assign CMAKE_SYSTEM_NAME as PROJECT_SYSTEM. This is to maintain backward compatibility with current projects. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> Compare: https://github.com/OpenAMP/openamp-system-reference/compare/1a11089bf356...… To unsubscribe from these emails, change your notification settings at https://github.com/OpenAMP/openamp-system-reference/settings/notifications

2 months

1
0
0 0

[OpenAMP/open-amp] 31acf6: CI: fix No space left on device message

by Arnaud Pouliquen

Branch: refs/heads/main Home: https://github.com/OpenAMP/open-amp Commit: 31acf6453380abec1cbb956c514cdf8d690df66a https://github.com/OpenAMP/open-amp/commit/31acf6453380abec1cbb956c514cdf8d… Author: Arnaud Pouliquen <arnaud.pouliquen(a)foss.st.com> Date: 2025-10-15 (Wed, 15 Oct 2025) Changed paths: M .github/workflows/continuous-integration.yml M .github/workflows/heathcheck.yml Log Message: ----------- CI: fix No space left on device message Add jlumbroso/free-disk-space action to clean-up the workspace before running action. 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/open-amp/settings/notifications

2 months

1
0
0 0

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: Monday, October 6, 2025 4:53 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; > linux-arm-kernel(a)lists.infradead.org; linux-kernel(a)vger.kernel.org; dl-linux-imx > <linux-imx(a)nxp.com>; openamp-rp(a)lists.openampproject.org > Subject: [EXT] Re: [PATCH v2 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO 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. > > > As long as you keep the GPIO/I2C device as a child of the remote processor node, > you should not have deferred probe issues. > The|of_platform_populate()|function ensures > that the I2C/GPIO devices are probed when the remote processor is started. > Calling|devm_gpiochip_add_data|in the RPMsg driver probe should also > prevent such issues. > Here, deferred probing is not an issue -it's an intentional feature. We need to ensure that all consumers of the GPIO/I2C controllers remain in the deferred state until the remote processor is fully online. For instance, consider a regulator node that references a GPIO line from the RPMSG GPIO controller. The regulator will stay in the deferred state until the remote processor comes online and its services are announced and received. Thanks, Shenwei > Regards, > Arnaud > > > > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit

2 months, 1 week

1
0
0 0

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

2025

2024

2023

2022

2021

2020

2019

Openamp-rp