-
Notifications
You must be signed in to change notification settings - Fork 314
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
Document (overlapping) codenames for toolchains, platforms, Kconfigurations, signing schemes, etc. #3491
Comments
@marc-hb there is a platform description table in sof-docs - this info could be added in new columns. They are product names but also used for fw and toolchain config. |
These "accidental" 1:1:1 mappings seem pretty bad. Because they "accidentally" work until they don't: Short of renaming everything to tgl-toolchain, tgl-kconfig, etc., some documentation would really help mitigate. |
Thanks to thesofproject/sof-test#428 for this useful "bookmark": https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/sof-pci-dev.c |
As reported in thesofproject#3491, there is confusion between platform names, CPU names, PCH names, toolchain names, signing schemes and what not. For instance in "build_apl_gcc/sof-apl.ri", the first "apl" matches the name of a defconfig file while the second "apl" matches the name of a signing scheme. When building out-of-source, there is no reason to vary the filenames of the output depending on the build configuration, changing the name of the build directory is enough. This simplifies automation logic including the next commit that adds a new install/GNUmakefile. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As reported in thesofproject#3491, there is confusion between platform names, CPU names, PCH names, toolchain names, signing schemes and what not. For instance in "build_apl_gcc/sof-apl.ri", the first "apl" matches the name of a defconfig file while the second "apl" matches the name of a signing scheme. When building out-of-source, there is no reason to vary the filenames of the output depending on the build configuration, changing the name of the build directory is enough. This simplifies automation logic including the next commit that adds a new install/GNUmakefile. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As reported in #3491, there is confusion between platform names, CPU names, PCH names, toolchain names, signing schemes and what not. For instance in "build_apl_gcc/sof-apl.ri", the first "apl" matches the name of a defconfig file while the second "apl" matches the name of a signing scheme. When building out-of-source, there is no reason to vary the filenames of the output depending on the build configuration, changing the name of the build directory is enough. This simplifies automation logic including the next commit that adds a new install/GNUmakefile. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As reported in thesofproject#3491, there is confusion between platform names, CPU names, PCH names, toolchain names, signing schemes and what not. For instance in "build_apl_gcc/sof-apl.ri", the first "apl" matches the name of a defconfig file while the second "apl" matches the name of a signing scheme. When building out-of-source, there is no reason to vary the filenames of the output depending on the build configuration, changing the name of the build directory is enough. This simplifies automation logic including the next commit that adds a new install/GNUmakefile. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 0e60ec8)
As reported in thesofproject#3491, there is confusion between platform names, CPU names, PCH names, toolchain names, signing schemes and what not. For instance in "build_apl_gcc/sof-apl.ri", the first "apl" matches the name of a defconfig file while the second "apl" matches the name of a signing scheme. When building out-of-source, there is no reason to vary the filenames of the output depending on the build configuration, changing the name of the build directory is enough. This simplifies automation logic including the next commit that adds a new install/GNUmakefile. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 0e60ec8)
As reported in #3491, there is confusion between platform names, CPU names, PCH names, toolchain names, signing schemes and what not. For instance in "build_apl_gcc/sof-apl.ri", the first "apl" matches the name of a defconfig file while the second "apl" matches the name of a signing scheme. When building out-of-source, there is no reason to vary the filenames of the output depending on the build configuration, changing the name of the build directory is enough. This simplifies automation logic including the next commit that adds a new install/GNUmakefile. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 0e60ec8)
ADL and ADL-S binaries share FW build configuration with TGL and TGL-H. See also issue thesofproject#3491 and commit 15e03fd ("config: intel: use PCH name for tigerlake") and the corresponding review in PR thesofproject#3451. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
ADL and ADL-S binaries share FW build configuration with TGL and TGL-H. See also issue thesofproject#3491 and commit 15e03fd ("config: intel: use PCH name for tigerlake") and the corresponding review in PR thesofproject#3451. Signed-off-by: Marc Herbert <marc.herbert@intel.com> (cherry picked from commit 5a7a135)
These links helped me a little: |
@greg-intel feel free to add links to these in sof-docs if not already stated. |
What do "TGL" or "CHT" mean? Are they Intel SoCs, PCH codenames, Kconfigurations, toolchain names, signing schemes? Probably a bit of everything depending on the context, no one knows for sure. No one except @jajanusz , who agreed in #3451 (comment) that some documentation is really needed. Quoting myself from there:
The text was updated successfully, but these errors were encountered: