- Openamp-system-reference - lists.openampproject.org

[PATCH] remoteproc: xilinx: add mailbox channels for rpmsg

by Tanmay Shah

This patch makes each r5 core mailbox client and uses tx and rx channels to send and receive data to/from remote processor respectively. This is needed for rpmsg communication to remote processor. Signed-off-by: Tanmay Shah <tanmay.shah(a)amd.com> --- drivers/remoteproc/xlnx_r5_remoteproc.c | 329 +++++++++++++++++++----- 1 file changed, 271 insertions(+), 58 deletions(-) diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c index 2db57d394155..1e797c5ffc06 100644 --- a/drivers/remoteproc/xlnx_r5_remoteproc.c +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c @@ -8,16 +8,23 @@ #include <linux/dma-mapping.h> #include <linux/firmware/xlnx-zynqmp.h> #include <linux/kernel.h> +#include <linux/mailbox_client.h> +#include <linux/mailbox/zynqmp-ipi-message.h> #include <linux/module.h> #include <linux/of_address.h> #include <linux/of_platform.h> #include <linux/of_reserved_mem.h> #include <linux/platform_device.h> #include <linux/remoteproc.h> -#include <linux/slab.h> #include "remoteproc_internal.h" +/* IPI buffer MAX length */ +#define IPI_BUF_LEN_MAX 32U + +/* RX mailbox client buffer max length */ +#define MBOX_CLIENT_BUF_MAX (IPI_BUF_LEN_MAX + \ + sizeof(struct zynqmp_ipi_message)) /* * settings for RPU cluster mode which * reflects possible values of xlnx,cluster-mode dt-property @@ -65,6 +72,12 @@ static const struct mem_bank_data zynqmp_tcm_banks[] = { * @rmem: reserved memory region nodes from device tree * @rproc: rproc handle * @pm_domain_id: RPU CPU power domain id + * @rx_mc_buf: to copy data from mailbox rx channel + * @tx_mc_buf: to copy data to mailbox tx channel + * @mbox_work: schedule work after receiving data from mailbox + * @mbox_cl: mailbox client + * @tx_chan: mailbox tx channel + * @rx_chan: mailbox rx channel */ struct zynqmp_r5_core { struct device *dev; @@ -75,6 +88,14 @@ struct zynqmp_r5_core { struct reserved_mem **rmem; struct rproc *rproc; u32 pm_domain_id; + + /* mailbox related data structures */ + unsigned char rx_mc_buf[MBOX_CLIENT_BUF_MAX]; + unsigned char tx_mc_buf[MBOX_CLIENT_BUF_MAX]; + struct work_struct mbox_work; + struct mbox_client mbox_cl; + struct mbox_chan *tx_chan; + struct mbox_chan *rx_chan; }; /** @@ -92,6 +113,181 @@ struct zynqmp_r5_cluster { struct zynqmp_r5_core **r5_cores; }; +/** + * event_notified_idr_cb() - callback for vq_interrupt per notifyid + * @id: rproc->notify id + * @ptr: pointer to idr private data + * @data: data passed to idr_for_each callback + * + * Pass notification to remoteproc virtio + * + * Return: 0. having return is to satisfy the idr_for_each() function + * pointer input argument requirement. + **/ +static int event_notified_idr_cb(int id, void *ptr, void *data) +{ + struct rproc *rproc = data; + + if (rproc_vq_interrupt(rproc, id) == IRQ_NONE) + dev_dbg(&rproc->dev, "data not found for vqid=%d\n", id); + + return 0; +} + +/** + * handle_event_notified() - remoteproc notification work function + * @work: pointer to the work structure + * + * It checks each registered remoteproc notify IDs. + */ +static void handle_event_notified(struct work_struct *work) +{ + struct zynqmp_r5_core *r5_core; + struct rproc *rproc; + + r5_core = container_of(work, struct zynqmp_r5_core, mbox_work); + rproc = r5_core->rproc; + + /* + * We only use IPI for interrupt. The RPU firmware side may or may + * not write the notifyid when it trigger IPI. + * And thus, we scan through all the registered notifyids and + * find which one is valid to get the message. + * Even if message from firmware is NULL, we attempt to get vqid + */ + idr_for_each(&rproc->notifyids, event_notified_idr_cb, rproc); +} + +/** + * zynqmp_r5_mb_rx_cb() - receive channel mailbox callback + * @cl: mailbox client + * @msg: message pointer + * + * Receive data from ipi buffer, ack interrupt and then + * it will schedule the R5 notification work. + */ +static void zynqmp_r5_mb_rx_cb(struct mbox_client *cl, void *msg) +{ + struct zynqmp_ipi_message *ipi_msg, *buf_msg; + struct zynqmp_r5_core *r5_core; + size_t len; + + r5_core = container_of(cl, struct zynqmp_r5_core, mbox_cl); + + /* copy data from ipi buffer to r5_core */ + ipi_msg = (struct zynqmp_ipi_message *)msg; + buf_msg = (struct zynqmp_ipi_message *)r5_core->rx_mc_buf; + len = ipi_msg->len; + if (len > IPI_BUF_LEN_MAX) { + dev_warn(r5_core->dev, "msg size exceeded than %d\n", + IPI_BUF_LEN_MAX); + len = IPI_BUF_LEN_MAX; + } + buf_msg->len = len; + memcpy(buf_msg->data, ipi_msg->data, len); + + /* received and processed interrupt ack */ + if (mbox_send_message(r5_core->rx_chan, NULL) < 0) + dev_err(r5_core->dev, "ack failed to mbox rx_chan\n"); + + schedule_work(&r5_core->mbox_work); +} + +/** + * zynqmp_r5_setup_mbox() - Setup mailboxes related properties + * this is used for each individual R5 core + * + * @r5_core: pointer to the ZynqMP r5 core data + * + * Function to setup mailboxes related properties + * + */ +static void zynqmp_r5_setup_mbox(struct zynqmp_r5_core *r5_core) +{ + struct zynqmp_r5_cluster *cluster; + struct mbox_client *mbox_cl; + + cluster = dev_get_drvdata(r5_core->dev->parent); + + /** + * ToDo: Use only one IPI channel for APU to communicate with both RPUs + * in split mode. As of now, two IPI channels are expeceted for APU + * to communicate with RPU. for example, APU(IPI0)<-> RPU0(IPI1) and + * APU(IPI7)<->RPU1(IPI2). However, this is not the optimized use + * of the hardware. As per hardware reference manual, each IPI channel + * can receive interrupt from another IPI channel. So APU must be able + * to communicate with both RPUs simultaneously using same IPI channel. + * For example, this is valid case: APU(IPI0)<->RPU0(IPI1) and + * APU(IPI0)<->RPU1(IPI2). However, with current available examples + * and RPU firmware, this configuration in device-tree is causing system-crash. + * And so, using extra IPI channel is required in device-tree. In split + * mode explicitly inform user about this limitation and requirement. + */ + if (cluster->mode == SPLIT_MODE) + dev_warn(r5_core->dev, "split mode: APU should use two IPI channels\n"); + + mbox_cl = &r5_core->mbox_cl; + mbox_cl->rx_callback = zynqmp_r5_mb_rx_cb; + mbox_cl->tx_block = false; + mbox_cl->knows_txdone = false; + mbox_cl->tx_done = NULL; + mbox_cl->dev = r5_core->dev; + + /* Request TX and RX channels */ + r5_core->tx_chan = mbox_request_channel_byname(mbox_cl, "tx"); + if (IS_ERR(r5_core->tx_chan)) { + r5_core->tx_chan = NULL; + return; + } + + r5_core->rx_chan = mbox_request_channel_byname(mbox_cl, "rx"); + if (IS_ERR(r5_core->rx_chan)) { + mbox_free_channel(r5_core->tx_chan); + r5_core->rx_chan = NULL; + r5_core->tx_chan = NULL; + return; + } + + INIT_WORK(&r5_core->mbox_work, handle_event_notified); +} + +static void zynqmp_r5_free_mbox(struct zynqmp_r5_core *r5_core) +{ + if (r5_core->tx_chan) { + mbox_free_channel(r5_core->tx_chan); + r5_core->tx_chan = NULL; + } + + if (r5_core->rx_chan) { + mbox_free_channel(r5_core->rx_chan); + r5_core->rx_chan = NULL; + } +} + +/* + * zynqmp_r5_core_kick() - kick a firmware if mbox is provided + * @rproc: r5 core's corresponding rproc structure + * @vqid: virtqueue ID + */ +static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid) +{ + struct zynqmp_r5_core *r5_core = rproc->priv; + struct device *dev = r5_core->dev; + struct zynqmp_ipi_message *mb_msg; + int ret; + + /* don't handle kick if mbox setup failed for this core */ + if (!r5_core->tx_chan && !r5_core->rx_chan) + return; + + mb_msg = (struct zynqmp_ipi_message *)r5_core->tx_mc_buf; + memcpy(mb_msg->data, &vqid, sizeof(vqid)); + mb_msg->len = sizeof(vqid); + ret = mbox_send_message(r5_core->tx_chan, mb_msg); + if (ret < 0) + dev_warn(dev, "failed to send message\n"); +} + /* * zynqmp_r5_set_mode() * @@ -227,6 +423,63 @@ static int zynqmp_r5_mem_region_unmap(struct rproc *rproc, return 0; } +/** + * zynqmp_r5_get_mem_region_node() + * parse memory-region property and get reserved mem regions + * + * @r5_core: pointer to zynqmp_r5_core type object + * + * Return: 0 for success and error code for failure. + */ +static int zynqmp_r5_get_mem_region_node(struct zynqmp_r5_core *r5_core) +{ + struct device_node *np, *rmem_np; + struct reserved_mem **rmem; + int res_mem_count, i; + struct device *dev; + + dev = r5_core->dev; + np = r5_core->np; + + res_mem_count = of_property_count_elems_of_size(np, "memory-region", + sizeof(phandle)); + + if (res_mem_count <= 0) { + dev_warn(dev, "failed to get memory-region property %d\n", + res_mem_count); + return 0; + } + + if (!r5_core->tx_chan && !r5_core->rx_chan) + res_mem_count = 1; + + rmem = devm_kcalloc(dev, res_mem_count, + sizeof(struct reserved_mem *), GFP_KERNEL); + if (!rmem) + return -ENOMEM; + + for (i = 0; i < res_mem_count; i++) { + rmem_np = of_parse_phandle(np, "memory-region", i); + if (!rmem_np) + goto release_rmem; + + rmem[i] = of_reserved_mem_lookup(rmem_np); + if (!rmem[i]) { + of_node_put(rmem_np); + goto release_rmem; + } + + of_node_put(rmem_np); + } + + r5_core->rmem_count = res_mem_count; + r5_core->rmem = rmem; + return 0; + +release_rmem: + return -EINVAL; +} + /* * add_mem_regions_carveout() * @rproc: single R5 core's corresponding rproc instance @@ -572,6 +825,20 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc) return ret; } + /* + * If mailbox nodes are disabled using "status" property then setting up + * mailbox channels will be failed and in that case, we don't need vrings + * and vdevbuffer for this core. So, setup mailbox before parsing + * memory-region property. If "tx" and "rx" mailboxes are not setup, then + * only parse and add first memory-region carveout. As per bindings, it + * must be firmware load region + */ + zynqmp_r5_setup_mbox(rproc->priv); + + ret = zynqmp_r5_get_mem_region_node(rproc->priv); + if (ret) + dev_warn(&rproc->dev, "memory-region prop failed %d\n", ret); + ret = add_mem_regions_carveout(rproc); if (ret) { dev_err(&rproc->dev, "failed to get reserve mem regions %d\n", ret); @@ -597,6 +864,8 @@ static int zynqmp_r5_rproc_unprepare(struct rproc *rproc) r5_core = (struct zynqmp_r5_core *)rproc->priv; + zynqmp_r5_free_mbox(r5_core); + for (i = 0; i < r5_core->tcm_bank_count; i++) { pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id; if (zynqmp_pm_release_node(pm_domain_id)) @@ -617,6 +886,7 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = { .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table, .sanity_check = rproc_elf_sanity_check, .get_boot_addr = rproc_elf_get_boot_addr, + .kick = zynqmp_r5_rproc_kick, }; /** @@ -726,59 +996,6 @@ static int zynqmp_r5_get_tcm_node(struct zynqmp_r5_cluster *cluster) return 0; } -/** - * zynqmp_r5_get_mem_region_node() - * parse memory-region property and get reserved mem regions - * - * @r5_core: pointer to zynqmp_r5_core type object - * - * Return: 0 for success and error code for failure. - */ -static int zynqmp_r5_get_mem_region_node(struct zynqmp_r5_core *r5_core) -{ - struct device_node *np, *rmem_np; - struct reserved_mem **rmem; - int res_mem_count, i; - struct device *dev; - - dev = r5_core->dev; - np = r5_core->np; - - res_mem_count = of_property_count_elems_of_size(np, "memory-region", - sizeof(phandle)); - if (res_mem_count <= 0) { - dev_warn(dev, "failed to get memory-region property %d\n", - res_mem_count); - return 0; - } - - rmem = devm_kcalloc(dev, res_mem_count, - sizeof(struct reserved_mem *), GFP_KERNEL); - if (!rmem) - return -ENOMEM; - - for (i = 0; i < res_mem_count; i++) { - rmem_np = of_parse_phandle(np, "memory-region", i); - if (!rmem_np) - goto release_rmem; - - rmem[i] = of_reserved_mem_lookup(rmem_np); - if (!rmem[i]) { - of_node_put(rmem_np); - goto release_rmem; - } - - of_node_put(rmem_np); - } - - r5_core->rmem_count = res_mem_count; - r5_core->rmem = rmem; - return 0; - -release_rmem: - return -EINVAL; -} - /* * zynqmp_r5_core_init() * Create and initialize zynqmp_r5_core type object @@ -806,10 +1023,6 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster, for (i = 0; i < cluster->core_count; i++) { r5_core = cluster->r5_cores[i]; - ret = zynqmp_r5_get_mem_region_node(r5_core); - if (ret) - dev_warn(dev, "memory-region prop failed %d\n", ret); - /* Initialize r5 cores with power-domains parsed from dts */ ret = of_property_read_u32_index(r5_core->np, "power-domains", 1, &r5_core->pm_domain_id); base-commit: 90d6db82626be5e5fe085f4f58c49a080c420fa6 -- 2.25.1

3 years, 1 month

1
0
0 0

OpenAMP System Reference WG

by Chan King Choy, Nathalie

First meeting of 2023. Agenda: * Bill: What are the 2023 HPP objectives? * All: Discuss brainstorm list<https://docs.google.com/document/d/19Bpss2PHw8xavpviWZ1vu45hxrIbBG8mSSgKhrE…> on what makes sense to work on next * Nathalie: Scheduling 2023 meeting series [https://st2.zoom.us/static/6.3.10219/image/new/ZoomLogo_110_25.png]<https://zoom.us/> Hi there, Nathalie Chan King Choy is inviting you to a scheduled Zoom meeting. Join Zoom Meeting<https://xilinx.zoom.us/j/91913123613?pwd=TVl6UldtR1k1R3RVY3ZueEdOQ1A2UT09&f…> Phone one-tap: US: +16699006833,,91913123613#,,,,,,0#,,3787125748#<tel:+16699006833,,91913123613#,,,,,,0#,,3787125748#> or +17209289299,,91913123613#,,,,,,0#,,3787125748#<tel:+17209289299,,91913123613#,,,,,,0#,,3787125748#> Meeting URL: https://xilinx.zoom.us/j/91913123613?pwd=TVl6UldtR1k1R3RVY3ZueEdOQ1A2UT09&f… Meeting ID: 919 1312 3613 Passcode: KxRC6Aut@y Join by Telephone For higher quality, dial a number based on your current location. Dial: US: +1 669 900 6833 or +1 720 928 9299 or +1 929 205 6099 or 888 475 4499 (Toll Free) or 833 548 0276 (Toll Free) or 833 548 0282 (Toll Free) or 877 853 5257 (Toll Free) India: +91 446 480 2722 or +91 806 480 2722 or +91 80 71 279 440 or +91 116 480 2722 or +91 22 48 798 004 or +91 224 879 8012 or +91 225 097 2744 or +91 225 097 2745 or +91 226 480 2722 or +91 22 71 279 525 or +91 406 480 2722 or 000 800 050 5050 (Toll Free) or 000 800 001 4002 (Toll Free) Ireland: +353 1 536 9320 or +353 1 653 3895 or +353 6 163 9031 or 1800 901 561 (Toll Free) or 1800 943 965 (Toll Free) or 1800 949 238 (Toll Free) Singapore: +65 3165 1065 or +65 3158 7288 or 1800 407 5602 (Toll Free) or 800 101 3814 (Toll Free) or 800 852 6054 (Toll Free) Meeting ID: 919 1312 3613 Passcode: 3787125748 International numbers<https://xilinx.zoom.us/u/aeBuTEAkLY> Join from a Video Conference room system Meeting ID: 919 1312 3613 Passcode: 3787125748 US: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 APAC: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 India: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 Europe: 91913123613(a)global.zoomcrc.com<mailto:91913123613@global.zoomcrc.com> Passcode: 3787125748 SIP: 91913123613(a)zoomcrc.com<mailto:91913123613@zoomcrc.com> Passcode: 3787125748

3 years, 2 months

1
0
0 0

2022-12-14 OpenAMP System Reference notes and action items

by Chan King Choy, Nathalie

Hi all, Notes from today's call are posted at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… Link to the google doc with brainstorm ideas for 2023 is below, so feel free to add to it as you get ideas. Action items * @Chan King Choy, Nathalie<mailto:nathalie.chan-king-choy@amd.com>: Ask Linaro Events what attendee info is possible to share with us, if we are interested in making contact * (DONE) Nathalie, Tanmay: Check if YouTube comments are enabled for [https://www.youtube.com/watch?v=bKhZIAt4DkI our webinar video] * Yes, they are enabled * @Tammy Leino<mailto:Tammy_Leino@mentor.com>: ask Marketing manager to see what he thinks about Nucleus binary download for demo * @Milea, Danut Gabriel (Danut)<mailto:Danut.Milea@windriver.com>: ask WR about binary SDK support for smaller target like R5 on ZCU102 * (DONE) Nathalie: Compile brainstorm ideas for next steps into a Google Doc and share for adding to it & discussing in January * [https://docs.google.com/document/d/19Bpss2PHw8xavpviWZ1vu45hxrIbBG8mSSgKhrE… Doc is here] (access limited to WG members) Happy Holidays! -Nathalie

3 years, 2 months

1
0
0 0

Agenda for 2022-12-14 OpenAMP System Reference call

by Chan King Choy, Nathalie

Hi all, Initial proposed topics for tomorrow's OpenAMP System Reference call: * Key learnings / retrospective on Tuesday's webinar * Next steps for System Reference WG * Call frequency going forward for System Reference WG Any other topics, please let us know. Bruce & Mathieu, if you would like to join in the discussion on Key learnings / retrospective on Tuesday's webinar, here's the Zoom link for tomorrow. The call is at 9:30am Pacific / 10:30am Mountain / 12:30pm Eastern https://xilinx.zoom.us/j/91782323144?pwd=SDAxbUZLSWQ1akEvek9tY0dUcWZsZz09&f… Thanks & regards, Nathalie

3 years, 2 months

2
1
0 0

Webinar merged slide deck - needs update to Try it on your own

by Chan King Choy, Nathalie

Hi Bill, I've merged the slides, removed keep-out rectangles, and put it in our webinar Google Drive folder & also added this link to the top of the Webinar Plan document<https://docs.google.com/document/d/1R-uUgavNI2GCcM133YfgCY5SMLanGT_-DN1nu6R…>: https://docs.google.com/presentation/d/1QE0zyCxm54KoTDuWKS0Xh-mml3SneQjecDg… You can update the Try it on your own slide when you are ready & PDF this for Linaro Events to post prior to the webinar. Thanks & regards, Nathalie

3 years, 2 months

3
4
0 0

Calling for agenda: 2022-12-07 OpenAMP System Reference

by Chan King Choy, Nathalie

Hi all, I made this reminder LinkedIn post on Friday, if you want to like it so it shows up in the feed of your networks: https://www.linkedin.com/feed/update/urn:li:activity:7004598893573267456 I've submitted the webinar video to Linaro events. * We've still got a few open items in the tracking sheet to discuss: https://docs.google.com/spreadsheets/d/1SkQvq34NJBjJM56T6nm9fknJGTHutfV-LJd… (I added the to do items from Bill's email) * Brainstorm some backup questions if Q/A is quiet * Any specific topic requests? Thanks & regards, Nathalie

3 years, 2 months

2
4
0 0

2022-12-07 OpenAMP System Reference notes and action items

by Chan King Choy, Nathalie

Hi all, Notes from today are posted at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… * Action items: * Tammy: Combine doxygen & markdown docs into same doc folder. OK to rename to "doc" to match libmetal. * Dan to try out demo4 shortcut in demo-lite * Dan to split out demo-lite instructions from build instructions in https://github.com/danmilea/hypervisorless_virtio_zcu102/blob/openamp-demo/… and submit PR so each is linked to show up in the docs for demo * Tammy will pull in Bruce's README as Markdown https://github.com/devicetree-org/lopper/tree/systemdt-linaro-demo/demos/op… * Tammy will pull in System Reference repo into the docs, which will automatically pull in Tanmay's standalone instructions * All: Try things out today or tomorrow & let Bill know feedback * Arnaud to merge https://github.com/OpenAMP/openamp-system-reference/pull/5 Convergence: [Chart, bar chart Description automatically generated] Thanks & regards, Nathalie

3 years, 2 months

1
0
0 0

OpenAMP System Reference Webinar video - opportunity to review before submission

by Chan King Choy, Nathalie

Hi team, Nice work on all your slides and recordings! Thank you so much for submitting recordings early, so that I could get most of the edits in place before the end-of-quarter craziness that I got swept up in this week. Here is the webinar video combined end-to-end if anyone wants to watch it. I have only watched the components on 2x and the transitions at normal speed. I'll watch the whole thing at normal speed over the weekend. https://drive.google.com/file/d/1XcQGtFZSDhbuj8v7vwb8GGcVyNZvfCFw/view?usp=… The components are in the release candidate folder: https://drive.google.com/drive/folders/1rZbnPeR2Ew5hTXz7N91YHRCQtDMEwawY?us… Updates since what we discussed on Nov 29th: * Bill intro & wrap up slides now use devicetree. * Arnaud's new recording footage is used * Dan's hflip video is incorporated * I added a section where Tomas introduces himself & Bruce from the discarded footage, because the good take didn't include it. * Sped up the "dead time" sections of Arnaud's, Dan's & Tanmay's videos (e.g. boot). Bruce's demo didn't have any long typing/execution gaps when he wasn't speaking. If I sped up execution, I annotated for transparency with a green box with white text. If I just sped up stuff like typing/scrolling then I didn't add the green box annotation. * Added fade transitions between sections. * There was 1 title slide of Bill's with a page # that I tried to hide, but it shows up for a fraction of a second still because of limitations with how the fade effect works. I hide all the page #s because otherwise we were restarting numbering with each new deck. @Bill Mills<mailto:bill.mills@linaro.org>: Assuming it has no issues when I watch it at normal speed on the weekend, how to submit this to Linaro Events on Monday? If we want to share the Google Drive link with them, we have to add them to the access for this file. I will work on the OpenAMP website update & TSC email later today. Wanted to get this video out first in case anyone wanted to review it. Thanks & regards, Nathalie

3 years, 2 months

1
0
0 0

2022-11-29 OpenAMP System Reference recording day notes and action items

by Chan King Choy, Nathalie

Hi all, Notes from today's call are at https://github.com/OpenAMP/openamp-system-reference/wiki/OpenAMP-System-Ref… Action items: * Tomas will try to get hold of Rob from NXP to ask about their membership in OpenAMP * Bill: Add to live slides: slide to mention all the mailing lists (OpenAMP, Linux RP?), Discord link * All: Send Nathalie your head shot or add it to the wrap-up slide https://docs.google.com/presentation/d/1bbdn1irvwdDoW9cR1B9RqVhhCOrK7Lr4JOA… * Nathalie: Add employers to Q/A slide * Bruce will send Bill the branch on Lopper GitHub repo * (DONE) Bill: Let Nathalie know which slide deck & slide # to fix in editing of video Did everyone's calendar reflect my cancellation of Wednesday's call? The system reference mailing list was recently changed to text-based, so not sure how that works with calendar entries... Thanks & regards, Nathalie

3 years, 2 months

2
1
0 0

Canceled: OpenAMP System Reference

by Chan King Choy, Nathalie

Thanks, everyone, for getting your recording submissions in & reviewing the videos so that we could cover all our discussion for the week in our Tuesday slot. Cancelling Wednesday slot this week.

3 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

Openamp-system-reference