-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
OpenAMP support. #12961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenAMP support. #12961
Conversation
c2b907d
to
1510a92
Compare
Code size report:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #12961 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 161 161
Lines 21078 21079 +1
=======================================
+ Hits 20739 20740 +1
Misses 339 339 ☔ View full report in Codecov by Sentry. |
445328b
to
a9d3ea6
Compare
a043cd3
to
5bb1b02
Compare
1375bd0
to
1952b72
Compare
It would be really nice if we can update the CMSIS headers to support zero and copy tables, this way I can remove the function that initializes the shared resource table ( |
6f142f0
to
1eeb92e
Compare
1eeb92e
to
b7bce32
Compare
Note: I'm working on this PR and will merge it shortly. |
OpenAMP framework provides a standard inter processor communications infrastructure for RTOS and bare metal environments. There are 3 major components in OpenAMP: libmetal, remoteproc and RPMsg. libmetal provides abstraction of the low-level underlying hardware, remoteproc is used for processor Life Cycle Management (LCM) like loading firmware, starting, stopping a core etc., and RPMsg is a bus infrastructure that enables Inter Processor Communications (IPC) between different cores. Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
libmetal provides an abstraction of the underlying hardware, to support other OpenAMP components. Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
b7bce32
to
fbb0d60
Compare
I reviewed the commits again, everything seems to be in order. |
Add a MicroPython platform for libmetal, based on the generic platform. The MicroPython platform uses common mp_hal_xxx functions and allows ports to customize default configurations for libmetal. Signed-off-by: Jim Mussared <jim.mussared@gmail.com> Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
So there's only one location that does the ioctl(MP_STREAM_SEEK) call. Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
This module implements OpenAMP's basic initialization and shared resources support, and provides support for OpenAMP's RPMsg component, by providing an `endpoint` type (a logical connection on top of RPMsg channel) which can be used to communicate with the remote core. Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
RemoteProc provides an API to load firmware and control remote processors. Note: port-specific operations must be implemented to support this class. Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
fbb0d60
to
df2ff0c
Compare
Merged!! Thanks @iabdalkader for implementing this, I think it will be a great feature for multicore SoCs, of which there are more and more these days. |
This PR adds support for OpenAMP in MicroPython, with the goal of standardizing asymmetric multi-core support across different hardware running MicroPython. There are 3 major components to OpenAMP,
libmetal
,remoteproc
andRPMsg
.libmetal
provides abstraction of the low-level underlying hardware,remoteproc
is used for processor Life Cycle Management (LCM) (i.e loading firmware, starting, stopping a core etc..), andRPMsg
is a bus infrastructure that enables Inter Processor Communications (IPC) between different cores. These components are implemented in this PR as follows:OpenAMP's
libmetal
submodule is added in this PR (see note about this submodule), and a generic MicroPython system port is implemented, one that uses some sane defaults and commonmp_hal
functions, and also allows for MicroPython's ports to override defaults and configlibmetal
.OpenAMP's
remoteproc
component is implemented inextmod/modremoteproc.c
module which provides an API to load firmware and control remote processors. Port-specific ops must be implemented for this module (similar tompbthciport.c
ormpnetworkport.c
). One example is already done in this PR forstm32
.OpenAMP's
RPMsg
component and the rest of the logic is implemented inextmod/modopenamp.c
. This module provides anendpoint
type (a logical connection on top ofRPMsg
channel) that can be used to communicate with the remote core.Example: The following script loads a firmware image that implements a virtual uart over RPMsg channel, built for STM32H7's M4 core, starts it, and communicates with the M4 once the core is ready to communicate. The remote core becomes ready to communicate after the master/host core initializes a shared memory area, and it announces its readiness by creating a new RPMsg channel. At this point, the
ns_callback
is called, and the host processor creates an endpoint to communicate over that RPMsg channel. Note the firmware is parsed and loaded from anelf
file stored on the filesystem, I can share the source somewhere later as an example or for testing.Output:
The firmware running on the M4 can be found here: https://github.com/iabdalkader/openamp_vuart
Todo:
libmetal
it's basically impossible to add its upstream as a submodule, since it only supports cmake, and it hard-codesconfigure_file
variables into headers, and it's basically expected to be built into a static library and installed somewhere. So for now I've used my own fork, with minor changes to make it more "MicroPython-friendly". This library hardly changes, I think it would make sense to maintain our own fork, I can transfer ownership of thelibmetal
repo to MicroPython later if you want, I have no need to maintain it.