examples: Add support for baremetal R5 in the TI K3 family devices #15
Conversation
Adding baremetal support for the R5 to use RPMsg for the devices in the TI K3 family, specifically for the SK-AM64. Users should be able to replace memory addresses for the R5 in the linker_remote.ld file and platform_info.h files to make RPMsg compatible with the R5 in their chosen board. Cmake file was added to aid in building for the R5 in TI K3 family devices. Mailbox driver added to allow RPMsg to work with the TI K3 family devices. Other API files added to aid in interrupts and other board specific functions. IPI and no IPI is supported in the platform_info files to allow mailbox to kick RPMsg. Matrix multiply example is functional as a demo. Signed-off-by: Kendall Willis <kendallwillis@ti.com>
|
I think gitsubmodule could work here, the source of much of the BSP code is a github project here: https://github.com/TexasInstruments/mcupsdk-core This is a rather extensive project though, so much so it even includes our alternative implementation of what OpenAMP provides: Seems a bit like circular layering to require all that to get a baremetal OpenAMP demo working. Maybe we could add a message/mailbox framework to libmetal, then offload the mailbox/IRQ/memory drivers to libmetal. That also doesn't feel exactly right either as those drivers integrate tightly with the startup code. And the startup code would still live here and in the BSP repo. So we end up with all 3 projects circularly depending on each other.. |
| changed to | ||
| ``` | ||
| project (open_amp C ASM) | ||
| ``` |
There was a problem hiding this comment.
Is there any other way to achieve this without user manually modifying these files? If not I am okay with this.
| the examples/linux/rpmsg-mat-mul and examples/linux/common folders to | ||
| the host processor. | ||
|
|
||
| Find the R5_1 core 0 by searching dmesg. Then run |
There was a problem hiding this comment.
What is R5_1 ? Is it only R5 ?
There was a problem hiding this comment.
There are technically four R5 cores on the AM64 but they are implemented as two R5 modules that have a dual core implementation. So there is R5 module 0 with core 0 and core 1, and R5 module 1 with core 0 and core 1.
| ``` | ||
| $ cd rpmsg-mat-mul | ||
| $ make | ||
| $ ./mat_mul_demo.c |
There was a problem hiding this comment.
./mat_mul_demo binary only. Remove ".c"
Also, you may want to add instruction to copy over mat_mul_demo to board via ssh or some other way.
| @@ -0,0 +1,20 @@ | |||
| collect (APP_COMMON_SOURCES platform_info.c) | |||
There was a problem hiding this comment.
I am missing something here. Where is application code of matrix multiplication that will use this platform_info.c ? Is it being picked up from open-amp library ?
There was a problem hiding this comment.
The mention of the matrix multiplication is just to show a demo that OpenAMP works on the AM64. The matrix_multiplyd.out executable is from OpenAMP in the apps/examples/matrix_multiply folder. This is used for the remote R5. The matrix multiply example in this repository is used on the host A53.
Cleaned up comments in platform_info and helper. Updated the README. Updated the cmake to be able to find libmetal easily. Signed-off-by: Kendall Willis <kendallwillis@ti.com>
|
Hi, It seems to me that this example contains too many specific TI K3 baremetal files. I would expect something similar to the AMD/Xilinx implementation available at https://github.com/OpenAMP/open-amp/tree/main/apps. A minimum adaptation layer (i.e. platform_info.c) should be used, followed by a readme that explains how to import the platform-specific K3 baremetal environment." |
|
We did consider that option, but our hope was to remove the dependency on vendor projects as much as possible. When we first started evaluating OpenAMP one of the biggest hurtles was building these examples as they depend on AMD/Xilinx SDK components which we didn't want to pull into our project environment. Idea here is to have a complete buildable "system reference" that one could compile from only sources available here in the OpenAMP projects. Although these files are pulled from our TI PDK/MCU+ projects, they are (other than mailbox) generic to any R5 core. So the other plan was to factor those parts out into a baremetal base for any R5 users, even AMD/Xilinx could make use of, vs XIL_* dependencies. |
Having an independent system seems like a good idea at first glance. But if we add the other core listed in This is one reason why we use Zephyr in system reference. It provides the abstraction layer for the hardware. That's said, we have to discuss the approach we want to support for baremetal. It is a topic to add in the agenda of next system reference meeting |
I agree with @arnopo. It's just not about r5. It will be very hard to maintain BSP for all the supported processors. Instead for each processor we can have one or two files which is glue to the BSP, and it is upto vendors how they want to add BSP library. For example, they can statically link separate library or they can have gitsubmodule and sync source code from external repository etc... |
|
After discussions we have decided to re-work this PR based on changes to the project structure. Closing for now. EDIT: Just realized I cannot close this for Kendall, project owners please feel free to close this PR. |
Thanks for the information, I close it |
Adding baremetal support for the R5 to use RPMsg for the devices in the TI K3 family, specifically for the SK-AM64. Users should be able to replace memory addresses for the R5 in the linker_remote.ld file and platform_info.h files to make RPMsg compatible with the R5 in their chosen board. Cmake file was added to aid in building for the R5 in TI K3 family devices. Mailbox driver added to allow RPMsg to work with the TI K3 family devices. Other API files added to aid in interrupts and other board specific functions. IPI and no IPI is supported in the platform_info files to allow mailbox to kick RPMsg. Matrix multiply example is functional as a demo.