Skip to content

Conversation

@lyakh
Copy link
Collaborator

@lyakh lyakh commented Oct 7, 2021

This should fix #4645, but additional Zephyr fixes are needed to fix the run-time too

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this Kconfig defaults for each platform ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lgirdwood in principle we can, sure. But just a couple of day ago I had to remind myself that select statements in Kconfig aren't recursive. I was trying to reconfigure the kernel, changed an option, its directly selected dependencies got switched, but not the next level up. So, maybe it would be good to limit the use of select at least where it's easy to avoid?

Copy link
Collaborator

@marc-hb marc-hb Oct 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a comment explaining that this is for memory usage reasons (and not for avoiding a bug or some other reason)

I find this more readable because it's closer to plain English:

if defined __XCC__ && ! (CONFIG_ZEPHYR_SOF_MODULE && CONFIG_APOLLOLAKE)

as in: "do not do this for Zephyr on APL"

Don't ask me about Kconfig but there seems to be some good documentation at https://docs.zephyrproject.org/latest/guides/build/kconfig/tips.html#alternatives-to-select

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marc-hb ack, agree, updated

Copy link
Collaborator

@marc-hb marc-hb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. If @singalsu can check the algo-version check. If there's a cleaner way, let'd do that, but if not, let's go with this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@singalsu Can you review this? Is there a cleaner way to do this?

Copy link
Collaborator

@singalsu singalsu Oct 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no point in leaving out the the optimizations, the intrinsics code is ball park of 10x speed with same configuration. Instead Zephyr build should choose the tiny coefficients set from kconfig (CONFIG_COMP_SRC_TINY) but keep optimizations. @lyakh Do you have ideas how to accomplish it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@singalsu it's easy to enable CONFIG_COMP_SRC_TINY for Zephyr on APL, but then it would be used for both gcc and xcc. Don't think we can check for compiler in Kconfig. Or we can do something like

 #if defined __XCC__
+#if CONFIG_APOLLOLAKE && CONFIG_ZEPHYR_SOF_MODULE
+#define SRC_SHORT	1
+#endif

What's preferred?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can probably override the CONFIG_COMP_SRC_TINY default value in xtensa-build-zephyr.sh. We have the platform and compiler information there. For similar examples search for "config" in https://github.com/thesofproject/sof/blob/main/scripts/xtensa-build-all.sh

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marc-hb I'd rather not do that. It should work without using the script too.

Copy link
Collaborator

@marc-hb marc-hb Oct 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are many other ways to ran out of memory (or worse) with Kconfig but fair enough: so much better when the defaults work.

but then it would be used for both gcc and xcc

How much of a problem would this be?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marc-hb 0, it was my mistake: with gcc the SRC_SHORT option is already used

@lyakh lyakh requested a review from singalsu October 11, 2021 08:39
Copy link
Collaborator

@singalsu singalsu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's another way

Building SOF with Zephyr for Apollolake with XCC fails because of
insufficient RAM. Reduce the heap size to fix the problem.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
@lyakh
Copy link
Collaborator Author

lyakh commented Oct 12, 2021

as discussed with @singalsu I've moved src configuration to a Zephyr PR zephyrproject-rtos/zephyr#39351

Copy link
Collaborator

@singalsu singalsu 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 to me, thanks!

@kv2019i
Copy link
Collaborator

kv2019i commented Oct 13, 2021

https://sof-ci.01.org/sofpr/PR4852/build10688/build/apl_zph_error.txt still failing. Some iteration on zephyrproject-rtos/zephyr#39351 needed. Once it is merged, we can merge this.

Zephyr XCC builds for Apollolake can be re-enabled now after the RAM
footprint has been reduced.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
@lgirdwood
Copy link
Member

@wszypelt @kkarask looks like CI is blocked ?

@wszypelt
Copy link

@lgirdwood yes, there were some problems, but it's working fine now

@marc-hb
Copy link
Collaborator

marc-hb commented Oct 13, 2021

Still failing in https://sof-ci.01.org/sofpr/PR4852/build10697/build/

/srv/home/jenkins/xcc/install/tools/RG-2017.8-linux/XtensaTools/bin/xt-ld:
address 0x9e084178 of zephyr/zephyr_prebuilt.elf section `.bss' is not within region `ucram'

This was with Zephyr commit 2f359aeacfab and SOF commit:

bc0b7e8bc 9823983a0 d50bef36e (HEAD, sof/pull/4852/merge)
Merge d50bef36eb80a03029edbcf008526dcff0f91f23 into 9823983a0ff037e5d9c8c1ee91ec806fa7ac87d2

EDIT: Zephyr commit 2f359aeacfab was 2 commits short of @lyakh's CONFIG_COMP_SRC_TINY=y change zephyrproject-rtos/zephyr#39351 so no surprise it still fails.

@marc-hb
Copy link
Collaborator

marc-hb commented Oct 13, 2021

SOFCI TEST

@marc-hb
Copy link
Collaborator

marc-hb commented Oct 14, 2021

Successful XCC + APL build at https://sof-ci.01.org/sofpr/PR4852/build10705/build/apl_zph.txt with newer Zephyr a8c4abdcf055

@kv2019i
Copy link
Collaborator

kv2019i commented Oct 14, 2021

@lgirdwood This is now ready!

@lgirdwood lgirdwood merged commit 6ce3237 into thesofproject:main Oct 14, 2021
@lyakh lyakh deleted the z-apl-xcc branch October 14, 2021 14:36
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.

[BUG] [APL] Zephyr SOF link failure on APL with XCC toolchain, .bss not within ucram

6 participants