Build machine-less libmetal #350

tnmysh · 2025-11-19T17:58:20Z

It is not required to have MACHINE variable defined for the libmetal project. As Vendors can choose to implement machine specific interfaces outside of the libmetal and link it build time with the demos.

Hence make MACHINE variable optional in the cmake build system.

tnmysh · 2025-11-19T18:05:56Z

@arnopo

I got report that 9f749f0 this change from 1.9.0 release, is causing build failures for xlnx platform. This PR is fixing that build issue.

What's best way to integrate changes in this PR? Should we make 1.9.1 or 2025.10.1 release? As the demos are not released yet, we can still upgrade minor version of the library with this fix.

tnmysh · 2025-11-19T18:46:15Z

The CI commands might need to be improved for this PR to pass:

cd /github/workspace/build-generic/lib && /usr/bin/arm-none-eabi-gcc -DDEFAULT_LOGGER_ON -DMETAL_INTERNAL -I/github/workspace/build-generic/lib/include -Wall -Werror -Wextra -MD -MT lib/CMakeFiles/metal-static.dir/dma.c.obj -MF CMakeFiles/metal-static.dir/dma.c.obj.d -o CMakeFiles/metal-static.dir/dma.c.obj -c /github/workspace/lib/dma.c
In file included from /github/workspace/build-generic/lib/include/metal/sys.h:85,
from /github/workspace/build-generic/lib/include/metal/io.h:22,
from /github/workspace/build-generic/lib/include/metal/device.h:16,
from /github/workspace/lib/dma.c:9:
/github/workspace/build-generic/lib/include/metal/system/generic/sys.h:27:10: fatal error: ./template/sys.h: No such file or directory
27 | #include "./template/sys.h"
| ^~~~~~~~~~~~~~~~~~

Since MACHINE is not mandatory anymore, may be we should explicitly pass it to build the library if needed.

arnopo · 2025-12-01T14:17:58Z

The CI commands might need to be improved for this PR to pass:

cd /github/workspace/build-generic/lib && /usr/bin/arm-none-eabi-gcc -DDEFAULT_LOGGER_ON -DMETAL_INTERNAL -I/github/workspace/build-generic/lib/include -Wall -Werror -Wextra -MD -MT lib/CMakeFiles/metal-static.dir/dma.c.obj -MF CMakeFiles/metal-static.dir/dma.c.obj.d -o CMakeFiles/metal-static.dir/dma.c.obj -c /github/workspace/lib/dma.c In file included from /github/workspace/build-generic/lib/include/metal/sys.h:85, from /github/workspace/build-generic/lib/include/metal/io.h:22, from /github/workspace/build-generic/lib/include/metal/device.h:16, from /github/workspace/lib/dma.c:9: /github/workspace/build-generic/lib/include/metal/system/generic/sys.h:27:10: fatal error: ./template/sys.h: No such file or directory 27 | #include "./template/sys.h" | ^~~~~~~~~~~~~~~~~~

Since MACHINE is not mandatory anymore, may be we should explicitly pass it to build the library if needed.

Hi @tnmysh : sorry for the late reply.

From my perspective the CI is good we specify the template machine in cmake/platforms/template-generic.cmake. The issue here is that the build-generic/lib/include/metal/system/generic/template folder is no more created.

Investigating the issue, it seems that it is coming from a syntax error in the PR

-if (DEFINED ${PROJECT_MACHINE})
+if (DEFINED PROJECT_MACHINE)
   add_subdirectory(${PROJECT_MACHINE})
-endif (DEFINED ${PROJECT_MACHINE})
+endif (DEFINED PROJECT_MACHINE)

tnmysh · 2025-12-02T15:24:05Z

The CI commands might need to be improved for this PR to pass:
cd /github/workspace/build-generic/lib && /usr/bin/arm-none-eabi-gcc -DDEFAULT_LOGGER_ON -DMETAL_INTERNAL -I/github/workspace/build-generic/lib/include -Wall -Werror -Wextra -MD -MT lib/CMakeFiles/metal-static.dir/dma.c.obj -MF CMakeFiles/metal-static.dir/dma.c.obj.d -o CMakeFiles/metal-static.dir/dma.c.obj -c /github/workspace/lib/dma.c In file included from /github/workspace/build-generic/lib/include/metal/sys.h:85, from /github/workspace/build-generic/lib/include/metal/io.h:22, from /github/workspace/build-generic/lib/include/metal/device.h:16, from /github/workspace/lib/dma.c:9: /github/workspace/build-generic/lib/include/metal/system/generic/sys.h:27:10: fatal error: ./template/sys.h: No such file or directory 27 | #include "./template/sys.h" | ^~~~~~~~~~~~~~~~~~
Since MACHINE is not mandatory anymore, may be we should explicitly pass it to build the library if needed.

Hi @tnmysh : sorry for the late reply.

From my perspective the CI is good we specify the template machine in cmake/platforms/template-generic.cmake. The issue here is that the build-generic/lib/include/metal/system/generic/template folder is no more created.

Investigating the issue, it seems that it is coming from a syntax error in the PR
-if (DEFINED ${PROJECT_MACHINE})
+if (DEFINED PROJECT_MACHINE)
   add_subdirectory(${PROJECT_MACHINE})
-endif (DEFINED ${PROJECT_MACHINE})
+endif (DEFINED PROJECT_MACHINE) 

@arnopo

For xlnx platform, we don't use template machine. In that case, how can we make sure not to enforce anything related to template machine?

Tanmay

arnopo · 2025-12-02T16:13:52Z

The CI commands might need to be improved for this PR to pass:
cd /github/workspace/build-generic/lib && /usr/bin/arm-none-eabi-gcc -DDEFAULT_LOGGER_ON -DMETAL_INTERNAL -I/github/workspace/build-generic/lib/include -Wall -Werror -Wextra -MD -MT lib/CMakeFiles/metal-static.dir/dma.c.obj -MF CMakeFiles/metal-static.dir/dma.c.obj.d -o CMakeFiles/metal-static.dir/dma.c.obj -c /github/workspace/lib/dma.c In file included from /github/workspace/build-generic/lib/include/metal/sys.h:85, from /github/workspace/build-generic/lib/include/metal/io.h:22, from /github/workspace/build-generic/lib/include/metal/device.h:16, from /github/workspace/lib/dma.c:9: /github/workspace/build-generic/lib/include/metal/system/generic/sys.h:27:10: fatal error: ./template/sys.h: No such file or directory 27 | #include "./template/sys.h" | ^~~~~~~~~~~~~~~~~~
Since MACHINE is not mandatory anymore, may be we should explicitly pass it to build the library if needed.

Hi @tnmysh : sorry for the late reply.
From my perspective the CI is good we specify the template machine in cmake/platforms/template-generic.cmake. The issue here is that the build-generic/lib/include/metal/system/generic/template folder is no more created.
Investigating the issue, it seems that it is coming from a syntax error in the PR
-if (DEFINED ${PROJECT_MACHINE})
+if (DEFINED PROJECT_MACHINE)
   add_subdirectory(${PROJECT_MACHINE})
-endif (DEFINED ${PROJECT_MACHINE})
+endif (DEFINED PROJECT_MACHINE) 
@arnopo

For xlnx platform, we don't use template machine. In that case, how can we make sure not to enforce anything related to template machine?

Tanmay

At least for build the CI does it for you: https://github.com/OpenAMP/libmetal/blob/main/.github/actions/build_ci/entrypoint.sh#L43-L51
You should be able to reproduce it locally on your PC.

arnopo · 2025-12-08T09:16:16Z

Something is not Crystal clear in AMD implementation
What is the value of PROJECT_SYSTEM regarding https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85?
I suppose that it is pointing to AMD sys.h defined in an AMD repo, right?
i would be nice to add aditional information in documentation to explain such mechanism, that should become the recommended implementation.

tnmysh · 2025-12-15T20:53:23Z

Something is not Crystal clear in AMD implementation What is the value of PROJECT_SYSTEM regarding https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85? I suppose that it is pointing to AMD sys.h defined in an AMD repo, right? i would be nice to add aditional information in documentation to explain such mechanism, that should become the recommended implementation.

HI @arnopo ,

sorry for delayed reply.

https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85 here we are passing PROJECT_SYSTEM value, but we don't want to pass PROJECT_MACHINE value.

Here

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

we don't have any PROJECT_MACHINE so, no header will be included.

Instead, we will include metal/sys.h into our vendor specific extension module, and implement those interfaces directly there and link them during building demos.

arnopo · 2025-12-16T15:47:11Z

Hi @tnmysh,

It is still not clear to me.

https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85 here we are passing PROJECT_SYSTEM value, but we don't want to pass PROJECT_MACHINE value.

what is the value of PROJECT_SYSTEM in your environment?

Here

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

we don't have any PROJECT_MACHINE so, no header will be included.
Instead, we will include metal/sys.h into our vendor specific extension module, and implement those interfaces directly there and link them during building demos.

You don't include the metal/sys.h generates from https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h?

Perhaps a link to the AMD extension module you mention, would help me to understand how you split the libmetal

tnmysh · 2025-12-16T15:54:12Z

Hi @tnmysh,

It is still not clear to me.

https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85 here we are passing PROJECT_SYSTEM value, but we don't want to pass PROJECT_MACHINE value.

what is the value of PROJECT_SYSTEM in your environment?

PRJOECT_SYSTEM can be one of the four: "generic", "freertos", "linux", or "zephyr".

Here

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

we don't have any PROJECT_MACHINE so, no header will be included.
Instead, we will include metal/sys.h into our vendor specific extension module, and implement those interfaces directly there and link them during building demos.

You don't include the metal/sys.h generates from https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h?

Yes, metal/sys.h is included in the extension as header.

Perhaps a link to the AMD extension module you mention, would help me to understand how you split the libmetal

Here it is: https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/xlnx_rel_v2025.2/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/metal_xlnx_extension.c

Here is the README: https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/xlnx_rel_v2025.2/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/README.md

arnopo · 2025-12-16T16:49:47Z

Hi @tnmysh,
It is still not clear to me.

https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85 here we are passing PROJECT_SYSTEM value, but we don't want to pass PROJECT_MACHINE value.

what is the value of PROJECT_SYSTEM in your environment?

PRJOECT_SYSTEM can be one of the four: "generic", "freertos", "linux", or "zephyr".

Here

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

we don't have any PROJECT_MACHINE so, no header will be included.
Instead, we will include metal/sys.h into our vendor specific extension module, and implement those interfaces directly there and link them during building demos.

You don't include the metal/sys.h generates from https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h?

Yes, metal/sys.h is included in the extension as header.

Perhaps a link to the AMD extension module you mention, would help me to understand how you split the libmetal

Here it is: https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/xlnx_rel_v2025.2/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/metal_xlnx_extension.c

Here is the README: https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/xlnx_rel_v2025.2/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/README.md

Unfortunately, this seems an AMD internal server. I don't have access to it.

tnmysh · 2025-12-16T18:05:32Z

Hi @tnmysh,
It is still not clear to me.

https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h#L85 here we are passing PROJECT_SYSTEM value, but we don't want to pass PROJECT_MACHINE value.

what is the value of PROJECT_SYSTEM in your environment?

PRJOECT_SYSTEM can be one of the four: "generic", "freertos", "linux", or "zephyr".

Here

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

we don't have any PROJECT_MACHINE so, no header will be included.
Instead, we will include metal/sys.h into our vendor specific extension module, and implement those interfaces directly there and link them during building demos.

You don't include the metal/sys.h generates from https://github.com/OpenAMP/libmetal/blob/main/lib/sys.h?

Yes, metal/sys.h is included in the extension as header.

Perhaps a link to the AMD extension module you mention, would help me to understand how you split the libmetal

Here it is: https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/xlnx_rel_v2025.2/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/metal_xlnx_extension.c
Here is the README: https://gitenterprise.xilinx.com/embeddedsw/embeddedsw/blob/xlnx_rel_v2025.2/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/README.md

Unfortunately, this seems an AMD internal server. I don't have access to it.

Ah! @arnopo I am so sorry. I completely missed it.

Here is the open source link: https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/metal_xlnx_extension.c

README: https://github.com/Xilinx/embeddedsw/tree/master/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib

Thanks,
Tanmay

arnopo · 2025-12-19T10:43:29Z

@tnmysh

I had a look at your repo. Please tell me if my analysis is wrong.

Regarding the README

The MACHINE is set to "zynqmp_r5"
set (MACHINE "zynqmp_r5" CACHE STRING "")
Regarding your commit
The PROJECT_MACHINE is defined and set to "zynqmp_r5"

Including libmetal/sys.h will include libmetal/zynqmp_r5/sys.h refering to the code in

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

At this point I was expecting to see libmetal/zynqmp_r5/sys.h in AMD extension

Now regarding AMD extension seems that you hack libmetal/generic/sys.h

It seems that you are replacing
#include "./@PROJECT_MACHINE@/sys.h"
by
#include <metal/system/generic/xlnx/sys.h>

This indicates to me that you don't use the include files generated by CMake but rather those defined in the AMD extension.

If my analysis is correct, this highlights a limitation in libmetal that forces users to update libmetal itself.

I wonder if we should break the direct link between the system and machine include files.
By renaming the machine includes (for instance, from sys.h to machine_sys.h or hal_sys.h), and instead of defining the path in the #include, we should add it to the include path list.

Is a fix is mandatory for do a fix for the v2025.10 release?

tnmysh · 2025-12-19T13:56:25Z

@tnmysh

I had a look at your repo. Please tell me if my analysis is wrong.

Regarding the README
The MACHINE is set to "zynqmp_r5"
set (MACHINE "zynqmp_r5" CACHE STRING "")

This is different project than libmetal. So whatever MACHINE is defined here its not same as libmetal.

Regarding your commit
The PROJECT_MACHINE is defined and set to "zynqmp_r5"

No, libmetal has different toolchain.cmake, it is not same as above extension library.

Including libmetal/sys.h will include libmetal/zynqmp_r5/sys.h refering to the code in

libmetal/lib/system/generic/sys.h

Line 27 in 1c3410b

#include "./@PROJECT_MACHINE@/sys.h"

At this point I was expecting to see libmetal/zynqmp_r5/sys.h in AMD extension

Now regarding AMD extension seems that you hack libmetal/generic/sys.h
It seems that you are replacing
#include "./@PROJECT_MACHINE@/sys.h"
by
#include <metal/system/generic/xlnx/sys.h>

This indicates to me that you don't use the include files generated by CMake but rather those defined in the AMD extension.

@arnopo

Above is partially correct. Actually, I don't pass template-toolchain.cmake, instead I have defined my own toolchain file for libmetal where PROJECT_MACHINE is not defined at all. If you prefer I can include my toolchain file in this PR. When you don't define PROJECT_MACHINE and build libmetal with this patch, it simply ignores @PROJECT_MACHINE/sys.h.

If my analysis is correct, this highlights a limitation in libmetal that forces users to update libmetal itself.

Correct. That is exactly why I introduced this patch, so extensions can be built out of libmetal.

I wonder if we should break the direct link between the system and machine include files. By renaming the machine includes (for instance, from sys.h to machine_sys.h or hal_sys.h), and instead of defining the path in the #include, we should add it to the include path list.

That is what this patch is doing. It removes requirement of @PROJECT_MACHINE/sys.h file.

Is a fix is mandatory for do a fix for the v2025.10 release?

This fix is needed because we are forcing template-toolchain.cmake to build the libmetal. So yes it is needed for v2025.10. I think the last patch re-introduced template directory, and when I tested, I didn't have the last patch of v2025.10. That is why I missed it.

arnopo · 2025-12-19T14:41:51Z

Above is partially correct. Actually, I don't pass template-toolchain.cmake, instead I have defined my own toolchain file for libmetal where PROJECT_MACHINE is not defined at all. If you prefer I can include my toolchain file in this PR. When you don't define PROJECT_MACHINE and build libmetal with this patch, it simply ignores @PROJECT_MACHINE/sys.h.

from my test you don't ignore @PROJECT_MACHINE/sys.h. the PROJECT_MACHINE is just empty and in the generated
libmetal/lib/system/generic/sys.h

The result is #include ".//sys.h"

Could you confirm it on your side?

If my analysis is correct, this highlights a limitation in libmetal that forces users to update libmetal itself.

Correct. That is exactly why I introduced this patch, so extensions can be built out of libmetal.

For legacy support, we need to at least use deprecation mechanism for next release

I wonder if we should break the direct link between the system and machine include files. By renaming the machine includes (for instance, from sys.h to machine_sys.h or hal_sys.h), and instead of defining the path in the #include, we should add it to the include path list.

That is what this patch is doing. It removes requirement of @PROJECT_MACHINE/sys.h file.

Is a fix is mandatory for do a fix for the v2025.10 release?

This fix is needed because we are forcing template-toolchain.cmake to build the libmetal. So yes it is needed for v2025.10. I think the last patch re-introduced template directory, and when I tested, I didn't have the last patch of v2025.10. That is why I missed it.

Ok that means that we have to find a short term solution and probably rework it for next release

For this release, what about having in libmetal/lib/system/xxxx/sys.h

#ifndef EXTERNAL_MACHINE
#include "./" PROJECT_MACHINE "/sys.h"
#endif

and in cmake

if(NOT DEFINED PROJECT_MACHINE OR PROJECT_MACHINE STREQUAL "")
    add_definitions(-DEXTERNAL_MACHINE)
endif()

tnmysh · 2025-12-19T15:47:53Z

Above is partially correct. Actually, I don't pass template-toolchain.cmake, instead I have defined my own toolchain file for libmetal where PROJECT_MACHINE is not defined at all. If you prefer I can include my toolchain file in this PR. When you don't define PROJECT_MACHINE and build libmetal with this patch, it simply ignores @PROJECT_MACHINE/sys.h.

from my test you don't ignore @PROJECT_MACHINE/sys.h. the PROJECT_MACHINE is just empty and in the generated libmetal/lib/system/generic/sys.h

The result is #include ".//sys.h"

Correct, and that sys.h won't be included again because, it's guarded with #ifndef. So it's like as if that line is not taking effect.

Could you confirm it on your side?

Confirmed.

If my analysis is correct, this highlights a limitation in libmetal that forces users to update libmetal itself.

Correct. That is exactly why I introduced this patch, so extensions can be built out of libmetal.

For legacy support, we need to at least use deprecation mechanism for next release

Legacy support on AMD-xlnx platform ?
Legacy support was introducing something xlnx specific, and not using standard libmetal API. With new extension, standard libmetal API use is possible. So, I am okay if we do not have legacy support on AMD-xlnx platform.

I wonder if we should break the direct link between the system and machine include files. By renaming the machine includes (for instance, from sys.h to machine_sys.h or hal_sys.h), and instead of defining the path in the #include, we should add it to the include path list.

That is what this patch is doing. It removes requirement of @PROJECT_MACHINE/sys.h file.

Is a fix is mandatory for do a fix for the v2025.10 release?

This fix is needed because we are forcing template-toolchain.cmake to build the libmetal. So yes it is needed for v2025.10. I think the last patch re-introduced template directory, and when I tested, I didn't have the last patch of v2025.10. That is why I missed it.

Ok that means that we have to find a short term solution and probably rework it for next release

For this release, what about having in libmetal/lib/system/xxxx/sys.h

Do you mean, introducing xlnx/sys.h and xlnx/sys.c ?
If we do that, then I will have to re-introduce xlnx directory under generic.
As legacy support is not expected on AMD-xlnx platform, I prefer not to introduce "xlnx" direcotry again. We can have template directory, for legacy support.

#ifndef EXTERNAL_MACHINE
#include "./" PROJECT_MACHINE "/sys.h"
#endif

and in cmake

Which cmake? option.cmake ? or CMakeLists.txt in system directory?

Also, If above #include becomes no-op as explained above, then do we need extra definition?

if(NOT DEFINED PROJECT_MACHINE OR PROJECT_MACHINE STREQUAL "")
    add_definitions(-DEXTERNAL_MACHINE)
endif()

arnopo · 2025-12-19T18:29:36Z

Above is partially correct. Actually, I don't pass template-toolchain.cmake, instead I have defined my own toolchain file for libmetal where PROJECT_MACHINE is not defined at all. If you prefer I can include my toolchain file in this PR. When you don't define PROJECT_MACHINE and build libmetal with this patch, it simply ignores @PROJECT_MACHINE/sys.h.

from my test you don't ignore @PROJECT_MACHINE/sys.h. the PROJECT_MACHINE is just empty and in the generated libmetal/lib/system/generic/sys.h
The result is #include ".//sys.h"

Correct, and that sys.h won't be included again because, it's guarded with #ifndef. So it's like as if that line is not taking effect.

Yes but the #include ".//sys.h" itself is not clean and the include of sys.h that is included by sys.h is not clean and can introduce confusion.

For legacy support, we need to at least use deprecation mechanism for next release

Legacy support on AMD-xlnx platform ? Legacy support was introducing something xlnx specific, and not using standard libmetal API. With new extension, standard libmetal API use is possible. So, I am okay if we do not have legacy support on AMD-xlnx platform.

Not only AMD platform. The generic template machine can be used as default machine for platforms that only needs metal for open-amp porting. This is the case for instance for ST platforms.

I wonder if we should break the direct link between the system and machine include files. By renaming the machine includes (for instance, from sys.h to machine_sys.h or hal_sys.h), and instead of defining the path in the #include, we should add it to the include path list.

That is what this patch is doing. It removes requirement of @PROJECT_MACHINE/sys.h file.

Is a fix is mandatory for do a fix for the v2025.10 release?

This fix is needed because we are forcing template-toolchain.cmake to build the libmetal. So yes it is needed for v2025.10. I think the last patch re-introduced template directory, and when I tested, I didn't have the last patch of v2025.10. That is why I missed it.

Ok that means that we have to find a short term solution and probably rework it for next release
For this release, what about having in libmetal/lib/system/xxxx/sys.h

Do you mean, introducing xlnx/sys.h and xlnx/sys.c ? If we do that, then I will have to re-introduce xlnx directory under generic. As legacy support is not expected on AMD-xlnx platform, I prefer not to introduce "xlnx" direcotry again. We can have template directory, for legacy support.

I mean by libmetal/lib/system/xxxx/sys.h metal/system/@PROJECT_SYSTEM@/sys.h

#ifndef EXTERNAL_MACHINE
#include "./" PROJECT_MACHINE "/sys.h"
#endif

apologogize the code should be

 #ifndef EXTERNAL_MACHINE
 #include "./@PROJECT_MACHINE@/sys.h" 
 #endif

But writing this I realize that it is not clean, the generated code would be in AMD case

 #ifndef EXTERNAL_MACHINE
 #include ".//sys.h" 
 #endif

So forget this approach

What about following the approach done for the cache ?

in libmetal/lib/system/generic/sys.h and libmetal/lib/system/freertos/sys.h
- remove line
  #include "./@PROJECT_MACHINE@/sys.h"
- move fonctions declaration from lib/system/freertos/template/sys.h and lib/system/generic/template/sys.h to libmetal/lib/system/generic/sys.h and libmetal/lib/system/freertos/sys.h

void sys_irq_enable(unsigned int vector);
void sys_irq_disable(unsigned int vector);

In such case we could remove lib/system/freertos/template/sys.h and lib/system/generic/template/sys.h

Could you try this with your AMD code?
I will test the template machine on my side.

and in cmake

Which cmake? option.cmake ? or CMakeLists.txt in system directory?

Also, If above #include becomes no-op as explained above, then do we need extra definition?
if(NOT DEFINED PROJECT_MACHINE OR PROJECT_MACHINE STREQUAL "")
    add_definitions(-DEXTERNAL_MACHINE)
endif()

tnmysh · 2025-12-19T19:36:46Z

Above is partially correct. Actually, I don't pass template-toolchain.cmake, instead I have defined my own toolchain file for libmetal where PROJECT_MACHINE is not defined at all. If you prefer I can include my toolchain file in this PR. When you don't define PROJECT_MACHINE and build libmetal with this patch, it simply ignores @PROJECT_MACHINE/sys.h.

from my test you don't ignore @PROJECT_MACHINE/sys.h. the PROJECT_MACHINE is just empty and in the generated libmetal/lib/system/generic/sys.h
The result is #include ".//sys.h"

Correct, and that sys.h won't be included again because, it's guarded with #ifndef. So it's like as if that line is not taking effect.

Yes but the #include ".//sys.h" itself is not clean and the include of sys.h that is included by sys.h is not clean and can introduce confusion.

For legacy support, we need to at least use deprecation mechanism for next release

Legacy support on AMD-xlnx platform ? Legacy support was introducing something xlnx specific, and not using standard libmetal API. With new extension, standard libmetal API use is possible. So, I am okay if we do not have legacy support on AMD-xlnx platform.

Not only AMD platform. The generic template machine can be used as default machine for platforms that only needs metal for open-amp porting. This is the case for instance for ST platforms.

I wonder if we should break the direct link between the system and machine include files. By renaming the machine includes (for instance, from sys.h to machine_sys.h or hal_sys.h), and instead of defining the path in the #include, we should add it to the include path list.

That is what this patch is doing. It removes requirement of @PROJECT_MACHINE/sys.h file.

Is a fix is mandatory for do a fix for the v2025.10 release?

This fix is needed because we are forcing template-toolchain.cmake to build the libmetal. So yes it is needed for v2025.10. I think the last patch re-introduced template directory, and when I tested, I didn't have the last patch of v2025.10. That is why I missed it.

Ok that means that we have to find a short term solution and probably rework it for next release
For this release, what about having in libmetal/lib/system/xxxx/sys.h

Do you mean, introducing xlnx/sys.h and xlnx/sys.c ? If we do that, then I will have to re-introduce xlnx directory under generic. As legacy support is not expected on AMD-xlnx platform, I prefer not to introduce "xlnx" direcotry again. We can have template directory, for legacy support.

I mean by libmetal/lib/system/xxxx/sys.h metal/system/@PROJECT_SYSTEM@/sys.h
#ifndef EXTERNAL_MACHINE
#include "./" PROJECT_MACHINE "/sys.h"
#endif
apologogize the code should be
 #ifndef EXTERNAL_MACHINE
 #include "./@PROJECT_MACHINE@/sys.h" 
 #endif
But writing this I realize that it is not clean, the generated code would be in AMD case
 #ifndef EXTERNAL_MACHINE
 #include ".//sys.h" 
 #endif
So forget this approach

What about following the approach done for the cache ?

in libmetal/lib/system/generic/sys.h and libmetal/lib/system/freertos/sys.h

remove line
#include "./@PROJECT_MACHINE@/sys.h"

move fonctions declaration from lib/system/freertos/template/sys.h and lib/system/generic/template/sys.h to libmetal/lib/system/generic/sys.h and libmetal/lib/system/freertos/sys.h
void sys_irq_enable(unsigned int vector);
void sys_irq_disable(unsigned int vector);
In such case we could remove lib/system/freertos/template/sys.h and lib/system/generic/template/sys.h

Could you try this with your AMD code? I will test the template machine on my side.

Okay, yeah that is reasonable. Then we can remove template/sys.h completely.

and in cmake

Which cmake? option.cmake ? or CMakeLists.txt in system directory?
Also, If above #include becomes no-op as explained above, then do we need extra definition?
if(NOT DEFINED PROJECT_MACHINE OR PROJECT_MACHINE STREQUAL "")
    add_definitions(-DEXTERNAL_MACHINE)
endif()

arnopo · 2025-12-22T09:47:08Z

@tnmysh : I pushed a commit on your branch. I tested it and the template machine is functional

If Ok for you could you create a new PR for the the v2025.10 branch I just created ?
I will create a release 2025.10.1 when merged after the review process

libmetal can be build without any machine support. It is possible that vendors implement machine specific interfaces outside of libmetal and link it with demos during build time. Hence, remove requirement to have MACHINE and PROJECT_MACHINE variables from the build system. If vendor prefer to choose 'template' machine, they can pass such option during cmake configuration. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>

This directory was removed and re-inroduced by mistake, and should not exists in the libmetal. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>

tnmysh · 2025-12-24T04:10:59Z

@tnmysh : I pushed a commit on your branch. I tested it and the template machine is functional

I tested this on AMD-xilinx platform, and it's working.

If Ok for you could you create a new PR for the the v2025.10 branch I just created ? I will create a release 2025.10.1 when merged after the review process

Okay, I will create a new PR.

tnmysh · 2025-12-24T04:20:40Z

@arnopo here is the new PR as requested: #354

Declare sys_irq_enable() and sys_irq_enable() directly in lib/system/@PROJECT_SYSTEM@/sys.h. This allows to declare the machine out of tree of the libmetal but also to support the in-tree template. [minor style fix by tanmay] Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>

tnmysh · 2025-12-24T16:31:17Z

@arnopo pushed minor fix in your commit related to checkpatch.pl. Other than that this PR looks good.

arnopo

same to #354 but for the main branch

arnopo · 2026-01-20T08:47:58Z

@tnmysh : Please update this PR to resolve conflicts

tnmysh requested review from arnopo and edmooring November 19, 2025 18:06

tnmysh force-pushed the build_machineless_libmetal branch from cd9e5a3 to 64f1c7a Compare November 19, 2025 18:19

tnmysh force-pushed the build_machineless_libmetal branch 5 times, most recently from 43c30b3 to db68068 Compare December 4, 2025 23:22

tnmysh added 2 commits December 23, 2025 13:55

lib: freertos: remove xlnx vendor directory

3b55d67

This directory was removed and re-inroduced by mistake, and should not exists in the libmetal. Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>

tnmysh force-pushed the build_machineless_libmetal branch from 87028b2 to 51e5ecf Compare December 24, 2025 16:29

xiaoxiang781216 approved these changes Jan 4, 2026

View reviewed changes

arnopo mentioned this pull request Jan 7, 2026

Build machineless libmetal v2025.10 #354

Merged

arnopo approved these changes Jan 20, 2026

View reviewed changes

Build machine-less libmetal #350

Are you sure you want to change the base?

Build machine-less libmetal #350

Uh oh!

Conversation

tnmysh commented Nov 19, 2025

Uh oh!

tnmysh commented Nov 19, 2025

Uh oh!

tnmysh commented Nov 19, 2025

Uh oh!

arnopo commented Dec 1, 2025

Uh oh!

tnmysh commented Dec 2, 2025

Uh oh!

arnopo commented Dec 2, 2025

Uh oh!

arnopo commented Dec 8, 2025

Uh oh!

tnmysh commented Dec 15, 2025

Uh oh!

arnopo commented Dec 16, 2025

Uh oh!

tnmysh commented Dec 16, 2025

Uh oh!

arnopo commented Dec 16, 2025

Uh oh!

tnmysh commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arnopo commented Dec 19, 2025

Uh oh!

tnmysh commented Dec 19, 2025

Uh oh!

arnopo commented Dec 19, 2025

Uh oh!

tnmysh commented Dec 19, 2025

Uh oh!

arnopo commented Dec 19, 2025

Uh oh!

tnmysh commented Dec 19, 2025

Uh oh!

arnopo commented Dec 22, 2025

Uh oh!

tnmysh commented Dec 24, 2025

Uh oh!

tnmysh commented Dec 24, 2025

Uh oh!

tnmysh commented Dec 24, 2025

Uh oh!

arnopo left a comment

Choose a reason for hiding this comment

Uh oh!

arnopo commented Jan 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tnmysh commented Dec 16, 2025 •

edited

Loading