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

Kconfig: don't fall back on CONFIG_TIGERLAKE #7763

Merged
merged 4 commits into from
Jun 13, 2023

Conversation

marc-hb
Copy link
Collaborator

@marc-hb marc-hb commented Jun 8, 2023

There's really no reason to fall back on a default "platform" and pick up a bunch of other, totally random settings.

Now the following command fails immediately with a useful platform not defined error message instead of stopping with a cryptic platform/trace/trace.h: No such file or directory after successfully compiling half the .c files in a Frankenstein CONFIG_uration.

  west build -p --board mimx8mm_evk_a53 modules/audio/sof/app

More context in #7192.

dbaluta
dbaluta previously approved these changes Jun 8, 2023
@marc-hb marc-hb requested review from andyross and a team June 8, 2023 18:56
@marc-hb

This comment was marked as resolved.

andyross
andyross previously approved these changes Jun 8, 2023
Copy link
Contributor

@andyross andyross left a comment

Choose a reason for hiding this comment

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

Makes sense. FWIW in the long term it's probably best to to some work to unify the SOF "platform" choice with the Zephyr-side "board"/"soc"/"arch" tuple.

As regards the fuzzer: there were definitely some leaky kconfigs in there. But for that application specifically, it seemed worthwhile to make sure as much of the firmware source base gets included as it would for the real device, even if the configuration is a little non-orthogonal.

@@ -18,6 +18,8 @@ elseif(CONFIG_MT8188)
set(platform_folder mt8188)
elseif(CONFIG_MT8195)
set(platform_folder mt8195)
else()
message(FATAL_ERROR "Platform not defined, check your Kconfiguration?")
Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW: you could move this to a build-time #error in a C file somewhere to avoid having to do this in two different cmake schemes.

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 respectfully but strongly disagree. I think it's better to check and fail as early as possible. Also, C compilation is parallelized and typically unreadable before adding -j1 whereas CMake configuration is single-threaded. I think it's also better to always have a "default" error clause in a case/switch, and/or to check a variable is not empty before using it (the -I platform/${EMPTY}/include wasted a large amount of my time!)

I avoid CMake as much as possible but the duplication here is only one line. It's only because Zephyr versus non-Zephyr so it won't grow larger.

Finally, in which C file?

All this being said, if there is some C file where this check could be useful TOO then why not; "defence in depth".

marc-hb added 4 commits June 8, 2023 23:17
Use get_filename_component() to get the basename and remove the
$platform_folder special case for CONFIG_RENOIR and
CONFIG_REMBRANDT. Zero change, binaries are identical.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This saves a lot of backslashes and is easier to read. Zero change.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Don't rely on some semi-random default value.

The final `zephyr/.config` and binaries are strictly identical.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
There's really no reason to fall back on a default "platform" and pick
up a bunch of other, totally random settings.

Now the following command fails immediately with a useful `platform not
defined` error message instead of stopping with a cryptic
`platform/trace/trace.h: No such file or directory` after successfully
compiling half the .c files in a Frankenstein CONFIG_uration.

```
  west build -p --board mimx8mm_evk_a53 modules/audio/sof/app
```

More context in thesofproject#7192.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
@marc-hb
Copy link
Collaborator Author

marc-hb commented Jun 9, 2023

Totally unrelated test failures in https://sof-ci.01.org/sofpr/PR7763/build9189/devicetest https://sof-ci.01.org/sofpr/PR7763/build9190/devicetest. This PR does not affect these platforms.

@marc-hb marc-hb marked this pull request as ready for review June 9, 2023 00:31
@marc-hb marc-hb dismissed stale reviews from andyross and dbaluta June 9, 2023 00:32

significant changes

@marc-hb
Copy link
Collaborator Author

marc-hb commented Jun 9, 2023

All LNL tests failed in https://sof-ci.01.org/sof-pr-viewer/#/build/PR7763/build12144879, just like they did in totally different #7772, so this is clearly unrelated.

@marc-hb
Copy link
Collaborator Author

marc-hb commented Jun 9, 2023

Thanks to whoever (@wszypelt ?) restored the LNL device. Now the newer https://sof-ci.01.org/sof-pr-viewer/#/build/PR7763/build12147803 is mostly passing except for this teardown failure below that occurred in only two tests (all other tests in the same run are green). @wszypelt this feels like a bug in the test framework or infrastructure; you may want to let the validation team know about it.

In any case it's totally unrelated to this PR.

# SAME test is both PASSED and ERROR, that's funny
06:58:34,859 INFO  - [gw0] [100%] PASSED tests/ace/fw_116_sdw_low_level/test_04_sdw_transfer_loopback_aggregation.py::TestSdwTransferLoopbackAggregation::test_116_04_sdw_loopback_aggregation_capture[0-source_PDI_4_to_sink_PDI_5_and_3-16000Hz_24in32bit_2ch]
06:58:35,126 INFO  - [gw0] [100%] ERROR  tests/ace/fw_116_sdw_low_level/test_04_sdw_transfer_loopback_aggregation.py::TestSdwTransferLoopbackAggregation::test_116_04_sdw_loopback_aggregation_capture[0-source_PDI_4_to_sink_PDI_5_and_3-16000Hz_24in32bit_2ch]

06:58:35,127 INFO  - _ ERROR at teardown of TestSdwTransferLoopbackAggregation.test_116_04_sdw_loopback_aggregation_capture[0-source_PDI_4_to_sink_PDI_5_and_3-16000Hz_24in32bit_2ch] _

06:58:35,127 INFO  - cavs_scripts-py\utilities\test_logger.py:404: in iteration_end
06:58:35,127 INFO  - l_handler.logger.close_current_iteration()
06:58:35,127 INFO  - cavs_scripts-py\utilities\loggers\weblogger_lite\weblogger_lite.py:253: in close_current_iteration
06:58:35,127 INFO  - self.iterations_files.append(self.current_iteration.close(passed=self.current_iteration_passed(),
06:58:35,127 INFO  - cavs_scripts-py\utilities\loggers\weblogger_lite\weblogger_lite.py:114: in close
06:58:35,127 INFO  - with open(iter_path_abs, "w") as file:
06:58:35,127 INFO  - E FileNotFoundError: [Errno 2] No such file or directory: 'C:\\history\\cAVS\\LABELED\\SMOKE_IPC4_pull-7763-merge_1405642_7421_7431\\116_04_TestSdwTransferLoopbackAggregation\\iters\\1_TestSdwTransferLoopbackAggregation_test_116_04_sdw_loopback_aggregation_capture[0-source_PDI_4_to_sink_PDI_5_and_3-16000Hz_24in32bit_2ch].html'

@wszypelt
Copy link

@marc-hb Thanks for the info, I'll debug it today

@wszypelt
Copy link

@marc-hb It worked, it was a tricky problem with path lengths, depending on the number of reruns, some PR passed, some not. Anyway, everything should work now :)

@marc-hb
Copy link
Collaborator Author

marc-hb commented Jun 12, 2023

Thanks for the info, I'll debug it today

Glad I could report a actionable bug! Thanks for fixing the issue, https://sof-ci.01.org/sof-pr-viewer/#/build/PR7763/build12159888 is all green now.

@kv2019i kv2019i merged commit c7af3c5 into thesofproject:main Jun 13, 2023
@marc-hb marc-hb deleted the no-default-platform branch June 24, 2023 05:27
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