Add support for Zephyr's native test environment

[aescolar]

Zephyr's native test environment is a setup which allows building the embedded SW with the Zephyr OS and HW models as a Linux executable.

When building for this target the Zephyr integration will set the PROJECT_PROCESSOR as "zephyr_native".

We need to provide appropriate headers for this "processor".
The "metal_cpu_yield()" call, which in other architectures is handled as either a hint for the CPU to yield to another thread or do nothing, and therefore busy waiting, needs replacing with a call out to the Zephyr API which will cause the CPU to waste 1 microsecond, therefore enabling the other CPU in the system to ready whatever we are waiting for in the meanwhile.

[aescolar]

@arnopo I'm honestly not sure if this would be the best way to handle this, your feedback would be very welcome
CC @carlocaione

[arnopo]

I answered in zephyrproject-rtos/libmetal#19:

Seems to me not a platform but an option in the Zephyr build.

You could try to address this in this in https://github.com/OpenAMP/libmetal/blob/main/lib/system/zephyr
and perhaps in https://github.com/OpenAMP/libmetal/edit/main/cmake/options.cmake?

[wmamills]

I would really like to replace all these do nothing headers with a single copy of a generic version. For "cpus" where both files are do nothing they can just define cpu_generic or something like that.

For this case you have something real to do in cpu.h so the cmake can select the generic-atomic.h and you can have the real cpu.h below.

[aescolar]

I can do that in a separate commit if you want, though if you would not mind, maybe in a follow up PR after we agree this other matter, as it is a bit unrelated and I would prefer to not mingle things too much.

[aescolar]

Thanks @wmamills ,
note the discussion was happening in zephyrproject-rtos/libmetal#19
( I just updated this PR based on what was discussed there )

[aescolar]

@arnopo The PR has been updated as you requested in zephyrproject-rtos/libmetal#19
You are very welcome to take a look.

[arnopo]

Please could you re-base your PR on top of the main branch to fix CI issue

[arnopo]

The way of integrating it seems ok to me, I let other reviewers share their opinions

[aescolar]

Thanks @arnopo, corrections according to your feedback have been done.

[aescolar]

@arnopo & others, is there anything that should be different / that prevents this from being merged?

Background: This enables a new type of tests and way of developing for AMP scenarios for Zephyr, so there is quite a few people looking forward to it.

[arnopo]

Hi @aescolar,
I understand the frustration, but we are in the release process of the library. Therefore, today's code is frozen until the release at the end of the month. Moreover, to merge any new changes, we require two approvals from reviewers.
if it is blocker for Zephyr, we can have an exception in Zephyr libmetal module.
In such case refresh the PR in zephyrproject-rtos/libmetal#19 explaining the need

[aescolar]

Thank you very much for the consideration @arnopo . I set the PR in the zephyr module as ready, and provided the motivation in this comment: zephyrproject-rtos/libmetal#19 (comment)
Getting this changes in would be very nice.

[arnopo]

@wmamills, @tnmysh, @edmooring
Please Could you have a look?

[wmamills]

I still don't want to create yet another ALMOST do nothing "processor". Can we have a PR to do the generic files first and then this can use them. Instead of adding the fake "processor" and then removing it.

[aescolar]

@wmamills is something like this what you were hoping for?

---

A Zephyr CI run with the equivalent of this patch can be seen passing in
zephyrproject-rtos/zephyr#64674

[wmamills]

@aescolar Yes that look great! Lots of code deletion!
Let me pull it down and look more closely.

At libmetal I would like to land the commits in the other order: generic first and then Zephyr test env.
Do you want to do that or do you want me to do that (and give you credit)

Question: Is zephyr native posix always == test environment or are there some cases where you would not want the sleep for the yield?

[aescolar]

@wmamills Thanks

Question: Is zephyr native posix always == test environment or are there some cases where you would not want the sleep for the yield?

Native_posix/native_sim and the related targets are test/simulation/development environment.
We always want to sleep a little bit in this metal_cpu_yield() case.

[aescolar]

@wmamills are you happy enough with this PR as to approve it? :)

[wmamills]

@aescolar @arnopo yes I am OK with this and even in this order. I guess it make sense as this shows more linear history from a Zephyr POV.

[wmamills]

I approve

[aescolar]

Thanks guys :)