-
Notifications
You must be signed in to change notification settings - Fork 319
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
Fixes for i.MX xt-clang build #7538
Conversation
a642a4d
to
4061b5a
Compare
|
||
#ifndef UINT32_C | ||
#define UINT32_C(x) __UINT32_C(x) | ||
#endif |
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.
This #ifndef #define
pattern is at best a necessary evil because the definition can change depending the #include
order (recent example: 2512698) and the direction the wind blows.
So can you transfer some of the information and justification from the commit message to the comment here?
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.
The reason I had to put it in here in the first place, especially with the __ZEPHYR__
guard, is because of the include order. On XTOS builds (including i.MX8) without that guard this is included before newlib and newlib does not do this, which leads to conflicts.
I will copy the comment and resubmit, maybe today but if not on Tuesday. (edit: done)
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.
On XTOS builds (including i.MX8) without that guard this is included before newlib and newlib does not do this, which leads to conflicts.
What sort of conflicts? This is coming up again in non-Zephyr build #9351 (comment) ...
Maybe @keith-packard or @stephanosio could help us get out of this libc / toolchain nightmare?
4061b5a
to
f355573
Compare
Now because Zephyr PR was merged I think we are ready to get this out of draft state. @iuliana-prodan should we update the west yaml to pull in the new zephyr code? |
Yes, definitely we should update the west.yaml with latest zephyr (to bring the changes needed for i.MX with xt-clang). |
bf85fab
to
6a4e769
Compare
|
@dbaluta wrote:
We are using https://github.com/zephyrproject-rtos/zephyr/ and the version defined in sof/west.yml. So you can add a commit to this PR to update the Zephyr version (see git log of sof/west.yml for examples). If we have a breaking interface change (like the SYS_INIT last week), then the SOF change and west.yml update need to be squashed into a single git commit, in order not to break git bisect. |
@lyakh great! then we are fine. A commit to update zephyr has was already added to this PR. Also, how are you doing for stable-v2.x version? |
@dbaluta wrote:
stable-v2.x branches have their own west.yml and there we've either used upstream Zephyr repo (if no backports are needed to Zephyr), or SOF zephyr clone (if Zephyr backports are needed for the stable series). The west.yml specifies both the repo and commit, so we can easily switch. Any any SOF branch/commit will always have a clear mapping to a Zephyr version, so there's no ambiguity on the version used. PS west.yml can also point to an unmerged pull request. This is a nice tool to test a Zephyr change with SOF CI (before it gets merged). |
Short answer: upstream every time it's possible, fork when it's not. Long answer: see @kv2019i's above :-) |
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.
Looks good, let's see the CI for the Zephyr update (should be good).
I don't have any qualms with which specific version of Zephyr to update to, my pull request just holds the earliest commit that solves the problem, but I wouldn't mind anything newer (or an update on the main branch that I can rebase on top of, which is even better IMO) |
@dbaluta #7174 is ready to be merged and I think it would be better if it gets merged first. It would make bisecting easier in case of any problems. |
@paulstelian97 #7174 merged, can you rebase and let's see if the CI passes now. |
This define is used by the new 2023 xt-clang toolchain and, while there are a few definitions (identical to this one) in various implementations such as newlib, none of them is in use when building SOF with Zephyr and XtensaTools. Add this define so that the toolchain provided headers work correctly. Signed-off-by: Paul Olaru <[email protected]>
For the functions platform_interrupt_clear and platform_interrupt_set, the existing definitions based on arch_interrupt_* do not compile with the xt-clang 2023 toolchain for imx. Use the Zephyr wrapper implementations for those for now. Signed-off-by: Paul Olaru <[email protected]>
Main branch still behind the commit I need, do I keep the update? I pushed without, can push the extra commit if necessary. |
This update is needed to include Zephyr specific patches required for building SOF on i.MX platforms with Xtensa toolchain. Signed-off-by: Paul Olaru <[email protected]>
6a4e769
to
480b24e
Compare
@paulstelian97 we still need to zephyr update, right? otherwise, the build will fail for SOF imx8 with xt-clang. |
#define UINT32_C(x) __UINT32_C(x) | ||
#endif | ||
|
||
#endif |
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.
is this really a suitable header for this? This seems some compiler compatibility support, how about xtos/include/sof/compiler_attributes.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.
I'm pretty sure the xtos/ subfolder isn't used in Zephyr builds; I want the opposite (something that only applies to Zephyr)
These two commits, together with upstream patch zephyrproject-rtos/zephyr#57374 fix the build of SOF for i.MX platforms with the new xt-clang Cadence 2023 toolchain.
Keeping as draft until the Zephyr patch is merged. (edit: Zephyr patch merged, west manifest updated)