Skip to content
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

Merged
merged 3 commits into from
May 15, 2023

Conversation

paulstelian97
Copy link
Collaborator

@paulstelian97 paulstelian97 commented Apr 28, 2023

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)


#ifndef UINT32_C
#define UINT32_C(x) __UINT32_C(x)
#endif
Copy link
Collaborator

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?

Copy link
Collaborator Author

@paulstelian97 paulstelian97 Apr 28, 2023

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)

Copy link
Collaborator

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?

@dbaluta
Copy link
Collaborator

dbaluta commented May 2, 2023

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?

@iuliana-prodan
Copy link
Contributor

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).
@paulstelian97 I agree with @dbaluta to add a commit for updating west.yaml in this PR.

@dbaluta
Copy link
Collaborator

dbaluta commented May 4, 2023

@lgirdwood :

@kv2019i
Copy link
Collaborator

kv2019i commented May 4, 2023

@dbaluta wrote:

* are we using https://github.com/zephyrproject-rtos/zephyr/ with sof? or https://github.com/thesofproject/zephyr
* should we create a separate PR to upgrade the zephyr hash?

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.

@dbaluta
Copy link
Collaborator

dbaluta commented May 4, 2023

@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?

@kv2019i
Copy link
Collaborator

kv2019i commented May 4, 2023

@dbaluta wrote:

@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?

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).

@marc-hb
Copy link
Collaborator

marc-hb commented May 5, 2023

are we using https://github.com/zephyrproject-rtos/zephyr/ [upstream] with sof? or https://github.com/thesofproject/zephyr [fork]

Short answer: upstream every time it's possible, fork when it's not.

Long answer: see @kv2019i's above :-)

Copy link
Collaborator

@kv2019i kv2019i left a 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).

@kv2019i
Copy link
Collaborator

kv2019i commented May 11, 2023

@tmleman Do we need #7174 to make the INtel MTL test pass, or is this something else (this PR moves to a newer Zephyr).

@tmleman
Copy link
Contributor

tmleman commented May 11, 2023

Do we need #7174 to make the INtel MTL test pass, or is this something else (this PR moves to a newer Zephyr).

@kv2019i If we do a zephyr update without my patch, the secondary cores will stop working on MTL. Currently, there are probably no tests for this in CI, so the fail's are rather unrelated.

@paulstelian97
Copy link
Collaborator Author

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
Copy link
Collaborator

dbaluta commented May 11, 2023

@tmleman so should we merge #7174 first? Or should we merge current PR now?

Is #7174 ready? We would like to have this patch merged asap because we have an internal release coming.

@tmleman
Copy link
Contributor

tmleman commented May 11, 2023

@tmleman so should we merge #7174 first? Or should we merge current PR now?

Is #7174 ready? We would like to have this patch merged asap because we have an internal release coming.

@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.

@kv2019i
Copy link
Collaborator

kv2019i commented May 11, 2023

@wszypelt Ok to proceed, this is not touching Intel platforms.? short term memory loss on my part, sorry for the noise. so now I read my own comment from today and will proceed and look at #7174

@kv2019i
Copy link
Collaborator

kv2019i commented May 11, 2023

@paulstelian97 #7174 merged, can you rebase and let's see if the CI passes now.

Paul Olaru added 2 commits May 12, 2023 09:56
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 <paul.olaru@nxp.com>
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 <paul.olaru@nxp.com>
@paulstelian97
Copy link
Collaborator Author

paulstelian97 commented May 12, 2023

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 <paul.olaru@nxp.com>
@dbaluta
Copy link
Collaborator

dbaluta commented May 12, 2023

@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
Copy link
Collaborator

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?

Copy link
Collaborator Author

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)

@dbaluta dbaluta merged commit 1acead1 into thesofproject:main May 15, 2023
@paulstelian97 paulstelian97 deleted the xt-clang-updates branch May 17, 2023 08:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants