Hello,
Moving forward the submodule pointers of the microcode [1] or Intel FSP [2][3] repository will make the Google boards (ChromeOS builds?) failing because the FSP does not fit into their flash region anymore.
How do we deal with that issue? I think there are two options:
* Make the flash regions bigger * Disable ChromeOS builds for upstream
Best
Felix
--- [1] https://review.coreboot.org/c/coreboot/+/75631 [2] https://review.coreboot.org/c/coreboot/+/74242 [3] https://review.coreboot.org/c/coreboot/+/74442
Another idea...
We could switch the default value of FSP_USE_REPO for ChromeOS builds so that it's disabled by default. It seems the header files are still taken from the repo then.
How does that sound?
On Tue, 2023-06-06 at 23:12 +0000, Felix Singer wrote:
Hello,
Moving forward the submodule pointers of the microcode [1] or Intel FSP [2][3] repository will make the Google boards (ChromeOS builds?) failing because the FSP does not fit into their flash region anymore.
How do we deal with that issue? I think there are two options:
* Make the flash regions bigger * Disable ChromeOS builds for upstream
Best
Felix
[1] https://review.coreboot.org/c/coreboot/+/75631 [2] https://review.coreboot.org/c/coreboot/+/74242 [3] https://review.coreboot.org/c/coreboot/+/74442
Dear Felix,
Thank you for bringing that up on the list.
Am 07.06.23 um 01:23 schrieb Felix Singer:
Another idea...
We could switch the default value of FSP_USE_REPO for ChromeOS builds so that it's disabled by default. It seems the header files are still taken from the repo then.
How does that sound?
On Tue, 2023-06-06 at 23:12 +0000, Felix Singer wrote:
Hello,
Moving forward the submodule pointers of the microcode [1] or Intel FSP [2][3] repository will make the Google boards (ChromeOS builds?) failing because the FSP does not fit into their flash region anymore.
How do we deal with that issue? I think there are two options:
* Make the flash regions bigger * Disable ChromeOS builds for upstream
Excuse my ignorance. How can all Google boards fail? Aren’t there Intel hardware generations where FSP should not be updated anymore?
Also, how much space is missing? Why did FSP grow that much?
Could a third option be to ask the FSP folks to provide smaller blobs?
Kind regards,
Paul
[1] https://review.coreboot.org/c/coreboot/+/75631 [2] https://review.coreboot.org/c/coreboot/+/74242 [3] https://review.coreboot.org/c/coreboot/+/74442
Hi Paul,
On Wed, 2023-06-07 at 08:09 +0200, Paul Menzel wrote:
Excuse my ignorance. How can all Google boards fail? Aren’t there Intel hardware generations where FSP should not be updated anymore?
I was unclear, sorry. Only the Alderlake boards are affected as it seems.
Also, how much space is missing? Why did FSP grow that much?
I didn't check. As Subrata explained in his comments[1], Google seems to use some sort of customized FSP binary, which is built from an internal repository and also stripped. So I was thinking that might be the reason for that issue, because related ChromeOS flashmaps are optimized for their FSP binary and not for the one from the public Intel repo.
Could a third option be to ask the FSP folks to provide smaller blobs?
I don't know how feasible that is. From recent discussions about releasing FSP binaries, it's even a thing to get *any* FSP binary uploaded on the FSP repo.
However, I think the best compromise is the one I wrote in my second mail, which is to use only the FSP headers from the repo but not the binaries for ChromeOS builds. Customized binaries can still be added by the build system or manually.
For the coreboot CI it shouldn't make much difference (probably not anything?) because it does only build-tests and there are still enough other boards to build-test that part.
Best
Felix
Hi,
On 08.06.23 00:55, Felix Singer wrote:
However, I think the best compromise is the one I wrote in my second mail, which is to use only the FSP headers from the repo but not the binaries for ChromeOS builds. Customized binaries can still be added by the build system or manually.
it's also the most promising short-term solution that I can see. Alas, I didn't find a good way to do it without adding yet another Kconfig (see draft below).
One question is if anybody actually builds for ChromeOS with only the publicly available resources? If yes, updating the FSP submodule would be a regression to them. One way to maintain the status quo for boards with limited flash space would be to use individual submodules. e.g. src/mainboard/vendor/board/fsp ?
Nico
diff --git a/Makefile.inc b/Makefile.inc index abf47d4fae45..0fdeeb736b7f 100644 --- a/Makefile.inc +++ b/Makefile.inc @@ -208,7 +208,7 @@ ifeq ($(CONFIG_USE_BLOBS),y) # until expressly requested and enabled with --checkout forgetthis:=$(shell git submodule update --init --checkout 3rdparty/blobs $(quiet_errors)) forgetthis:=$(shell git submodule update --init --checkout 3rdparty/intel-microcode $(quiet_errors)) -ifeq ($(CONFIG_FSP_USE_REPO),y) +ifneq ($(filter y,$(CONFIG_FSP_REPO_HEADERS) $(CONFIG_FSP_USE_REPO)),) forgetthis:=$(shell git submodule update --init --checkout 3rdparty/fsp $(quiet_errors)) endif ifeq ($(CONFIG_USE_AMD_BLOBS),y) diff --git a/src/drivers/intel/fsp2_0/Kconfig b/src/drivers/intel/fsp2_0/Kconfig index 378f4fb3301d..b42e9fceb932 100644 --- a/src/drivers/intel/fsp2_0/Kconfig +++ b/src/drivers/intel/fsp2_0/Kconfig @@ -55,9 +55,22 @@ config HAVE_INTEL_FSP_REPO and available in 3rdparty/fsp/. When selecting this option, the platform must also set FSP_HEADER_PATH and FSP_FD_PATH correctly.
+config FSP_REPO_HEADERS + bool "Use header files of the Intel FSP repository on GitHub" + depends on HAVE_INTEL_FSP_REPO + default y + help + Select this option to use the default FSP headers + found in the IntelFsp GitHub repository at + + https://github.com/IntelFsp/FSP/ + + If unsure, say Y. + config FSP_USE_REPO bool "Use binaries of the Intel FSP repository on GitHub" depends on HAVE_INTEL_FSP_REPO + select FSP_REPO_HEADERS select FSP_FULL_FD default y help @@ -69,7 +82,7 @@ config FSP_USE_REPO If unsure, say Y.
config FSP_HEADER_PATH - string "Location of FSP headers" if !FSP_USE_REPO + string "Location of FSP headers" if !FSP_REPO_HEADERS help Include directory with the FSP ABI header files.
diff --git a/src/soc/intel/alderlake/Kconfig b/src/soc/intel/alderlake/Kconfig index 0e5a671be2a9..d75639843539 100644 --- a/src/soc/intel/alderlake/Kconfig +++ b/src/soc/intel/alderlake/Kconfig @@ -390,6 +390,9 @@ config CONSOLE_CBMEM_BUFFER_SIZE default 0x100000 if CONSOLE_SERIAL default 0x40000
+config FSP_USE_REPO + default !CHROMEOS + config FSP_TYPE_IOT bool default n
On Thu, Jun 8, 2023 at 6:42 AM Nico Huber nico.h@gmx.de wrote:
Hi,
On 08.06.23 00:55, Felix Singer wrote:
However, I think the best compromise is the one I wrote in my second mail, which is to use only the FSP headers from the repo but not the binaries for ChromeOS builds. Customized binaries can still be added by the build system or manually.
I'm forced to agree as well
it's also the most promising short-term solution that I can see. Alas, I didn't find a good way to do it without adding yet another Kconfig (see draft below).
One question is if anybody actually builds for ChromeOS with only the publicly available resources? If yes, updating the FSP submodule would be a regression to them. One way to maintain the status quo for boards with limited flash space would be to use individual submodules. e.g. src/mainboard/vendor/board/fsp ?
I'm not aware of anyone who does
Nico
diff --git a/Makefile.inc b/Makefile.inc index abf47d4fae45..0fdeeb736b7f 100644 --- a/Makefile.inc +++ b/Makefile.inc @@ -208,7 +208,7 @@ ifeq ($(CONFIG_USE_BLOBS),y) # until expressly requested and enabled with --checkout forgetthis:=$(shell git submodule update --init --checkout 3rdparty/blobs $(quiet_errors)) forgetthis:=$(shell git submodule update --init --checkout 3rdparty/intel-microcode $(quiet_errors)) -ifeq ($(CONFIG_FSP_USE_REPO),y) +ifneq ($(filter y,$(CONFIG_FSP_REPO_HEADERS) $(CONFIG_FSP_USE_REPO)),) forgetthis:=$(shell git submodule update --init --checkout 3rdparty/fsp $(quiet_errors)) endif ifeq ($(CONFIG_USE_AMD_BLOBS),y) diff --git a/src/drivers/intel/fsp2_0/Kconfig b/src/drivers/intel/fsp2_0/Kconfig index 378f4fb3301d..b42e9fceb932 100644 --- a/src/drivers/intel/fsp2_0/Kconfig +++ b/src/drivers/intel/fsp2_0/Kconfig @@ -55,9 +55,22 @@ config HAVE_INTEL_FSP_REPO and available in 3rdparty/fsp/. When selecting this option, the platform must also set FSP_HEADER_PATH and FSP_FD_PATH correctly.
+config FSP_REPO_HEADERS
bool "Use header files of the Intel FSP repository on GitHub"depends on HAVE_INTEL_FSP_REPOdefault yhelpSelect this option to use the default FSP headersfound in the IntelFsp GitHub repository athttps://github.com/IntelFsp/FSP/If unsure, say Y.config FSP_USE_REPO bool "Use binaries of the Intel FSP repository on GitHub" depends on HAVE_INTEL_FSP_REPO
select FSP_REPO_HEADERS select FSP_FULL_FD default y help@@ -69,7 +82,7 @@ config FSP_USE_REPO If unsure, say Y.
config FSP_HEADER_PATH
string "Location of FSP headers" if !FSP_USE_REPO
string "Location of FSP headers" if !FSP_REPO_HEADERS help Include directory with the FSP ABI header files.diff --git a/src/soc/intel/alderlake/Kconfig b/src/soc/intel/alderlake/Kconfig index 0e5a671be2a9..d75639843539 100644 --- a/src/soc/intel/alderlake/Kconfig +++ b/src/soc/intel/alderlake/Kconfig @@ -390,6 +390,9 @@ config CONSOLE_CBMEM_BUFFER_SIZE default 0x100000 if CONSOLE_SERIAL default 0x40000
+config FSP_USE_REPO
default !CHROMEOSconfig FSP_TYPE_IOT bool default n
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Felix Singer -
Matt DeVillier -
Nico Huber -
Paul Menzel