-
Notifications
You must be signed in to change notification settings - Fork 194
Add QNX cross-compilation support #343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Following API additions are made to support libmetal on QNX systems allocate and free memory assert statements caching support condition variables physical devices like static shared memory i/o configurations interrupt requests logs mutex dynamic shared memory (under /dev/shmem) with precise page-wise controls sleep time system and misc utilities fix irq compilation Signed-off-by: Deep Chordia <dchordia@blackberry.com>
|
Hello @dchordia, Thanks for this contribution. First of all, if you are not aware, the v2025.10 release is planned for this month, with the associated code freeze scheduled for the end of this week. The delay will probably be too short to integrate QNX support for this release. That said, would it be possible for you to split this PR into two parts?
|
|
Thanks for quick response. Ah, I had planned to squeeze it in before October release but that will likely not be the case. I will split the PR based on your feedback. However, regarding build testing CI, we have not yet officially worked on integrating it in any open-source repositories. Right now I am in experimental testing (build test as well as run unit test) stage for a similar request from AWS (example run PR at qnx-ports CI). A way ahead to enable QNX CI build job in this repository would require SDP based on maintainer registed QNXE license. Post which either a custom docker with this Software Development Platform (SDP) can be created and spin up on each QNX build run or SDP has to downloaded for before each QNX build run. |
If you are not able to add CI in the first step, we can address this later. Just be aware that, in such a case, we will not be able to ensure that updates in the Libmetal or OpenAMP libraries do not break the QNX build. The CACHE_ PR is a good example. |
|
Sure. Yes, right. I will make CI additions soon. In the meantime, can one of the repository maintainers register for QNXE license and store credentials (username, password, license key) in org level GitHub secrets. CI jobs for QNX requires pulling SDP which will require the credentials |
|
This pull request has been marked as a stale pull request because it has been open (more than) 45 days with no activity. |
|
Hello @dchordia |
|
Hello @arnopo, Regarding CI, legal division is making changes to licensing terms to accommodate multi-user cloud builds and hoping to get that done by January. Once that is complete, and license is signed by one of the libmetal maintainers, I can work towards CI integration. |
@dchordia, Could you please add a README with step by step instructions that people can use to build libmetal with QNX ? |
Add QNX build process
arnopo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started to review your PR and posted a few comments.
I’m not familiar with QNX, so I would like to understand if your porting could be simplified.
It seems you use Linux as a reference system. This reference might not be the most appropriate since it more complex allowing the implementation of the OpenAMP library in Linux userspace (with specific IRQ management, filesystem for shared memory, etc.).
If QNX is more similar to Zephyr, NuttX, or FreeRTOS, I suggest looking at those portings to simplify yours.
Additionally, please split your commit into two: one for the library and one for the tests.
| * SPDX-License-Identifier: BSD-3-Clause | ||
| */ | ||
|
|
||
| /* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To update in all source file in this PR ( I will create a PR for the reste of the libmetal files)
| /* | |
| /** |
| metal_log(METAL_LOG_ERROR, "cache init failed - %s\n", | ||
| strerror(errno)); | ||
| return -errno; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to initialize the cache and the IRQs here?
I the libmetal is only used for the openamp library porting layer. theses initialization are probably already done during your QNX system initialization.
| GENERIC_BUS_REGISTER = 1; | ||
| } | ||
|
|
||
| metal_unused(params); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to move at the beginning of the function
| int metal_sys_io_mem_map(struct metal_io_region *io) | ||
| { | ||
| if (io->virt) | ||
| return 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
coding style; please declare first local variable
| int irq, unsigned int state); | ||
|
|
||
| /* QNX IRQ controller */ | ||
| static METAL_IRQ_CONTROLLER_DECLARE(qnx_irq_cntr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need this for the OpenAMP porting?
The definitions of metal_irq_save_enable and metal_irq_save_disable could be sufficient here.
the rest of the IRQ management in libmetal is more of an optional extension and is not used by default in the OpenAMP library.
You can have a look to Zephyr porting as example
| NULL, NULL, NULL, NULL, NULL, metal_shmem_io_close, NULL, NULL | ||
| }; | ||
|
|
||
| static int metal_shmem_try_map(int fd, size_t size, struct metal_io_region **result) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need this complexity in QNX? this seems similar to the Linux userspace implementation.
| #include <sys/stat.h> | ||
| #include <sys/types.h> | ||
| #include <sys/wait.h> | ||
| #include <unistd.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems that some include are useless here
Thanks for the guide, I'm facing docker access restriction in my Ubuntu environment. I need first to fix that with my DIT (beginning of January)
This seems reasonable, it let time for next release in April. |
Hi,
This contribution adds cross-compilation support for QNX operating system to libmetal.
Motivation
QNX is an industry standard real-time operating system for embedded systems, particularly for vehicles, featuring safety focused features. It has also recently been made free for non-commercial use through the QNX Everywhere program, aiming for students, researchers and hobbyists to experiment with the OS.
Given that libmetal is a powerful abstraction layer across different OSes and baremetal as well as being a dependency to open-amp, it would be great to enable libmetal to run natively on free version of QNX OS.
Description of changes
Following API additions are made to support libmetal on QNX system
These changes have been reviewed by QNX open-source team at supporting PR, for v2024.10.0, and additional supporting changes have been made to make it compatible with latest main.
How to build for QNX
The build-files and instructions for cross-compiling libmetal for QNX are present at qnx-ports. A free QNX8 license can be obtained here
By submitting this pull request, I confirm that my contribution is made under the terms of BSD License
PS: Tagging @arnopo for review