You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.
@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.
@plbossart we do need the ext_manifest for ICL to enable ICCMAX during FW boot. Should we tie it with a minimum ABI requirement?
@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.
@plbossart we do need the ext_manifest for ICL to enable ICCMAX during FW boot. Should we tie it with a minimum ABI requirement?
Oh, because you need to know the information before getting the information from firmware in the SRAM window?
If yes, we are indeed looking at a minimum ABI for ICL and TGL, and we need a 1.6 release that implements this. @lgirdwood FYI
@plbossart The end result of last ext-manifest deployment discussion was to do it on a platform basis. I.e. starting with platform N (which is not supported by any old kernels), all SOF FW released for platform N will have ext-manifest enabled. Nothing will break as any kernel that could be used on platform N systems, will also support extended manifest in firmware binary.
However, ICL is problematic as it is supported in multiple major kernel revisions which support ICL but do not support SOF ext-manifest descriptions.
But given the concrete need to have this, yes, we should start at next SOF release (1.6. ) to build the ICL binary with ext-manifest. For Linux distros, this in practise means they cannot update SOF FW unless they update the kernel to 5.8 (or newer, or backport the ext-manifest series).
@kv2019i given all the firmware panics on HDaudio platforms, everyone will have to jump to firmware 1.6, including distros already on 5.4/5.5. 5.8 isn't going to be used for some time, it's barely out of the oven and the stable branch isn't updated yet.
We have to find a way to solve this. Maybe e.g. work with the stable branch folks so that this series is added - we could say it's a hardware-related requirement that forces folks to take the ext_manifest patches.
Activity
plbossart commentedon Jul 22, 2020
@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.
ranj063 commentedon Jul 22, 2020
@plbossart we do need the ext_manifest for ICL to enable ICCMAX during FW boot. Should we tie it with a minimum ABI requirement?
plbossart commentedon Jul 23, 2020
Oh, because you need to know the information before getting the information from firmware in the SRAM window?
If yes, we are indeed looking at a minimum ABI for ICL and TGL, and we need a 1.6 release that implements this. @lgirdwood FYI
kv2019i commentedon Aug 26, 2020
@plbossart The end result of last ext-manifest deployment discussion was to do it on a platform basis. I.e. starting with platform N (which is not supported by any old kernels), all SOF FW released for platform N will have ext-manifest enabled. Nothing will break as any kernel that could be used on platform N systems, will also support extended manifest in firmware binary.
However, ICL is problematic as it is supported in multiple major kernel revisions which support ICL but do not support SOF ext-manifest descriptions.
But given the concrete need to have this, yes, we should start at next SOF release (1.6. ) to build the ICL binary with ext-manifest. For Linux distros, this in practise means they cannot update SOF FW unless they update the kernel to 5.8 (or newer, or backport the ext-manifest series).
plbossart commentedon Aug 26, 2020
@kv2019i given all the firmware panics on HDaudio platforms, everyone will have to jump to firmware 1.6, including distros already on 5.4/5.5. 5.8 isn't going to be used for some time, it's barely out of the oven and the stable branch isn't updated yet.
We have to find a way to solve this. Maybe e.g. work with the stable branch folks so that this series is added - we could say it's a hardware-related requirement that forces folks to take the ext_manifest patches.
fredoh9 commentedon Sep 28, 2020
Duplicated, #2434 has more discussion. We can close this.
fredoh9 commentedon Nov 16, 2020
#2548 merged