OpenAMP and Libmetal module: is it a way to directly import the external libraries?

[arnopo]

Some modules such as open-amp and libmetal are a simple fork of the original project with a adaptation glue for Zephyr.
Instead of making a copy/past/clean it seems interesting to be able to directly import the libraries, for instance using git submodule mechanism.

For instance in https://github.com/zephyrproject-rtos/open-amp, on each open-amp release, the code is copied from https://github.com/OpenAMP/open-amp in the open-amp folder after documentation and test clean-up.

In a basic repository adding a .gitmodules should do the job:

+[submodule "libmetal"]
+	path = libmetal
+	url = https://github.com/OpenAMP/libmetal

But Seems more tricky using west for the management of a zephyr module.

So any advice would be welcome!
Thanks in advances

[carlocaione]

I fully support this. Tagging @mbolivar-nordic

[mbolivar-nordic]

Hi, sorry, but I don't understand the request. However, west manifests do support pulling in git modules from projects. See https://docs.zephyrproject.org/latest/develop/west/manifest.html#git-submodules-in-projects. @arnopo is that what you are looking for? I assume no action is needed for zephyr/west.yml since open-amp is already pulled in as a module.

[arnopo]

Hi @mbolivar-nordic

let take the open-amp lib example.

In west .yml the open-amp is listed as a zephyr module: https://github.com/zephyrproject-rtos/zephyr/blob/main/west.yml#L195-L197
The Zephyr openamp repo is available here and contains:

• a readme file
• a CMakeLists.txt
• a zephyr folder in cluding a module.yml
• a open-amp folder that contains a copy of the https://github.com/OpenAMP/open-amp library.

The point is that there is no delta between the copy and the original. So, instead of making a copy for each version of openamp, it would be better to get the code directly from the https://github.com/OpenAMP/open-amp when the zephyr project is set and/or build.
The question is how to do this in a clean way in zephyr project?

[mbolivar-nordic]

The question is how to do this in a clean way in zephyr project?

I can't say what is "clean" and what isn't, but did you try making the open-amp library a submodule of the zephyr module, and using the submodules support already built into west using the docs I linked above?

[arnopo]

I had misunderstood the use of "submodules", I was looking for complexity where there is none.
I have done a quick test yesterday and seems to work,
Now I need to finalize the implementation and test it.
Thanks!

[arnopo]

Hi @mbolivar-nordic
I prototyped the solution on my github:
https://github.com/arnopo/zephyr_stm32mp1/tree/submodule
https://github.com/arnopo/libmetal-zephyr/tree/submodule
https://github.com/arnopo/open-amp-zephyr/tree/submodule

it is working fine but if someone want to update for instan the the https://github.com/OpenAMP/open-amp repo, he/she still need to fork the zephyrproject-rtos/open-amp and zephyrproject-rtos/libmetal repos in addition of the zephyr repo

So I would like investigate the possibility of suppressing zephyrproject-rtoss/open-amp and zephyrproject-rtos/libmetal repos.

The idea would be to create for instance an openamp folder in https://github.com/zephyrproject-rtos/zephyr/tree/main/modules that would contains the https://github.com/zephyrproject-rtos/open-amp/blob/master/CMakeLists.txt and https://github.com/zephyrproject-rtos/zephyr/blob/main/modules/Kconfig.open-amp

And then directly declare the https://github.com/OpenAMP/open-amp in west.yml.

Is it something that would be acceptable and feasible from you point of view?

To be honest I tried to prototype it but I'm facing issue saying:

warning: OPENAMP (defined at modules/openamp/Kconfig:7) was assigned the value 'y' but got the value
'n'. Check these unsatisfied dependencies: 0 (=n).

Thanks in advance for your feedback!
Arnaud

[mbolivar-nordic]

Hey, I am not sure what you are asking me from a west perspective. But this part I think is not acceptable:

And then directly declare the https://github.com/OpenAMP/open-amp in west.yml.

As a matter of policy, we only point to repositories in zephyrproject-rtos from zephyr/west.yml. You could set up an automated fork that kept the zephyrproject-rtos fork up to date with the main repository in OpenAMP.

Are you saying you've got the west parts working otherwise? I'm not totally clear on if you still need a west feature or not.

[arnopo]

Hey, I am not sure what you are asking me from a west perspective. But this part I think is not acceptable:

And then directly declare the https://github.com/OpenAMP/open-amp in west.yml.

As a matter of policy, we only point to repositories in zephyrproject-rtos from zephyr/west.yml. You could set up an automated fork that kept the zephyrproject-rtos fork up to date with the main repository in OpenAMP.

If I well understood such commit can not be uspreamed:
https://github.com/arnopo/zephyr_stm32mp1/commit/3d60e5549e6ecdc1ae31f8416483fe205f4930fa#diff-d7f4082837dc3cb270fcf1abd68188216fdadee294e01611b8ca59ddea7fdbb3R24-R25
as we add another remote, right?

Are you saying you've got the west parts working otherwise? I'm not totally clear on if you still need a west feature or not.

The prototype mentioned at thee beginning of #44279 (comment) is working. but this implies that if we want to fork Zephyr in OpenAMP for demos we need to fork zephyrproject-rtoss/open-amp and zephyrproject-rtos/libmetal modules repo.

that's why We are trying another approach that consists in suppressing the zephyrproject-rtoss/open-amp and zephyrproject-rtos/libmetal modules repo., and directly use the openAMP repos instead with west.
here is my POC for libmetal :
https://github.com/arnopo/zephyr_stm32mp1/commit/1834886f8d48bd00d4469a0ad7415235520764cd
it show help you to understand what i'm trying to do .
But as mentioned in previous comment I'm facing an issue. An if you confirm that the west.yml update proposed in the commit is not upstreamable I 'll need to come back to my first patches based on submodules

Thanks!

[mbolivar-nordic]

If I well understood such commit can not be uspreamed:
https://github.com/arnopo/zephyr_stm32mp1/commit/3d60e5549e6ecdc1ae31f8416483fe205f4930fa#diff-d7f4082837dc3cb270fcf1abd68188216fdadee294e01611b8ca59ddea7fdbb3R24-R25
as we add another remote, right?

Right, exactly.

it show help you to understand what i'm trying to do .

Ah, I see. Have you had a look here?

https://github.com/zephyrproject-rtos/zephyr/tree/main/submanifests

You can use a submanifest file to override libmetal in your zephyr fork more easily, avoiding merge conflicts when upstream west.yml changes. See the README in that link for more information.

An if you confirm that the west.yml update proposed in the commit is not upstreamable I 'll need to come back to my first patches based on submodules

That west.yml update is not upstreamable, no. If you require this exact commit in something you're upstreaming, you'll need to come up with a different approach.

[carlocaione]

tagging @stephanosio because this topic was discussed on another story

[arnopo]

Associated issue raised in OpenAMP: OpenAMP/open-amp#434