Skip to content

Conversation

@checkupup
Copy link
Contributor

  • 5.1, 7.1 input channels support for DAX.
  • Fixed compilation errors on XTOS
  • Remove memmove and sprintf usage in DAX code for better adaptation to LLEXT

@sofci
Copy link
Collaborator

sofci commented Dec 3, 2025

Can one of the admins verify this patch?

reply test this please to run this test once

uint32_t offset = 0;

for (uint32_t i = 0; i < param_sz && offset < MAX_PARAMS_STR_BUFFER_SIZE; i++)
offset += sprintf(params_str + offset, "%d,", param_val[i]);
Copy link
Collaborator

Choose a reason for hiding this comment

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

other libc functions are exported from https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/llext/llext_export.c#L10-L17 - have you tried adding sprintf() and memmove() there?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not yet. Oh thanks it seems like a better solution.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lyakh This change works, then I will commit a PR to Zephyr and revert the modifications in SOF. Very thanks.

diff --git a/subsys/llext/llext_export.c b/subsys/llext/llext_export.c
index fe2c417795b..c1835819fc3 100644
--- a/subsys/llext/llext_export.c
+++ b/subsys/llext/llext_export.c
@@ -5,6 +5,8 @@
  */
 
 #include <string.h>
+#include <stdlib.h>
+#include <stdio.h>
 #include <zephyr/llext/symbol.h>
 
 EXPORT_SYMBOL(strcpy);
@@ -15,6 +17,9 @@ EXPORT_SYMBOL(strncmp);
 EXPORT_SYMBOL(memcmp);
 EXPORT_SYMBOL(memcpy);
 EXPORT_SYMBOL(memset);
+EXPORT_SYMBOL(memmove);
+EXPORT_SYMBOL(strtoul);
+EXPORT_SYMBOL(sprintf);
 
 /* These symbols are used if CCAC is given the flag -Os */
 #ifdef __CCAC__

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

See Zephyr PR: zephyrproject-rtos/zephyr#100442

@checkupup as far as I understand this SOF PR does not actually formally depend on that Zephyr PR, right? Obviously you need it for your module to work, but from the SOF PoV nothing will break in the repository if this PR is merged before we update our Zephyr hash to include your Zephyr PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is indeed a potential problem, let's adopt the modifications from both SOF and Zephyr.

Copy link
Member

Choose a reason for hiding this comment

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

Also approved zephyrproject-rtos/zephyr#100442.

@checkupup if we assume Zephyr PR will merge as-is, do we need any changes here ? I dont mind merging into SOF if its not a formal dependency.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lgirdwood No, if Zephyr PR is merged, the SOF commit 8a0e63e is no longer needed. However if the SOF commit is merged, the Zephyr PR is still needed. Both of them serve the LLEXT implementation of DAX module.

Copy link
Member

Choose a reason for hiding this comment

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

@lgirdwood No, if Zephyr PR is merged, the SOF commit 8a0e63e is no longer needed. However if the SOF commit is merged, the Zephyr PR is still needed. Both of them serve the LLEXT implementation of DAX module.

@checkupup thanks, just checked and Zephyr PR is now merged. Can you drop the stdlib commit and add a west update to align with the new Zephyr commit we depend on. Thanks !

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lgirdwood I will add the new Zephyr commit to west.yml. However, regardless of whether the stdlib commit is summitted or not, the modification of west.yml is necessary, so I tend to keep this commit to improve robustness to dependencies.

@checkupup checkupup force-pushed the dax_fixes branch 2 times, most recently from 5220336 to 8a0e63e Compare December 4, 2025 08:33
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

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

Just one question.

uint32_t offset = 0;

for (uint32_t i = 0; i < param_sz && offset < MAX_PARAMS_STR_BUFFER_SIZE; i++)
offset += sprintf(params_str + offset, "%d,", param_val[i]);
Copy link
Member

Choose a reason for hiding this comment

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

Also approved zephyrproject-rtos/zephyr#100442.

@checkupup if we assume Zephyr PR will merge as-is, do we need any changes here ? I dont mind merging into SOF if its not a formal dependency.

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

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

Just one question.

@checkupup
Copy link
Contributor Author

if we assume Zephyr PR will merge as-is, do we need any changes here ? I dont mind merging into SOF if its not a formal dependency.

@lgirdwood We don't need stdlib change if Zephyr PR merges as-is. But I believe minimizing dependencies is always a good thing when we compiling with CONFIG_COMP_DOLBY_AUDIO_PROCESSING_MOCK and working well with --gc-sections flag.

@lgirdwood
Copy link
Member

rerun CI - due to lab power off

@lgirdwood
Copy link
Member

SOFCI TEST

@softwarecki
Copy link
Collaborator

Please use tags in the PR title next time, for example dax: . When I first saw this PR, my initial thought was that it fixes something in llext.

@softwarecki softwarecki changed the title Fixing compilation errors and better adaptation to LLEXT dax: Fixing compilation errors and better adaptation to LLEXT Dec 11, 2025
@lgirdwood
Copy link
Member

@checkupup looks like we have a conflict and the west patch could be dropped if it has your dependency.

Add 5.1, 7.1 input channels for DAX.

Signed-off-by: Jun Lai <jun.lai@dolby.com>
sof_top_dir is unavailable for non-zephyr build.

Signed-off-by: Jun Lai <jun.lai@dolby.com>
We remove memmove and sprintf for two reasons:

1) Both of them are not available on XTOS
when using certain xtensa toolchains.
2) Them are not marked as EXPORT_SYMBOL by
Zephyr when compiling as LLEXT module.

Signed-off-by: Jun Lai <jun.lai@dolby.com>
@checkupup
Copy link
Contributor Author

Hi, @lgirdwood , I have resolved the conflict, but we still needs the west patch:

No, if Zephyr PR is merged, the SOF commit 8a0e63e is no longer needed. However if the SOF commit is merged, the Zephyr PR is still needed. Both of them serve the LLEXT implementation of DAX module.

I have kept the SOF commit due to:

But I believe minimizing dependencies is always a good thing.

@lgirdwood
Copy link
Member

looks like CI got stuck - will rerun.

@lgirdwood
Copy link
Member

SOFCI TEST

@kv2019i kv2019i changed the title dax: Fixing compilation errors and better adaptation to LLEXT dax: Fixing compilation errors and better adaptation to LLEXT (contains Zephyr Dec03 update) Dec 12, 2025
@kv2019i kv2019i merged commit 631fc30 into thesofproject:main Dec 15, 2025
37 of 43 checks passed
@checkupup checkupup deleted the dax_fixes branch December 23, 2025 01:53
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.

6 participants