diff --git a/current/application_services.rst b/current/application_services.rst deleted file mode 100644 index bc5a772..0000000 --- a/current/application_services.rst +++ /dev/null @@ -1,42 +0,0 @@ -============================== -Application Services Sub-Group -============================== - -Introduction ------------- - -This sub-group covers the application space that sits on top of OpenAMP and describes higher level services for - - - file sharing - - proxy and/or forwarding of IP ports - - debug proxy - - high level IPC APIs for send-receive-reply / byte streams / message-based connections / pub/sub - - IPC server registration and client binding - - application partitioning using RPCs, C & non-C languages, canonical format - - bare metal APIs (using RPC) for stdio, socket IO, other APIs - -Communications --------------- - -Mailing list -~~~~~~~~~~~~ - -We have a Mailman list for app-services discussions. You can find info about it, reach the link to the archives, and subscribe/unsubscribe `here `_. - -Meetings -~~~~~~~~ - -Check out the meeting notes for the Application Services meetings on the :ref:`OpenAMP Meeting Notes page`. - -Documentation -------------- - -Placeholder -~~~~~~~~~~~ - -Placeholder for other documentation here - -Future work ------------ - -Check out the future work list for the Application Services sub-group in the :ref:`future-services-work-label` section. \ No newline at end of file diff --git a/current/ci.rst b/current/ci.rst deleted file mode 100644 index 9441b7d..0000000 --- a/current/ci.rst +++ /dev/null @@ -1,6 +0,0 @@ -==================== -OpenAMP CI Sub-Group -==================== - - - CI regression for every push request from OpenAMP repo - - Enabling OpenAMP tests for different users to run on different platforms diff --git a/current/device_trees.rst b/current/device_trees.rst deleted file mode 100644 index 8893b94..0000000 --- a/current/device_trees.rst +++ /dev/null @@ -1,44 +0,0 @@ -============================ -System Device Tree Sub-Group -============================ - -Introduction ------------- - -Todays heterogeneous SoCs are very hard to configure. Issues like which cores, memory and devices belongs to which operating systems, hypervisors and firmware is done in an ad-hoc, error prone way. System Device Trees will change all that by extending todays device trees, used by Linux, Xen, uboot, etc. to describe the full system and also include configuration information on what belongs where. - -Communications --------------- -Mailing list -~~~~~~~~~~~~ - -We have a Mailman list for system-dt discussions. You can find info about it, reach the link to the archives, and subscribe/unsubscribe `here `_ - -Meetings -~~~~~~~~ - -Check out the meeting notes for the System Device Tree meetings on the :ref:`OpenAMP Meeting Notes page`. - -Documentation -------------- -System DT intro presentation given at Linaro Connect SAN19 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - - `Video `_ - - `Slides `_ - -Placeholder for Stefano to populate -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Placeholder for other documentation here - -Lopper -~~~~~~ - -Lopper is a device tree manipulation tool that has been created to provide data driven manipulation and transformation of System Device Trees into any number of output formats, with an emphasis on conversion to standard device trees. - -The source code and information can be found at: https://github.com/devicetree-org/lopper/ - -Future work ------------ - -Check out the future work list for the System Device Tree sub-group in the :ref:`future-device-tree-work-label` section \ No newline at end of file diff --git a/current/inclusive_language.rst b/current/inclusive_language.rst deleted file mode 100644 index 7c3af18..0000000 --- a/current/inclusive_language.rst +++ /dev/null @@ -1,39 +0,0 @@ -============================================= -Inclusive Language and Biased Terms Sub-Group -============================================= - -This proposal from Bill Mills was approved at the 10/22/21 OpenAMP TSC: - -replace master with main ------------------------- - -github has special case logic to make this easier: https://github.com/github/renaming - -remoteproc context ------------------- - - - "slave" should be "remote processor" - - "master" should be "remoteproc host" - -virto context -------------- - -virtio spec uses "device" and "driver". suggest we use "virtio device" and "virtio driver" - -Examples of devices: - - - vitioblk device - - virtio network interface - -For today's remoteproc rpmsg, Linux is always the driver side. - -Some virtio "devices" are not very device like and instead are more like services. Alternative for such cases - - - "application service" and "application client" - -Examples: - - - vsock: service is the one that calls accept on the socket - - p9fs: service is the side that has the filesystem - -Note that a remote processor can host a service and be a client at the same time. The terminology is per service. \ No newline at end of file diff --git a/current/index.rst b/current/index.rst deleted file mode 100644 index d49a089..0000000 --- a/current/index.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. OpenAMP documentation master file, created by - sphinx-quickstart on Wed Oct 5 10:21:26 2022. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - -Current Work -============ - -.. toctree:: - :maxdepth: 2 - :caption: Contents: - - remoteproc - device_trees - application_services - inclusive_language - ci - ipc - system_reference - older_topics \ No newline at end of file diff --git a/current/ipc.rst b/current/ipc.rst deleted file mode 100644 index c5947ea..0000000 --- a/current/ipc.rst +++ /dev/null @@ -1,5 +0,0 @@ -============= -IPC Sub-Group -============= - - - Shared memory support to use DMA buffer in Linux userspace \ No newline at end of file diff --git a/current/older_topics.rst b/current/older_topics.rst deleted file mode 100644 index 4e4f79a..0000000 --- a/current/older_topics.rst +++ /dev/null @@ -1,9 +0,0 @@ -============ -Older Topics -============ - -Formation of OpenAMP project ----------------------------- - - - Launched as a `Linaro Community Project at Linaro Connect SAN19 `_ - diff --git a/current/remoteproc.rst b/current/remoteproc.rst deleted file mode 100644 index 3abbd17..0000000 --- a/current/remoteproc.rst +++ /dev/null @@ -1,40 +0,0 @@ -==================== -Remoteproc Sub-Group -==================== - -Introduction ------------- - -Bill to revise summary about this group The OpenAMP remoteproc sub-group (A.K.A. "OpenAMP Classic") works on the original parts of OpenAMP, focusing on open-amp, libmetal, remoteproc, rpmsg, virtio. - -Communications --------------- -Mailing list -~~~~~~~~~~~~ - -We have a Mailman list for OpenAMP Remoteproc sub-group discussions. You can find info about it, reach the link to the archives, and subscribe/unsubscribe `here `_. - -Meetings -~~~~~~~~ - -Check out the meeting notes for the OpenAMP Remoteproc meetings on the :ref:`OpenAMP Meeting Notes page`. The cadence is every 2 weeks on Thursday mornings at 11am Eastern Time. Join the openamp-rp mailing list (see above) for the latest about the upcoming calls. - -Documentation -------------- -Placeholder for Bill to populate -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Placeholder for other documentation here - -OpenAMP Introduction from Linaro Connect HKG18 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Slides_ - -.. _Slides: http://connect.linaro.org.s3.amazonaws.com/hkg18/presentations/hkg18-411.pdf - -Future work ------------ - -Check out the future work list for the OpenAMP Remoteproc sub-group in the :ref:`future-remoteproc-work-label` section. - diff --git a/current/system_reference.rst b/current/system_reference.rst deleted file mode 100644 index a6259a6..0000000 --- a/current/system_reference.rst +++ /dev/null @@ -1,53 +0,0 @@ -=============================================== -System Reference / End-to-End Example Sub-Group -=============================================== - -What is OpenAMP System Reference / End-to-end example? ------------------------------------------------------- - -This working group aims to put together end-to-end system reference material showcasing all the different aspects of OpenAMP, on multiple vendor platforms. - -Communications --------------- - - - To sign up for the mailing list and to see the archives, visit `this page `_ BROKEN LINK - - Meetings: Small group who is working on the project is meeting meeting weekly on Wednesday during Aug-Oct 2021 & then will decide on frequency. - * Reach out on the `Mailing list `_ BROKEN LINK if you need info about this. - * :ref:`Project Meeting Notes` - -Repository ----------- - -`GitHub repository openamp-system-reference `_ - -Documentation -------------- - -WIP documentation folder on `Google Drive `_ (Note: Google doc access is currently restricted to working group members. Will publish documents once they are sufficiently ready) - -Samples and demos ------------------ - -Please refer to :ref:`Samples and demos page`. - -Milestones ----------- - -Future work ------------ - -Efforts -~~~~~~~ - - - Baremetal-baremetal - - RTOS-RTOS - -High level plan for Xilinx Software Stack -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - - QEMU & initial doc – Mid Sept. - - Userspace & kernel space demos – Sept end - - Hardware demo – End - Oct. - - System-dt flow (Without using Xilinx tools) – End-Nov - - Advanced app – End-Jan - - Completely upstream flow – (Based on When Xilinx driver is merged in upstream kernel) diff --git a/demos/inter_process.rst b/demos/inter_process.rst index f85389f..7b98da8 100644 --- a/demos/inter_process.rst +++ b/demos/inter_process.rst @@ -4,7 +4,7 @@ Running Demos as Processes on Linux =================================== -The `OpenAMP project examples `_ +The `OpenAMP project examples `_ are intended to execute on the remote of a reference board but can also be demonstrated by implementing as a process on the main controller, effectively emulating a remote. This can be useful for demonstration purposes, but can also be leveraged for component testing, even as part of a continuous integration setup. diff --git a/demos/reference_boards.rst b/demos/reference_boards.rst index 89e5b3b..d233413 100644 --- a/demos/reference_boards.rst +++ b/demos/reference_boards.rst @@ -12,4 +12,5 @@ In general the OpenAMP feature being exemplified is found in the `OpenAMP source docker_images system_reference-AMD-Xilinx system_reference-ST + system_reference-NXP inter_process diff --git a/demos/rpmsg_multi_services.rst b/demos/rpmsg_multi_services.rst index 9b5b7ed..77bdd08 100644 --- a/demos/rpmsg_multi_services.rst +++ b/demos/rpmsg_multi_services.rst @@ -157,3 +157,7 @@ This RPMsg Multi Services Sample is demonstrated in the following reference impl * Refer to `Zephyr Build Instructions `_. * Refer to `example demo script `_. + +* :ref:`NXP ` + + * Refer to Application Note `AN13970 Running Zephyr RTOS `_ diff --git a/demos/system_reference-NXP.rst b/demos/system_reference-NXP.rst new file mode 100644 index 0000000..c247f1a --- /dev/null +++ b/demos/system_reference-NXP.rst @@ -0,0 +1,13 @@ + + +.. _reference_board_NXP: + +==================== +NXP Reference Boards +==================== + +A number of the `OpenAMP project examples `_ can be executed on NXP Reference boards. + +* NXP `8MPLUSLPD4-EVK `_. + +The `AN13970 Running Zephyr RTOS on Cadence Tensilica HiFi 4 DSP `_ application note provides instructions for setting up the evaluation board. diff --git a/future/device_tree.rst b/future/device_tree.rst deleted file mode 100644 index 326a098..0000000 --- a/future/device_tree.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _future-device-tree-work-label: - -======================================== -System Device Tree Sub-Group Future Work -======================================== - -2019-10-17 - This list (to be populated) covers topics for the OpenAMP System Device Tree sub-group to discuss what to work on at their sub-group meetings. This sub-group welcomes participants from other areas of Device Tree beyond OpenAMP as well, such as DeviceTree.org, Device Tree Evolution projects. OpenAMP Project is hosting this discussion because of its cross-functional nature. \ No newline at end of file diff --git a/future/hardware_description.rst b/future/hardware_description.rst deleted file mode 100644 index 35d03c6..0000000 --- a/future/hardware_description.rst +++ /dev/null @@ -1,29 +0,0 @@ -==================== -Hardware Description -==================== - -Problems --------- - - - Need to communicate HW details (addresses, topologies, …) to SW subsystems during build - * Both at system level (complete HW including all CPUs) and subsystem level - * Tool to create subsystems with assigned devices out of system level info - - Need to communicate HW details during runtime - * Device trees used by Linux, Xen, etc. - * How to communicate to coprocessors (remoteproc) what devices it has? - - Need tools to create static config data (#defines, .h, .c files) from HW description - * Zephyr working on this. Need general solution. - - Need compact format for runtime use cases - * DTB is not very compact. Using strings instead of labels, no compression - -Potential solutions -------------------- - - - Come up with standard, humanly readable, HW description format for usage during build - * Possible candidates include extended Device Trees, IPExact, … - * A “System Level Device Tree” would add another level with multiple CPUs and mappings - - Come up with standard compressed HW description - * Potential candidate is CBOR - -Others interested in this problem? ----------------------------------- \ No newline at end of file diff --git a/future/hmm.rst b/future/hmm.rst deleted file mode 100644 index c738034..0000000 --- a/future/hmm.rst +++ /dev/null @@ -1,22 +0,0 @@ -===================================== -HMM (Heterogeneous Memory Management) -===================================== - -Use Cases ---------- - - - pcie/ccix endpoint side memory pools - - embedded soc e.g. dedicated media buffer alloc pool - -zone device and memory hotplug (on arm64) ------------------------------------------ - - - arch pte devmap bit options (mair bits, pte_none?, pte_special?) - - device pluggable private and public memory - -hmm address space mirroring w/ rproc ------------------------------------- - - - tie into vfio-map shmem model w/ remoteproc instances? - - could we somehow do better than dma migration w/ pgtable remapping? - - (opt.) tie into vfio-bind shmem model needs intg. iommu fault handling diff --git a/future/hypercalls.rst b/future/hypercalls.rst deleted file mode 100644 index 9b9db20..0000000 --- a/future/hypercalls.rst +++ /dev/null @@ -1,5 +0,0 @@ -================================== -Standardizing Hypercalls Sub-Group -================================== - -2019-10-17: This list (to be populated) covers topics for the OpenAMP Standardizing Hypercalls (sub-group to decide what name they want to use) sub-group to discuss what to work on at their sub-group meetings. \ No newline at end of file diff --git a/future/index.rst b/future/index.rst deleted file mode 100644 index 0760451..0000000 --- a/future/index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. OpenAMP documentation master file, created by - sphinx-quickstart on Wed Oct 5 10:21:26 2022. - You can adapt this file completely to your liking, but it should at least - contain the root `toctree` directive. - -Future Work -=========== - -.. toctree:: - :maxdepth: 1 - :caption: Contents: - - remoteproc - services - device_tree - hypercalls - hmm - hardware_description - diff --git a/future/remoteproc.rst b/future/remoteproc.rst deleted file mode 100644 index b334e46..0000000 --- a/future/remoteproc.rst +++ /dev/null @@ -1,232 +0,0 @@ -.. _future-remoteproc-work-label: - -================================ -Remoteproc Sub-Group Future Work -================================ - -This list (needs update) covers topics for the "OpenAMP remoteproc" sub-group to discuss and work on. This sub-group covers areas such as remoteproc, rpmessage, virtio, big buffers, etc. - -The sections below should include an short abstract and links to prior discussion etc. More detailed information should be added on a new wiki page and a link to that page should be added to the topic here. - -HW description (Xilinx, TI, ST, Mentor) ---------------------------------------- - - - How to describe HW to System SW – Complete HW vs. OS centric subsystems – DT, IPExact. More info can be found here. - - Q: 2019/11/7, Is this the same as SystemDT and should be moved to that group, or are there rp specific topics? - -System Resource Management – (ST, Xilinx, TI, Cypress) ------------------------------------------------------- - - - How to configure and assign resources and peripherals to coprocessors - - Complications include clock and power domain control, system firewall and/or IOMMU configuration - - Some of this gets easier if both Linux and the remote processor are using a central system controller for clock. power, and peripheral access control like SCMI or TISCI - -OpenAMP project support for Virtio spec (Xilinx, TI, ST, Mentor) ----------------------------------------------------------------- - - - Packed vrings, indirect descriptors, … - - Virtio device handshake improvements - - Use of existing virtio drivers (ex: virtblk, virtnet, virtcon) from remoteprocs - * remoteproc could be frontend or backend (ex:could be the block user or block device) - * Q: 2019/10/7, should this be its own topic and leave this one to be just virtio mechanics? - -Remoteproc Virtio driver ------------------------- - -Remoteproc framework is covering coprocessor management (init, load, start, stop, crash, dump...), but also provides functions for vring support. That complicates the device management, mainly the parent/child relation and the memory region assignment. Idea is to create a virtrproc like virtmem or virtcon and rely on DT definition for driver probing. - - - ST has some patches to share - -Big data – (Xilinx, TI, ST) ---------------------------- - - - Rpmsg buffer management - - Zero copy and big buffer - - Heterogeneous Memory Management. More info can be found here BROKEN LINK - - libmetal shared memory allocation: https://github.com/OpenAMP/libmetal/issues/70 - - sub topics include allocation, mapping, IOMMU, remoteproc MMU, cache maintenance, address translation - - DMA-BUF heaps seems to be the obvious choice for allocation API now - -Kernel remoteproc CI patches - Loic ------------------------------------ - -The rate of remoteproc/rpmsg patch review/acceptance seems slow, what can we do to accelerate it? This page has a lot of stuff (and there is a lot more waiting as 2nd tier of features). (This is not about maintainer bashing; it is about working better together.) - - - more mailing list discussion - * patch review should be done on kernel rpmsg list not openamp-rp list - * openamp-rp list can be used for broader arch discussion and Linux/RTOS interaction - - more reviewed by/acked by/tested by cooperation - - remoteproc CI loop should help - -OpenAMP kernel staging tree - Bill ----------------------------------- - - - Create an OpenAMP github repo for linux to collect all carried and WIP patches in one place - - This is not to create a product, it is to more easily see what problem everyone is working around - - Suggestion is to have a branch per vendor where they collect all the remoteproc related patches as a rebase branch - - Extra: Some have suggested trying to merge all the vendor work together ahead of getting to mainline - * However this step seems controversial, lets not focus on that, at least for now - - Alternative: just collect a list of links to the vendor trees - * This is definitely easier but it can be a lot of work to find the relevant patches - -Remoteproc/rpmsg CI & regression test – (Xilinx, TI, ST) --------------------------------------------------------- - -Create a CI environment that can build both RTOS and Linux side and test existing and new operations. - - - QEMU based AMP SOC highly desired as target - - Should be usable in cloud CI (travis etc) and on individual developers desktop - - V0.1: Start with QEMU fork and any publicly reproducible build - - V1: Add build flow for easy developer mode - - Expand to board farm as second phase - - Nice to have: use upstream QEMU - -There is a Docker container (work in process), that runs an instance of Xilinx QEMU that supports up to 4 A-53 cores and 2 R5 cores. This boots Linux, loads the firmware into the R5 via remoteproc, and can run the OpenAMP rpmsg echo test. https://hub.docker.com/repository/docker/edmooring/qemu - -Secure coprocessor support – Loic ---------------------------------- - -Add a generic rproc driver to support secure and isolated coprocessor thanks to some trusted services based on OPTEE or other Trusted OS. Standard flow will be to load coprocessor firmware and its associated signature somewhere in secure/non-secure shared memory and then to request secure world to load, authenticate coprocessor image and then start coprocessor Some tasks: - - - Define a standard file format for firmware to authenticate (is ELF still relevant or should we rely on PKCS11 header like to integrate signature ?) - - Define TA API to control secure coprocessor (load, start, stop...) - - How to manage resource table in that case? Should we rely on some secure services or should we consider it as input for communication link (aka rpmsg) configuration between coprocessor and Linux kernel (and in that case could stay non-secure) - - Q: Can we make this generic enough to be used when coproessor is to be owned/trusted by a hypervisor instead of the secure world - -Linux RPMSG only mode - Bill (TI,) ----------------------------------- - -RPMSG should be usable in the Linux kernel when Linux will never be the life-cycle manager for that coprocessor. - -In many modern systems the Linux kernel is not the most trusted entity in the system. Sometimes a given coprocessor is loaded and managed by another entity that is more secure (ex: secure world), more safe (ex: dual lock-set R5), or more trusted (hypervisor). In these system Linux may never be the one that loads/starts/restarts/crash dumps the coprocessor but Linux still needs to use a rpmsg channel and perhaps other virtio based communication channels. - - - Need to tell remoteproc that it is not the controller - - Need to find the resource table in use - - remoteproc still needs to do: IOMMU mapping, PA to DA, etc - - Q: Can we make a generic remoteproc that is usable for this case that can handle some (but not all) SOCs? - - This model brings up many cases for robustness - -RPMSG robustness - Bill (TI,ST) -------------------------------- - - - If coprocessor goes down and comes backup, Linux needs to recognize that and re-establish rpmsg communication - - If Linux goes down (crash/shutdown) and restarts while the coprocessor stays running, coprocessor needs to recognize that and re-establisg rpmsg communication - - The restart should be advertised to the applications not hidden from them. Applications should take recovery actions themselves. - * On Linux this would probably mean an error code from the existing handle and a need to open a new one (or a issue a reset ioctl) - -Early coprocessor boot – late attach, detach - Loic (ST,TI) ------------------------------------------------------------ - -Late attach is different from rpmsg only mode in that once Linux comes up, it becomes the life cycle controller for the coprocessor. - - - Linux should have the option to stay with the firmware already loaded on the coprocessor. - - Linux could later stop or reload the coprocessor with different firmware - - Linux may take ownership of crashdump and debug logs - - Late attach could require that matching firmware file exists in the filesystem, this would make finding the resource table easier - - Or late attach could require to know where firmware resource table has previously been loaded as would be required in RPMSG only mode - -Detach means that Linux stops becoming the life cycle owner. This could happen while Linux is running or as part of Linux crash/shutdown. - -Early booted processor patch sent on ML: https://lore.kernel.org/patchwork/patch/1147726/ - -Lifecycle management and Trusted & Embedded Base Boot Requirement (T/E-BBR) – Etsam ------------------------------------------------------------------------------------ - -Lifecycle management with Linux remote – Etsam ----------------------------------------------- - -The life cycle management of Linux is required in scenarios where it provides the rich execution environment and certified software environment (e.g on low end CPUs such as cortex M or R) is the system master and responsible to start/stop/recover Linux. The intent here is to cover the driver architecture (e.g. remoteproc replacement ) and device tree bindings for remote Linux. No plan to cover the Linux bootstrapping and RPMSG remote mode operation. They can be treated as separate topics. Linux will still assumed to be the RPMsg master. - -Rpmsg protocol documentation for remote – Etsam ------------------------------------------------ - -The RPMSG framework master side protocol is well manifested in Linux upstream and new masters (e.g. OpenAMP) can be written using it as a reference. However, there is no standard Doc/Implementation for remote which often leads to problematic protocol scenarios. For instance, consider the two cases below: - - - At what point VDEV Resource is initialized by the Master, specially when the vrings are dynamically allocated? - * Conversely, at what point remote should access that vdev resource? Consider the case where vdev resource is accessed by the remote right after boot up, assumption here is that it is initialized by the master before starting the remote. This worked for kernel v3.18 , however, it is broken for v4.9 (may be for others as well) where the vring addresses are populated after remote is booted. For latter, this leads to race condition and sometimes remote ends up accessing uninitialized vdev resource. Apparently, the correct point to access vdev resource is after vdev status field (DRIVER_OK) is updated by the master. - - When to send the Name service announcement? - * In response to first kick from the master: This works if remote is up and running. What if kick is sent and remote is not yet operational? It will miss the kick and consequently NS will not be sent. - * In response to VDEV status update (DRIVER_OK). Will work if remote comes up after the first kick. The status will still be in the shared memory and can be used to send the NS. - -The foolproof approach would be to use both kick and VDEV status to send the NS. This point was found after trial and error. - -It is required to document all such scenarios i.e. all master actions and expected response from the remote, to enable seamless operation with different remotes. - -MCU – MCU issues, rpsmg only - Mark ------------------------------------ - - - libopenamp example of rpmsg only - * Does it exist, are there any remaining issues? - * target for CI loop - * how big is it? Measure as regression test - - MCU boot first - late-attach - * Crash recovery - - Are there MISRA issues with libopenamp? - * Is malloc required? Can this be easily mapped to something more static - - "Big" Data in context of MCU to MCU (same SOC) - * zero-copy? - - OpenAMP improvement - * Libmetal rework to be continued - * Integrates last feedbacks coming from Nordic benchmark - * Reduce memory footprint - * Stack usage - - rpmsg-lite: anything missing from libopenamp? - -64 bits support - Clément -------------------------- - - - 64 bits support in elf file, see https://patchwork.kernel.org/patch/11175161/ - * Elf 64 files are needed for 64 bits processors - - 64 bits addresses in resources table - * Currently, addresses are only on 32bits, this is really limitating for 64bits - - 64 bits features in vdev declaration - * Virtio Features are now using 64 bits. Without this support, we are tied to legacy 32bits features. - * Need to switch to at least 64 bits and provisioned more bits for future evolution - -Misc I/O over VirtIO/RPMSG - Loic, Bill ---------------------------------------- - - - Put the "IO" in VirtIO - - Virtual UART - * ST has patches - * should this be full UART control (baud rate, HW flow control, RI/DCE/DTE/CTS/RTS) or just a communication channel - * Is Linux the device or the user? - * example: MCU wants to send console messages to Linux for logging - * example: MCU owns a physical UART but wants Linux to use it. - - Virtual I2C - * ST has some patches - * exmaple: MCU owns phy I2C with multiple devices, presents virtual I2C for to Linux so it can use some but not all of the devices - - Virtual SPI - * ST has some patches - - Virtual GPIO - - Virtual register bank - * via: regmap - * Can be used on its own or as the base level of some of the above (GPIO seems obvious) - - Should these be over RPMSG, direct over virtio, or both? - -Reference: ST Presentation at ELC-E 2019, https://elinux.org/images/6/63/ELC_EU19_rpmsg.pdf - -Improve Coprocessor debug capabilities - Loic ---------------------------------------------- - -Today rproc framework offers access to a virtual trace file (circular buffer filed by coprocessor) which limit coprocessor debug capabilities. Tracks to explore: - - - How to store coprocessor traces in a log file (syslog like) to improve trace depth? - - How to get same timestamp between Linux and coprocessors to correlate trace - - How to control coprocessor debug infrastructure (coresight?) - - Is it possible to debug coprocessor firmware thanks to GDB/GDB server over rpmsg or mailbox? - - How to avoid clashing with external JTAG debugger (RPMSG only mode may help here) - -Past presentations and TODO lists -================================= - - - TI presentation on TODO list from 2017 - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2017/OpenAMP-TI-Roadmap.pdf - - ST presentation from 2018 on short term TODO list - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2018hkg/OpenAMP-short-term-topcis-st.pdf - - Xilinx presentation from 2017 on Intro - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2017/OpenAMP-Intro-Feb-2017.pdf - - TI presentation from 2018 on Big Data and robustness, IPC only and life cycle - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2018hkg/OpenAMP-Buffer-Exchange.pdf - - TI presentation from 2017 on coprocessor memory types and howto handle - * https://github.com/OpenAMP/openamp.github.io/blob/master/docs/linaro-2017/OpenAMP-memory-types.pdf diff --git a/future/services.rst b/future/services.rst deleted file mode 100644 index f581921..0000000 --- a/future/services.rst +++ /dev/null @@ -1,7 +0,0 @@ -.. _future-services-work-label: - -=========================================== -Higher Level Services Sub-Group Future Work -=========================================== - -2019-10-17 - This list (to be populated) covers topics for the OpenAMP Higher Level Services (sub-group to decide what name they want to use) sub-group to discuss what to work on at their sub-group meetings. This sub-group covers areas such as Proxy, eRPC, WindRiver islet. \ No newline at end of file diff --git a/index.rst b/index.rst index 8d850f1..b41a399 100644 --- a/index.rst +++ b/index.rst @@ -16,6 +16,7 @@ Welcome to the OpenAMP Project Documentation tools/index protocol_details/index docs/index + openamp/glossary Indices and tables ================== diff --git a/openamp/contributing.rst b/openamp/contributing.rst index dacbf44..6abd571 100644 --- a/openamp/contributing.rst +++ b/openamp/contributing.rst @@ -4,6 +4,8 @@ Contributing to the OpenAMP Project =================================== +If you want to contribute and port OpenAMP to your platform read more about OpenAMP porting :ref:`here`. + Release Cycle ------------- - Release branch (feature freeze) cut 1 month before release target diff --git a/openamp/glossary.rst b/openamp/glossary.rst new file mode 100644 index 0000000..892d092 --- /dev/null +++ b/openamp/glossary.rst @@ -0,0 +1,22 @@ +======== +Glossary +======== + +.. csv-table:: Glossary + :header: "Acronym", "Description" + :widths: 20, 200 + + AMP, `Asymmentric Multiprocessing `_ + API, Application Interface + GPL, `GNU General Public License `_ + IPC, `Inter-Processor Communications `_ + LCM, Life-Cycle Management + OALK, OpenAMP Linux Kernel + OAOS, `OpenAMP Open Source Project `_ + OAPI, OpenAMP Proprietary Implementations + RPC, :ref:`Remote Procedure Calls (RPC)` + RTOS, Real Time Operating System + RPMsg, `Remote Processor Messaging `_ + SMP, `Symmetric Multiprocessing (SMP) `_ + SoC, System on Chip + Virtio, Virtual Input Output diff --git a/openamp/overview.rst b/openamp/overview.rst index c7e123b..277a0a6 100644 --- a/openamp/overview.rst +++ b/openamp/overview.rst @@ -8,28 +8,37 @@ OpenAMP Intro `Asymmetric Multiprocessing (AMP) `_ involves the management, control and communication of multi-core computer systems, where processors have independent tasks and are often in a `heterogeneous `_ embedded environment where there are different types of processors. This is in contrast to `Symmetric Multiprocessing (SMP) `_ which involves central control and load sharing using identical processor cores and is common place in servers and desktop computers. -The **OpenAMP** project is a community effort that is standardizing and implementing how these multiple embedded systems interact with each other in an AMP environment. It provides conventions and standards as well as an open source implementation to facilitate AMP development for embedded systems. +The **OpenAMP** project is a community effort that is promoting and implementing how these multiple embedded systems interact with each other in an AMP environment. It provides conventions and open source implementation to facilitate AMP development for embedded systems. The vision is that regardless of the operating environment/operating system, it should be possible to use identical interfaces to interact with other operating environments in the same system. -Furthermore, these operating environments can interoperate over a standardized protocol, making it possible to mix and match any two or more operating systems in the same device. +Furthermore, these operating environments can interoperate over a common protocol, making it possible to mix and match any two or more operating systems in the same device. Read more about Asymmetric Multiprocessing :ref:`here`. +******* +History +******* + +Texas Instruments’ remoteproc and RPMsg infrastructure available in the upstream Linux kernel enable the Linux applications running on a host processor to manage the life cycle of remote processor/firmware and perform IPC with them. However, there was no open- source API/software available that provided similar functionality and interfaces for other possible software contexts (RTOS- or bare metal-based applications) running on the remote processor to communicate with the Linux host. Also, AMP applications may require RTOS- or bare metal-based applications to run on the host processor and be able to manage and communicate with various software environments (RTOS, bare metal, or even Linux) on the remote processor. + +The OpenAMP Framework fills these gaps. It provides the required LCM and IPC infrastructure from the RTOS and bare metal environments with the API conformity and functional symmetry available in the upstream Linux kernel. As in upstream Linux, the OpenAMP Framework's remoteproc and RPMsg infrastructure uses virtio as the transport layer/abstraction. + + ************ Project Aims ************ To provide a solution to cover the :ref:`AMP Fundamentals`, the OpenAMP project is divided into the following efforts: - * A standardization group under Linaro Community Projects - - Standardizing the low-level protocol that allows systems to interact (:ref:`more info here`) - + Built on top of the `Virtio Open Standard `_ - - Standardizing on the user level APIs that allow applications to be portable + * A guidance group under Linaro Community Projects + - Provides guidance for the low-level protocol that allows systems to interact (:ref:`more info here`) + + Built on top of the `Virtio Open Standard `_ + - Maintaining common user level APIs that allow applications to be portable + :ref:`RPMSG` + :ref:`remoteproc` - - **Standardizing on the low-level** :ref:`OS/HW abstraction layer` **that abstracts the open source implementation from the underlying OS and hardware, simplifying the porting to new environments** + - **Provide low-level** :ref:`OS/HW abstraction layer` APIs **that abstracts the open source implementation from the underlying OS and hardware, simplifying the porting to new environments** * An open source project that implements a clean-room implementation of OpenAMP - Runs in :ref:`multiple environments` @@ -152,9 +161,9 @@ RemoteProc RPMsg and Virtio ================ -Standardization of the IPC is promoted by the OpenAMP project through the use of :ref:`RPMsg `, using `Open Standard Virtio Devices `_ as a HW abstraction or MAC layer. +Standardization of the IPC is promoted by the OpenAMP project through the use of :ref:`RPMsg `, using `Open Standard Virtio Devices `_ as a HW abstraction or MAC layer. -This abstraction, using virtio, means that the implementer can optionally use :ref:`resource isolation` (e.g. using a hypervisor or secure context), which is exemplified by the first processor in the architecture diagram. The other two remotes are in what is referred to as a hypervisorless-virtio setup because they are using virtio (virtual io) as an abstraction layer but without a hypervisor. +This abstraction, using virtio, means that the implementer can optionally use :ref:`resource isolation` (e.g. using a hypervisor or secure context), which is exemplified by the first processor in the architecture diagram. .. image:: ../images/architecture/overview-architecture-rpmsg.svg @@ -195,7 +204,7 @@ OpenAMP aims to provide components which are portable and aim to be environment The result is that OpenAMP is supported in various operating environments through - an `OpenAMP open source project `_ (OAOS), - - a Linux kernel project (OALK), coming through the regular `remoteproc `_/`RPMsg `_/`Virtio `_ efforts in the kernel. + - an OpenAMP Linux Kernel (OALK) project, coming through the regular `remoteproc `_/`RPMsg `_/`Virtio `_ efforts in the kernel. - multiple proprietary implementations (OAPI). The operating environments that OpenAMP supports include: @@ -220,12 +229,10 @@ There are a few guiding principles that governs OpenAMP: - Provide a clean-room implementation of OpenAMP with business friendly APIs and licensing * Allow for compatible proprietary implementations and products - Base as much as possible on existing technologies/open source projects/standards - * In particular :ref:`remoteproc`, :ref:`RPMsg ` and virtio + * In particular :ref:`remoteproc`, :ref:`RPMsg ` and `virtio `_ - **Never standardize on anything unless there is an open source implementation that can prove it** - Always be backwards compatible (unless there is a really, really good reason to change) - * In particular make sure to be compatible with the Linux kernel implementation of :ref:`remoteproc`/:ref:`RPMsg `/virtio + * In particular make sure to be compatible with the Linux kernel implementation of :ref:`remoteproc`/:ref:`RPMsg `/`Virtio `_ There are a number of project members as outlined in `OpenAMP Project Page `_ as well as many community members, so please join the :ref:`OpenAMP open source project`! - See https://github.com/OpenAMP/open-amp - -If you want to contribute and port OpenAMP to your platform read more about OpenAMP porting :ref:`here`. diff --git a/protocol_details/components.rst b/protocol_details/components.rst index adcd322..1f9b5c2 100644 --- a/protocol_details/components.rst +++ b/protocol_details/components.rst @@ -20,15 +20,6 @@ The key components, and the capabilities they provide, of the OpenAMP Framework remoteproc, This component allows for the Life Cycle Management (LCM) of remote processors from software running on a host processor. The remoteproc API provided by the OpenAMP Framework is compliant with the remoteproc infrastructure present in upstream Linux 3.4.x kernel onward. The Linux remoteproc infrastructure and API was first implemented by Texas Instruments. RPMsg, The RPMsg API enables `Inter Processor Communications (IPC) `_ between independent software contexts running on homogeneous or `heterogeneous `_ cores present in an AMP system. This API is compliant with the RPMsg bus infrastructure present in upstream Linux 3.4.x kernel onward. The Linux RPMsg bus and API infrastructure was first implemented by Texas Instruments. - -******* -History -******* - -Texas Instruments’ remoteproc and RPMsg infrastructure available in the upstream Linux kernel enable the Linux applications running on a host processor to manage the life cycle of remote processor/firmware and perform IPC with them. However, there was no open- source API/software available that provided similar functionality and interfaces for other possible software contexts (RTOS- or bare metal-based applications) running on the remote processor to communicate with the Linux host. Also, AMP applications may require RTOS- or bare metal-based applications to run on the host processor and be able to manage and communicate with various software environments (RTOS, bare metal, or even Linux) on the remote processor. - -The OpenAMP Framework fills these gaps. It provides the required LCM and IPC infrastructure from the RTOS and bare metal environments with the API conformity and functional symmetry available in the upstream Linux kernel. As in upstream Linux, the OpenAMP Framework's remoteproc and RPMsg infrastructure uses virtio as the transport layer/abstraction. - ********** Topologies ********** diff --git a/protocol_details/rpmsg_protocol.rst b/protocol_details/rpmsg_protocol.rst index fb85709..ee344e1 100644 --- a/protocol_details/rpmsg_protocol.rst +++ b/protocol_details/rpmsg_protocol.rst @@ -27,7 +27,7 @@ This layer is the key part of the whole solution - thanks to this layer, there i This technique is however applicable only in core-to-core configuration, not in core-to-multicore configuration, since in such a case, there would be multiple writers to the “IN” ring buffer. This would require a synchronization element, [such as a semaphore?], which is not desirable. -The above shown picture describes the vring component. The Vring is composed of three elementary parts - buffer descriptor pool, the “available” ring buffer (or input ring buffer) and the “used” ring buffer (or free ring buffer). All three elements are physically stored in the shared memory. +The above shown picture describes the vring component. The Vring is composed of three elementary parts - buffer descriptor pool, the available ring buffer and the used ring buffer. All three elements are physically stored in the shared memory. Each buffer descriptor contains a 64-bit buffer address, which holds an address to a buffer stored in the shared memory (as seen physically by the “receiver” or host of this vring), its length as a 32-bit variable, 16-bit flags field and 16-bit link to the next buffer descriptor. The link is used to chain unused buffer descriptors and to chain descriptors, which have the F_NEXT bit set in the flags field to the next descriptor in the chain. @@ -35,15 +35,17 @@ Note that the available and used ring buffer areas contain pointers to buffers, .. image:: ../images/vring_descriptor.jpg -The input ring buffer contains its own flags field, where only the 0th bit is used - if it is set, the “writer” side should not be notified, when the “reader” side consumes a buffer from the input or “avail” ring buffer. By default the bit is not set, so after the reader consumes a buffer, the writer should be notified by triggering an interrupt. The next field of the input ring buffer is the index of the head, which is updated by the writer, after a buffer index containing a new message is written in the ring[x] field. +The available ring buffer contains its own flags field, where only the 0th bit is used - if it is set, the “writer” side should not be notified, when the “reader” side consumes a buffer from the available ring buffer. By default the bit is not set, so after the reader consumes a buffer, the writer should be notified by triggering an interrupt. The next field of the available ring buffer is the index of the head, which is updated by the writer, after a buffer index containing a new message is written in the ring[x] field. -.. image:: ../images/vring_descriptor_flags.jpg +.. figure:: ../images/vring_descriptor_flags.jpg -The last part of the vring is the “used” ring buffer. It contains also a flags field and only the 0th bit is used - if set, the writer side will not be notified when the reader updates the head index of this free ring buffer. The following picture shows the ring buffer structure. The used ring buffer differs from the avail ring buffer. For each entry, the length of the buffer is stored as well. + Flags (16 bit) Fields of Available Ring Buffer Descriptor + +The last part of the vring is the used ring buffer. It contains also a flags field and only the 0th bit is used - if set, the writer side will not be notified when the reader updates the head index of this used ring buffer. The following picture shows the ring buffer structure. The used ring buffer differs from the available ring buffer. For each entry, the length of the buffer is stored as well. .. image:: ../images/vrings_used_buffers.jpg -Both “used” and “avail” ring buffers have a flags field. Its purpose is mainly to tell the writer whether he should interrupt the other core when updating the head of the ring. The same bit is used for this purpose in both “used” and “avail” ring buffers: +Both used and available ring buffers have a flags field. Its purpose is mainly to tell the writer whether he should interrupt the other core when updating the head of the ring. The same bit is used for this purpose in both used and available ring buffers: .. image:: ../images/vrings_used_buffers_flags.jpg