On 25/11/2023 17:41, Massimiliano Cialdi via Gcc-help wrote:
Hello,
I am engaged in a firmware project with Cortex-M microcontrollers, focusing
on implementing dynamic plugin functionality. My setup includes FreeRTOS,
LittleFS, and gcc-arm-none-eabi.
I'm exploring creating a dynamic linker/loader for plugins. My queries are:
1. *File Format and Loading:* Recommendations for file formats and
loading strategies in a dynamic linker/loader system?
2. *Function Entry Points:* Best practices for managing function entry
points in non-PIC firmware for plugins?
3. *Memory Management:* Managing different memory types (DTCM and SRAM)
for plugin code and data.
4. *Compilation and Linking:* Specific parameters or considerations for
compiling and linking, including post-linking steps.
5. *Security and Stability:* Ensuring safety and reliability when
loading plugins dynamically.
6. *Toolchain Adequacy:* Are the standard tools in the gcc-arm-none-eabi
toolchain sufficient for this task, or is there a need for third-party
tools or custom solutions?
Any advice, experiences, or references to similar projects would be
immensely helpful. Thank you!
best regards
You are going to find a number of limitations here, but it is all
workable. Traditionally link/loading involves changes to at least some
parts of the program image will loading, and that won't work since your
code will be fixed in flash, and not loaded into ram. So your key tool
is indirection tables. Your main code will provide a table of function
pointers at a fixed address in flash, for each of the services it
supports. Your plugin has a struct type declared that matches the
table, and accesses it through a cast pointer from this fixed address
(in the same way as it accesses hardware peripherals). You can have
small wrappers to make these indirect functions callable as normal
functions in your plugin code.
The service table here can also helpfully include other things like
version numbers, pointers to structs of data, etc. And it's also fine
to have another level of indirection with the fixed address holding a
pointer to this table rather than the table itself.
Similarly, the plugin will have a table of information and function
pointers at a fixed address (or indirectly via a pointer at a fixed
address).
This lets the main program and the plug access each other's services as
needed.
You don't need anything beyond the normal tools to make all this work.
It is not as scalable as a general dynamic library approach, but you
wouldn't want that anyway in a microcontroller setting. You want to
have fixed sizes for things as much as possible - such as saying the
main program gets the first 128 KB of DTCM and the plugin gets the other
128 KB (assuming that's the available sizes, as an example). I'd advise
against trying to be /too/ flexible - even if you are using something
like an NXP RT10xx device with run-time configurable choices of data and
instruction tightly coupled memory, pick one setting and stick to it.
Security is not an easy question to answer because it it is far too
dependent on circumstances and requirements. It should be perfectly
possible to have digital signatures included in the plugin's table and
let the main program check it. It is also possible to have the main
program run in privileged mode and the plugin in unprivileged mode, and
use the MPU to block the plugin from accessing some parts of memory and
peripherals. That does make things more complicated, however, since you
need to use software interrupts to jump to privileged mode, which is
less efficient than a simple indirect function call. And it can
complicate matters when using an RTOS that uses SWI to trigger the
scheduler.
It is all possible, and can be done mainly using standard development
tools. You might, however, find it helpful to have a bit of
post-processing of images - I personally use Python scripts to add
things like checksums to binary images, and maybe you'll need a bit of
that kind of thing. The details will depend a great deal on exactly
what you are trying to do, and as you are using FreeRTOS then you might
find it useful to look for information specifically from that direction.
I don't think this mailing list is the right place for such discussions,
however, since it is not a gcc-related issue. But I hope I've given you
a few helpful thoughts.
David
