Test: reenable boot-testing

[lyakh]

a subset of #10119 without userspace

[Copilot]

Pull Request Overview

This PR refactors the boot test infrastructure by consolidating test execution into the IPC handler and adds heap assignment for specific Zephyr threads. Key changes include:

• Moved boot test suite registration and execution from a standalone file to the IPC4 handler
• Added a new sof_sys_heap_get() API to expose the SOF system heap for thread heap assignment
• Removed unused code and fixed function signatures in test files

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
zephyr/boot_test.c	Deleted standalone boot test file (logic moved to IPC handler)
src/ipc/ipc4/handler.c	Added boot test suite registration and deferred test execution after first IPC
src/include/sof/boot_test.h	Removed unused TEST_RUN_ONCE macro; added logging header include
zephyr/lib/alloc.c	Added sof_sys_heap_get() function to expose SOF system heap
zephyr/include/rtos/alloc.h	Added sof_sys_heap_get() function declaration
zephyr/edf_schedule.c	Added heap assignment for EDF work queue thread
src/idc/zephyr_idc.c	Added heap assignment for IDC threads with explanatory comment
zephyr/test/vmh.c	Changed to LOG_MODULE_REGISTER; removed unused variable; fixed function calls
zephyr/test/CMakeLists.txt	Added CONFIG_METEORLAKE exclusion for boot test
zephyr/CMakeLists.txt	Removed boot_test.c source; added toolchain check for USERSPACE flag
app/debug_overlay.conf	Enabled ZTEST and SOF_BOOT_TEST configurations
src/include/sof/audio/module_adapter/module/generic.h	Fixed parameter name in documentation comment

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The test_done static variable is declared inside the function body within a conditional block. This placement is unconventional and could be confusing. Consider moving the variable declaration to the top of the function or to file scope for better readability and maintainability.

Suggested change

	/*
	* On platforms, using openmodules module libraries we run tests after
	* the modules are loaded. On other platforms after the first IPC.
	*/
	static bool test_done;
	static bool test_done;
	/*
	* On platforms, using openmodules module libraries we run tests after
	* the modules are loaded. On other platforms after the first IPC.
	*/

[Copilot]

Typo in comment: 'openmodules' should likely be 'open modules' or 'OpenModules' if it's a proper name.

Suggested change

	* On platforms, using openmodules module libraries we run tests after
	* On platforms, using open modules module libraries we run tests after

[lgirdwood]

@lrudyX not sure if QB is running the ztests ?

[lrudyX]

@lrudyX not sure if QB is running the ztests ?

Actually I don't know. @abonislawski FYI

[lyakh]

@lrudyX not sure if QB is running the ztests ?

Actually I don't know. @abonislawski FYI

as of our current approach - yes, there's no choice, the firmware is started and it runs the tests, unless a different configuration is used. But I think in this case the same configuration is used and it leads to the failures that we see.

[lyakh]

"Internal Intel CI" failing - same as in other PRs recently - TGL, MTL and LNL complete failure

[abonislawski]

QB is not using debug build so should not run boot tests, CI errs unrelated.

CONFIG_SOF_BOOT_TEST_SUPPORTED
CONFIG_SOF_BOOT_TEST_ALLOWED
CONFIG_SOF_BOOT_TEST

Its not unnecessarily overcomplicated?

[lyakh]

Its not unnecessarily overcomplicated?

@abonislawski I haven't found a better option. I want to have this testing enabled by the debug overlay. And it can be included by any platform. But some platform might not work with ZTEST (like MTL). So how do you do that? This is the simplest solution I've come up with - each platform that doesn't support ZTEST can say so and then even when the debug overlay is used with it, ZTEST won'b be enabled.

[lyakh]

Many jenkins tests are now failing the "check-sof-logger.sh" test where ZTEST is enabled, e.g. https://sof-ci.01.org/sofpr/PR10355/build17256/devicetest/index.html?model=LNLM_RVP_NOCODEC&testcase=check-sof-logger . Indeed this has been observed - with ZTEST enabled mtrace often stays empty when loading modules, but works as expected when more activity takes place and new output is created:
https://sof-ci.01.org/sofpr/PR10355/build17256/devicetest/index.html?model=LNLM_RVP_SDW&testcase=check-sof-logger
Maybe the test should be modified not to fail in such cases.

[abonislawski]

Its not unnecessarily overcomplicated?

@abonislawski I haven't found a better option. I want to have this testing enabled by the debug overlay. And it can be included by any platform. But some platform might not work with ZTEST (like MTL). So how do you do that? This is the simplest solution I've come up with - each platform that doesn't support ZTEST can say so and then even when the debug overlay is used with it, ZTEST won'b be enabled.

CONFIG_SOF_BOOT_TEST + CONFIG_SOF_BOOT_TEST_SUPPORTED is not going to work?

CONFIG_SOF_BOOT_TEST
default n
depends on SOF_BOOT_TEST_SUPPORTED

[lyakh]

Its not unnecessarily overcomplicated?

@abonislawski I haven't found a better option. I want to have this testing enabled by the debug overlay. And it can be included by any platform. But some platform might not work with ZTEST (like MTL). So how do you do that? This is the simplest solution I've come up with - each platform that doesn't support ZTEST can say so and then even when the debug overlay is used with it, ZTEST won't be enabled.

CONFIG_SOF_BOOT_TEST + CONFIG_SOF_BOOT_TEST_SUPPORTED is not going to work?

CONFIG_SOF_BOOT_TEST default n depends on SOF_BOOT_TEST_SUPPORTED

@abonislawski not the way I want it - I want to have CONFIG_ZTEST=n by default in non-debug cases

[lyakh]

"Internal CI:" one test failed on PTL (4 times?) with a timeout, @lrudyX any idea?

[lrudyX]

"Internal CI:" one test failed on PTL (4 times?) with a timeout, @lrudyX any idea?

Possible wrong DUT state after testing other PR ? I reset DUT and rerun

[lyakh]

"Internal CI:" one test failed on PTL (4 times?) with a timeout, @lrudyX any idea?

Possible wrong DUT state after testing other PR ? I reset DUT and rerun

@lrudyX thanks! I've tried the same test on a lab (SDW) device with stock firmware, and got the same error "HDA controller: codec not responding!" - can it be that your device is also configured as SDW? What exactly are you rerunning - just that test or all of them?

[lyakh]

@lrudyX now PTL is completely red... And BTW now https://sof-ci.01.org/sof-pr-viewer/#/build/PR10363/build14791233 has the same HDA timeout error and that PR shouldn't be able to cause any CI errors as @lgirdwood has pointed out

[lyakh]

@lrudyX sorry to bother you again, but https://sof-ci.01.org/sof-pr-viewer/#/build/PR10355/build14793276 looks worse than anything I've seen from QB until now

[lgirdwood]

@lrudyX other CIs passing, false positive ?

[lrudyX]

@lrudyX other CIs passing, false positive ?

Rerun tests for clearance

[lrudyX]

@lrudyX other CIs passing, false positive ?

Rerun tests for clearance

One test failed - not related

[lgirdwood]

@lrudyX other CIs passing, false positive ?

Rerun tests for clearance

One test failed - not related

Thanks - merged.