GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/arch/x86/Kconfig

332 lines
7.8 KiB
Text
Raw Normal View History

arch/x86/Kconfig: Add license header Add license header with copyright of the original authors. Change-Id: I8c55bb38a2a2a387ad2461e11d402c7392fa2497 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/8691 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:29:35 +01:00
##
src/arch/x86: Convert to SPDX license header This also drops individual copyright notices, all mentioned authors in that part of the tree are listed in AUTHORS. Change-Id: Ib5a92bb46ff2b9d2928aae3763daec71747044c2 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39284 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2020-03-04 15:10:45 +01:00
## SPDX-License-Identifier: GPL-2.0-only
arch/x86/Kconfig: Add license header Add license header with copyright of the original authors. Change-Id: I8c55bb38a2a2a387ad2461e11d402c7392fa2497 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/8691 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:29:35 +01:00
## This file is part of the coreboot project.
##
kconfig: drop intermittend forwarder files With kconfig understanding wildcards, we don't need Kconfig files that just include other Kconfig files anymore. Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9298 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-04-04 01:58:28 +02:00
config ARCH_X86
bool
select PCI
arch/x86: Always select RELOCATABLE_MODULES All boards except those with NO_RELOCATABLE_RAMSTAGE or explicit select already had this feature built. Change-Id: I838e12141243ec49c2555c09269e07476eb0cfad Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/26816 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-03 21:48:51 +02:00
select RELOCATABLE_MODULES
kconfig: drop intermittend forwarder files With kconfig understanding wildcards, we don't need Kconfig files that just include other Kconfig files anymore. Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/9298 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-04-04 01:58:28 +02:00
Add x64 support to src/arch/x86/Kconfig Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8692 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:34:03 +01:00
# stage selectors for x86
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
config ARCH_BOOTBLOCK_X86_32
Move the HAVE_ARCH_* config options from src/arch/x86 to src/. The options that keep track of whether there are arch versions of the standard string functions shouldn't be in the arch/x86 directory since they apply to all architectures. Move them into the higher level, shared Kconfig defaulting to off. Then, in each applicable arch (currently all of them) they can be selected to on. Change-Id: I7ea64a583230fdc28773f17fd7cc23e0f0a5f3d6 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3760 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-07 22:52:37 +02:00
bool
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
select ARCH_X86
vboot2: add verstage This reverts the revert commit 5780d6f3876723b94fbe3653c9d87dad6330862e and fixes the build issue that cuased it to be reverted. Verstage will host vboot2 for firmware verification. It's a stage in the sense that it has its own set of toolchains, compiler flags, and includes. This allows us to easily add object files as needed. But it's directly linked to bootblock. This allows us to avoid code duplication for stage loading and jumping (e.g. cbfs driver) for the boards where bootblock has to run in a different architecture (e.g. Tegra124). To avoid name space conflict, verstage symbols are prefixed with verstage_. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac Original-Reviewed-on: https://chromium-review.googlesource.com/204376 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf Reviewed-on: http://review.coreboot.org/8224 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-14 19:51:47 +01:00
config ARCH_VERSTAGE_X86_32
bool
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
select ARCH_X86
vboot2: add verstage This reverts the revert commit 5780d6f3876723b94fbe3653c9d87dad6330862e and fixes the build issue that cuased it to be reverted. Verstage will host vboot2 for firmware verification. It's a stage in the sense that it has its own set of toolchains, compiler flags, and includes. This allows us to easily add object files as needed. But it's directly linked to bootblock. This allows us to avoid code duplication for stage loading and jumping (e.g. cbfs driver) for the boards where bootblock has to run in a different architecture (e.g. Tegra124). To avoid name space conflict, verstage symbols are prefixed with verstage_. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac Original-Reviewed-on: https://chromium-review.googlesource.com/204376 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf Reviewed-on: http://review.coreboot.org/8224 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-14 19:51:47 +01:00
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
config ARCH_ROMSTAGE_X86_32
bool
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
select ARCH_X86
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
toolchain: Add POSTCAR as a stage we have a toolchain for Fixes building vb2lib for postcar. Since postcar is an x86ism, add the Kconfig options only for x86. Change-Id: Ib92436bc7270c24689dcf01a47f0c6fe7661814b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/29395 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-31 14:24:47 +01:00
config ARCH_POSTCAR_X86_32
bool
default ARCH_ROMSTAGE_X86_32 && POSTCAR_STAGE
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
config ARCH_RAMSTAGE_X86_32
bool
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
select ARCH_X86
Move the HAVE_ARCH_* config options from src/arch/x86 to src/. The options that keep track of whether there are arch versions of the standard string functions shouldn't be in the arch/x86 directory since they apply to all architectures. Move them into the higher level, shared Kconfig defaulting to off. Then, in each applicable arch (currently all of them) they can be selected to on. Change-Id: I7ea64a583230fdc28773f17fd7cc23e0f0a5f3d6 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3760 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-07 22:52:37 +02:00
Add x64 support to src/arch/x86/Kconfig Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8692 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:34:03 +01:00
# stage selectors for x64
config ARCH_BOOTBLOCK_X86_64
bool
select ARCH_X86
config ARCH_VERSTAGE_X86_64
bool
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
select ARCH_X86
Add x64 support to src/arch/x86/Kconfig Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8692 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:34:03 +01:00
config ARCH_ROMSTAGE_X86_64
bool
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
select ARCH_X86
Add x64 support to src/arch/x86/Kconfig Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8692 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:34:03 +01:00
toolchain: Add POSTCAR as a stage we have a toolchain for Fixes building vb2lib for postcar. Since postcar is an x86ism, add the Kconfig options only for x86. Change-Id: Ib92436bc7270c24689dcf01a47f0c6fe7661814b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/29395 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-31 14:24:47 +01:00
config ARCH_POSTCAR_X86_64
bool
default ARCH_ROMSTAGE_X86_64 && POSTCAR_STAGE
Add x64 support to src/arch/x86/Kconfig Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8692 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:34:03 +01:00
config ARCH_RAMSTAGE_X86_64
bool
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
select ARCH_X86
if ARCH_X86
Add x64 support to src/arch/x86/Kconfig Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8692 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-15 04:34:03 +01:00
cpu/qemu-x86: Add x86_64 bootblock support Add support for x86_64 bootblock on qemu. Introduce a new approach to long mode support. The previous patch set generated page tables at runtime and placed them in heap. The new approach places the page tables in memory mapped ROM. Introduce a new tool called pgtblgen that creates x86 long mode compatible page tables and writes those to a file. The file is included into the CBFS and placed at a predefined offset. Add assembly code to load the page tables, based on a Kconfig symbol and enter long in bootblock. The code can be easily ported to real hardware bootblock. Tested on qemu q35. Change-Id: Iec92c6cea464c97c18a0811e2e91bc22133ace42 Signed-off-by: Patrick Rudolph <siro@das-labor.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35680 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2019-09-28 17:44:01 +02:00
config ARCH_X86_64_PGTBL_LOC
hex "x86_64 page table location in CBFS"
depends on ARCH_BOOTBLOCK_X86_64
default 0xfffea000
help
The position where to place pagetables. Needs to be known at
compile time. Must not overlap other files in CBFS.
xcompile: Add a way to specify -march=i586 Instead of instructing users to edit xcompile when they want to build a quark platform, give the build a way to set -march=586 so that the quark code will build correctly. The Quark processor does not support the instructions introduced with the Pentium 6 architecture. Change-Id: I0ed69aadc515f86f76800180e0e33bcd75feac5a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13552 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
2016-02-02 01:33:37 +01:00
config USE_MARCH_586
def_bool n
help
Allow a platform or processor to select to be compiled using
the '-march=i586' option instead of the typical '-march=i686'
Various Kconfig fixes and improvements: - Add helps texts to multiple user-visible Kconfig options. - Improve some menu and option names. - PAYLOAD_NONE should come before PAYLOAD_ELF, so that you scroll down (instead of up) when changing "no payload" to "ELF payload" (more intuitive, IMHO). - s/cbfs/cbfstool/. - Add some TODO items where needed. - Put GDB_STUB in a "Debugging" menu, no options should be top-level. There'll be more debug options later, I'm pretty sure. - Start converting help texts which are not user-visible to #-comments. - Re-order some options for more intuitive menus. - Set ARCH_X86 and ARCH_POWERPC to "default n", each boards selects them. - "Maximum reboot count" should proabably not be user-selectable, or at most if CONFIG_EXPERT (yet to be added) is enabled. It does definately not need its own "Misc options" menu. - Set PCI_ROM_RUN and VGA_ROM_RUN to "default y", most users will want to run option ROMs. Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Uwe Hermann <uwe@hermann-uwe.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4734 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-07 18:15:40 +02:00
# This is an SMP option. It relates to starting up APs.
# It is usually set in mainboard/*/Kconfig.
# TODO: Improve description.
Revert "Use broadcast SIPI to startup siblings" This reverts commit 042c1461fb777e583e5de48edf9326e47ee5595f. It turned out that sending IPIs via broadcast doesn't work on Sandybridge. We tried to come up with a solution, but didn't found any so far. So revert the code for now until we have a working solution. Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714 Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/1381 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-29 19:18:03 +02:00
config AP_IN_SIPI_WAIT
bool
default n
Add dependency for CONFIG_AP_IN_SIPI_WAIT Change-Id: Ia20c138dae1fc1382abe74303e1117472c513d1d Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1779 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-10-15 22:38:09 +02:00
depends on ARCH_X86 && SMP
This is the final set of changes to allow rumba to build. Rumba is not tested. I also addressed questions raised by Uwe: TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 UDELAY_TSC Are now defined as booleans in src/cpu/x86/Kconfig and can be selected in the mainboard Kconfig. The remaining question of Uwe's is a deeper problem: --- We'll have to check if this works. From a quick glance the Rumba does not have the mmx related lines (which _are_ in Makefile.romccboard.inc, though): crt0-y += ../../../../src/cpu/x86/fpu/enable_fpu.inc crt0-y += ../../../../src/cpu/x86/mmx/enable_mmx.inc crt0-y += auto.inc crt0-y += ../../../../src/cpu/x86/mmx/disable_mmx.inc --- We're going to need a whole variant of this standard mainboard OR we're going to have to make (some) of the unconditional includes above conditional. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4618 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-29 04:59:35 +02:00
arch|cpu/x86: Add Kconfig option for x86 reset vector Prepare for an implementation supporting the reset vector in RAM and not the traditional 0xfffffff0. Add a Kconfig symbol that can be used in place of hardcoded values. Change-Id: I6a814f7179ee4251aeeccb2555221616e944e03d Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37485 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-11-02 00:30:05 +01:00
config X86_RESET_VECTOR
hex
depends on ARCH_X86
default 0xfffffff0
help
Specify the location of the x86 reset vector. In traditional devices
this must match the architectural reset vector to produce a bootable
image. Nontraditional designs may use this to position the reset
vector into its desired location.
x86: Introduce RESET_VECTOR_IN_RAM option Create a new Kconfig symbol that allows an x86 device to begin execution when its reset vector is in DRAM and not at the traditional 0xfffffff0. The implementation will follow later, this is just to setup various ENV_xxx definitions correctly for the build environment. Change-Id: I098ecf8bf200550db1e15f178f7661c1ac516dc5 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35004 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-04-23 00:26:23 +02:00
config RESET_VECTOR_IN_RAM
bool
depends on ARCH_X86
help
Select this option if the x86 soc implements custom code to handle the
reset vector in RAM instead of the traditional 0xfffffff0 location.
Fix support for RAM-less multi-processor init Fix regression after commit: 7dfe32c5408916b6cb23f1ec48e473e1c728d300 Only align 16-bit entry on platforms that really require it, indicated by selecting SIPI_VECTOR_IN_ROM in CPU Kconfig. Disable assertion test of AP_SIPI_VECTOR for platforms not depending on this feature. Build of romstage should be fixed to get the vector address from bootblock build automatically. Change-Id: Ide470833c0254df1a9ff708369ab1c095ccfb98d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/875 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-04-06 03:03:50 +02:00
# Aligns 16bit entry code in bootblock so that hyper-threading CPUs
# can boot AP CPUs to enable their shared caches.
config SIPI_VECTOR_IN_ROM
bool
default n
depends on ARCH_X86
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
# Set the rambase for systems that still need it, only 5 chipsets as of
# Sep 2018. This value was 0x100000, chosen to match the entry point
# of Linux 2.2 in 1999. The new value, 14 MiB, makes a lot more sense
# for as long as we need it; with luck, that won't be much longer.
# In the long term, both RAMBASE and RAMTOP should be removed.
# This value leaves more than 1 MiB which is required for fam10
# and broadwell_de.
Kconfig! Works on Kontron, qemu, and serengeti. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> tested on abuild only. Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12 17:00:51 +02:00
config RAMBASE
hex
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
default 0xe00000
Kconfig! Works on Kontron, qemu, and serengeti. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> tested on abuild only. Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12 17:00:51 +02:00
Define RAMTOP for x86 only This Kconfig is deprecated, new platforms need to locate ramstage stack in CBMEM instead. Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15189 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-06-15 01:25:00 +02:00
config RAMTOP
hex
selfboot: remove bounce buffers Bounce buffers used to be used in those cases where the payload might overlap coreboot. Bounce buffers are a problem for rampayloads as they need malloc. They are also an artifact of our x86 past before we had relocatable ramstage; only x86, out of the 5 architectures we support, needs them; currently they only seem to matter on the following chipsets: src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig The first three are obsolete or at least could be changed to avoid the need to have bounce buffers. The last two should change to no longer need them. In any event they can be fixed or pegged to a release which supports them. For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0xe00000 (14 Mib) which will put the non-relocatable x86 ramstage out of the way of any reasonable payload until we can get rid of it for good. 14 MiB was chosen after some discussion, but it does fit well: o Fits in the 16 MiB cacheable range coreboot sets up by default o Most small payloads are well under 14 MiB (even kernels!) o Most large payloads get loaded at 16 MiB (especially kernels!) With this change in place coreboot correctly still loads a bzImage payload. Werner reports that the 0xe00000 setting works on his broadwell systems. Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/28647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-09-16 18:59:54 +02:00
default 0x1000000
Define RAMTOP for x86 only This Kconfig is deprecated, new platforms need to locate ramstage stack in CBMEM instead. Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15189 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-06-15 01:25:00 +02:00
depends on ARCH_X86
arch/x86: Add option to disable default mmap_boot implementation On certain platforms, the boot media is either not memory-mapped, or not mapped at the top of 4G. This makes the default mmap_boot implementation unsuitable. Add an option to allow such platforms to define their own mapping implementation. Change-Id: I8293126fd9cc1fd3d75072f7811e659765348e4a Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/13319 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-27 18:27:30 +01:00
# Traditionally BIOS region on SPI flash boot media was memory mapped right below
# 4G and it was the last region in the IFD. This way translation between CPU
# address space to flash address was trivial. However some IFDs on newer SoCs
# have BIOS region sandwiched between descriptor and other regions. Turning off
# this option enables soc code to provide custom mmap_boot.c which can be used to
# implement complex translation.
config X86_TOP4G_BOOTMEDIA_MAP
bool
default y
X86: make the SIPI num_starts a config variable The code to figure out how to set num_starts was starting to get kludgy. It's a constant for a given CPU; constants should be constant; make it a config variable. This change includes an example of how to override it. Build but not boot tested; drivers welcome. Change-Id: Iddd906a707bb16251615c7b42f2bfb5a044379b4 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3796 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-07-22 20:17:18 +02:00
# This is something you almost certainly don't want to mess with.
# How many SIPIs do we send when starting up APs and cores?
# The answer in 2000 or so was '2'. Nowadays, on many systems,
# it is 1. Set a safe default here, and you can override it
# on reasonable platforms.
config NUM_IPI_STARTS
int
default 2
CBMEM: Add config CBMEM_TOP_BACKUP AGESA and binaryPI boards have no easy way to determine correct cbmem_top() location early enough when GFXUMA is enabled, so they will use these functions with EARLY_CBMEM_INIT as well. At the end of AmdInitPost() the decisions of UMA base and size have not been written to hardware yet. The decisions are stored inside AGESA heap object we cannot locate from coreboot proper until after AmdInitEnv(). Modify code such that weak backup functions are only defined for LATE_CBMEM_INIT; they are somewhat troublesome to handle. Change-Id: Ifef4f75b36bc6dee6cd56d1d9164281d9b2a4f2a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/19306 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-04-19 06:37:38 +02:00
config CBMEM_TOP_BACKUP
def_bool n
help
Platform implements non-volatile storage to cache cbmem_top()
over stage transitions and optionally also over S3 suspend.
x86: Configure premem cbmem console size Sometime preram cbmem logs are truncated due to lack of space (default preram cbmem console size is 0xc00). Provide Kconfig option to configure preram cbmem console size so that mainboard can configure it to required value. Change-Id: I221d9170c547d41d8bd678a3a8b3bca6a76ccd2e Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com> Reviewed-on: https://review.coreboot.org/17839 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-12-13 16:46:46 +01:00
config PRERAM_CBMEM_CONSOLE_SIZE
hex
default 0xc00
help
Increase this value if preram cbmem console is getting truncated
- Fix shortcoming in Kconfig when handling multiple "choice"s - move some variables where they belong Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6186 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-17 00:37:17 +01:00
config PC80_SYSTEM
bool
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
default y if ARCH_X86
- Fix shortcoming in Kconfig when handling multiple "choice"s - move some variables where they belong Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6186 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-17 00:37:17 +01:00
arch/x86: Add debug spinloop Conditionally add a debug spinloop to enable easy connection of JTAG debuggers. TEST=Build and run on Galileo Gen2 with a JTAG debugger. Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15127 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-07 17:45:17 +02:00
config BOOTBLOCK_DEBUG_SPINLOOP
bool
default n
help
Add a spin (JMP .) in bootblock_crt0.S during early bootblock to wait
for a JTAG debugger to break into the execution sequence.
Allow coreboot to initialize CMOS if checksum is invalid. If a file "cmos.default", type "cmos default"(0xaa) is in CBFS, a wrong checksum leads to coreboot rewriting the first 128 bytes (except for clock data) with the data in cmos.default, then reboots the system so every component of coreboot works with the same set of values. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6253 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-01-14 08:40:24 +01:00
config HAVE_CMOS_DEFAULT
def_bool n
Build system: Update HAVE_CMOS_DEFAULT - Don't build the cmos.default file into cbfs if USE_OPTION_TABLE isn't specified. - Don't allow HAVE_CMOS_DEFAULT if HAVE_OPTION_TABLE isn't set. Change-Id: I92401e892f09fc95d4b3fd7418cdbd10ed033fa8 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/17454 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2016-11-16 23:45:22 +01:00
depends on HAVE_OPTION_TABLE
Allow coreboot to initialize CMOS if checksum is invalid. If a file "cmos.default", type "cmos default"(0xaa) is in CBFS, a wrong checksum leads to coreboot rewriting the first 128 bytes (except for clock data) with the data in cmos.default, then reboots the system so every component of coreboot works with the same set of values. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6253 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-01-14 08:40:24 +01:00
config CMOS_DEFAULT_FILE
string
Provide sane Kconfig default for cmos.default. Without that fix we have with CONFIG_USE_OPTION_TABLE: OPTION cmos_layout.bin build/util/nvramtool/nvramtool -y /home/gnutoo/x86/coreboot-alix/src/mainboard/pcengines/alix1c/cmos.layout -L build/cmos_layout.bin make: *** No rule to make target `nvramtool', needed by `build/coreboot.pre1'. Stop. rm build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c That log was captured with make V=1 but the error also appear with make. Tested on the PC Engines ALIX.1C with the following commit (Change-Id: Ia87b090) [1]: PC Engines ALIX.1C: Add CMOS defaults. [1] http://review.coreboot.org/#/c/3323/ Change-Id: I548005a58f430ed7b6da5249a24bbdcae440a1e9 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3223 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2013-05-28 13:46:12 +02:00
default "src/mainboard/$(MAINBOARDDIR)/cmos.default"
Allow coreboot to initialize CMOS if checksum is invalid. If a file "cmos.default", type "cmos default"(0xaa) is in CBFS, a wrong checksum leads to coreboot rewriting the first 128 bytes (except for clock data) with the data in cmos.default, then reboots the system so every component of coreboot works with the same set of values. Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6253 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-01-14 08:40:24 +01:00
depends on HAVE_CMOS_DEFAULT
Via Epia-N and C3: Set ioapic delivery type in Kconfig The original comment says it's a Via C3 and not Epia requirement to deliver IOAPIC interrupts on APIC serial bus. Change-Id: I73c55755e0ec1ac5756b4ee7ccdfc8eb93184e4f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/435 Tested-by: build bot (Jenkins)
2012-03-16 19:28:15 +01:00
config IOAPIC_INTERRUPTS_ON_FSB
bool
default y if !IOAPIC_INTERRUPTS_ON_APIC_SERIAL_BUS
config IOAPIC_INTERRUPTS_ON_APIC_SERIAL_BUS
bool
default n
arch/x86: Define HPET_ADDRESS_OVERRIDE Symbol defined in via/cx700 but also used elsewhere. Change-Id: I31d6043e71dea474de00f609b9609a628ecc6eb8 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/26510 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2018-05-24 08:56:11 +02:00
config HPET_ADDRESS_OVERRIDE
def_bool n
hpet: common ACPI generation HPET's min ticks (minimum time between events to avoid losing interrupts) is chipset specific, so move it to Kconfig. Via also has a special base address, so move it as well. Apart from these (and the base address was already #defined), the table is very uniform. Change-Id: I848a2e2b0b16021c7ee5ba99097fa6a5886c3286 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1562 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
2012-10-05 21:54:38 +02:00
config HPET_ADDRESS
hex
default 0xfed00000 if !HPET_ADDRESS_OVERRIDE
Drop Kconfig.deprecated_options Both remaining options, DRIVERS_PS2_KEYBOARD and ID_SECTION_OFFSET are not likely to go away any time soon, so let's not keep them in Kconfig.deprecated_options but move them close to the code they control. Change-Id: I310b877c5b3d5a3444056641c4aee07a48c4c4be Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1839 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-14 00:04:12 +01:00
config ID_SECTION_OFFSET
hex
default 0x80
acpi: bring back ability to link DSDT into ramstage Bring back the ability to link in the DSDT. This is to help Chrome OS to switch over to a new upstream quickly (because some of the custom built mechanisms are a pain with tons of files). This is supposed to be temporary (famous last words), but I'd rather fix the lack of CBFS awareness in CrOS bit for good in the time I usually spend on keeping upstream and CrOS branches close. Change-Id: I7fa5540bbf5c568c4adca56a09c83b6c7e358ad5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10637 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-06-22 21:10:34 +02:00
Kconfig: Drop the C_ENVIRONMENT_BOOTBLOCK symbol The romcc bootblock will be deprecated soon and most platforms use C_ENVIRONMENT_BOOTBLOCK already. This patch drops the CONFIG_C_ENVIRONMENT_BOOTBLOCK symbol and adds CONFIG_ROMCC_BOOTBLOCK where needed. Change-Id: I773a76aade623303b7cd95ebe9b0411e5a7ecbaf Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37154 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
2019-11-22 21:01:30 +01:00
# 64KiB default bootblock size
x86: make bootblock size for C_ENVIRONMENT_BOOTBLOCK configurable Certain platforms may need to limit their bootblock size to within a given size because specific constraints. Allow the size to be provided by the mainboard or chipset by way of the arch Kconfig being processed after those. Change-Id: I46cc6315918cde575070fa2d3e2514f28008f575 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13691 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-02-11 21:36:19 +01:00
config C_ENV_BOOTBLOCK_SIZE
hex
default 0x10000
arch/x86: Allow soc/chipset to set linking address Until recently x86 romstage used to be linked at some default address. The address itself is not meaningful because the code was normally relocated at address calculated during insertion in CBFS. Since some newer SoC run romstage at CAR it became useful to link romstage code at some address in CAR and avoid relocation during build/run time altogether. Change-Id: I11bec142ab204633da0000a63792de7057e2eeaf Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/13860 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-02-29 07:04:51 +01:00
# Default address romstage is to be linked at
config ROMSTAGE_ADDR
hex
default 0x2000000
# Default address verstage is to be linked at
config VERSTAGE_ADDR
hex
default 0x2000000
arch/x86: introduce postcar stage/phase Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-18 18:21:23 +01:00
# Use the post CAR infrastructure for tearing down cache-as-ram
src/arch: Capitalize CPU, RAM and ROM Change-Id: Ia6ac94a93b48037a392a9aec2cd19cd80369173f Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/15953 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-29 07:40:41 +02:00
# from a program loaded in RAM and subsequently loading ramstage.
arch/x86: introduce postcar stage/phase Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-18 18:21:23 +01:00
config POSTCAR_STAGE
arch/x86: Flip option NO_CAR_GLOBAL_MIGRATION It is easier to track CAR_GLOBAL_MIGRATION which is the approach to be deprecated with the next release. This change enforces new policy; POSTCAR_STAGE=y is not allowed together with CAR_GLOBAL_MIGRATION=y. Change-Id: I0dbad6a14e68bf566ac0f151dc8ea259e5ae2250 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34804 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-08-09 06:11:07 +02:00
def_bool y
depends on ARCH_X86
arch/x86: Add debug spinloops in assembly_entry.S Use Kconfig values to enable debug spinloops in assembly_entry.S. This makes it easy to debug the assembly code. TEST=Build and run on Galileo Gen2 Change-Id: Ic56bf2260b8e3181403623961874c9289f3ca945 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/15135 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-08 22:40:08 +02:00
config VERSTAGE_DEBUG_SPINLOOP
bool
default n
help
Add a spin (JMP .) in assembly_entry.S during early verstage to wait
for a JTAG debugger to break into the execution sequence.
config ROMSTAGE_DEBUG_SPINLOOP
bool
default n
help
Add a spin (JMP .) in assembly_entry.S during early romstage to wait
for a JTAG debugger to break into the execution sequence.
src/Kconfig: Move bootblock behavior to arch/x86 as TODO suggested The four options are only used in X86: - BOOTBLOCK_SIMPLE - BOOTBLOCK_NORMAL - BOOTBLOCK_SOURCE - SKIP_MAX_REBOOT_CNT_CLEAR Move them all into src/arch/x86/Kconfig - this puts them in the chipset menu instead of general setup. Verified that this makes no significant changes to any config file. Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/17909 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2016-12-16 00:04:55 +01:00
choice
prompt "Bootblock behaviour"
default BOOTBLOCK_SIMPLE
bootblock: Support normal/fallback mechanism again Change-Id: I7395e62f6682f4ef123da10ac125127a57711ec6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37760 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-12-16 15:00:49 +01:00
depends on !VBOOT
src/Kconfig: Move bootblock behavior to arch/x86 as TODO suggested The four options are only used in X86: - BOOTBLOCK_SIMPLE - BOOTBLOCK_NORMAL - BOOTBLOCK_SOURCE - SKIP_MAX_REBOOT_CNT_CLEAR Move them all into src/arch/x86/Kconfig - this puts them in the chipset menu instead of general setup. Verified that this makes no significant changes to any config file. Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/17909 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2016-12-16 00:04:55 +01:00
config BOOTBLOCK_SIMPLE
bool "Always load fallback"
config BOOTBLOCK_NORMAL
arch/x86/Kconfig: Hide the prefix option on all but BOOTBLOCK_NORMAL Change-Id: Icf5e8fa18bea1cdfb85b8a4999d8fccea94d16b9 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33324 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-06-08 11:28:52 +02:00
select CONFIGURABLE_CBFS_PREFIX
src/Kconfig: Move bootblock behavior to arch/x86 as TODO suggested The four options are only used in X86: - BOOTBLOCK_SIMPLE - BOOTBLOCK_NORMAL - BOOTBLOCK_SOURCE - SKIP_MAX_REBOOT_CNT_CLEAR Move them all into src/arch/x86/Kconfig - this puts them in the chipset menu instead of general setup. Verified that this makes no significant changes to any config file. Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/17909 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2016-12-16 00:04:55 +01:00
bool "Switch to normal if CMOS says so"
endchoice
config SKIP_MAX_REBOOT_CNT_CLEAR
bool "Do not clear reboot count after successful boot"
depends on BOOTBLOCK_NORMAL
help
Do not clear the reboot count immediately after successful boot.
Set to allow the payload to control normal/fallback image recovery.
Note that it is the responsibility of the payload to reset the
arch/x86/Kconfig: Fix spelling of *successful* Change-Id: If0da91cf94aa12fe7b8670f6b181e443e3446aa1 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/c/30745 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-01-08 16:21:31 +01:00
normal boot bit to 1 after each successful boot.
arch/x86: Add Kconfig option for ACPI \_PR CPU name string Add a Kconfig option to change the \PR.CPxx name string. This provides some flexibility when working with table not generated by coreboot. Change-Id: Ibc0c56783c6da80501e2177de96a414b592cb74f Signed-off-by: Marc Jones <marcj303@gmail.com> Reviewed-on: https://review.coreboot.org/21210 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2017-08-26 02:54:23 +02:00
x86/acpi: Add Kconfig to toggle 8259 reporting Change-Id: If3c9783ebc41c103c915788139d91644b805f397 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/29832 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2018-11-24 18:25:50 +01:00
config ACPI_NO_PCAT_8259
bool
help
Selected by platforms that don't expose a PC/AT 8259 PIC pair.
config ACPI_HAVE_PCAT_8259
def_bool y if !ACPI_NO_PCAT_8259
arch/x86: Add Kconfig option for ACPI \_PR CPU name string Add a Kconfig option to change the \PR.CPxx name string. This provides some flexibility when working with table not generated by coreboot. Change-Id: Ibc0c56783c6da80501e2177de96a414b592cb74f Signed-off-by: Marc Jones <marcj303@gmail.com> Reviewed-on: https://review.coreboot.org/21210 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2017-08-26 02:54:23 +02:00
config ACPI_CPU_STRING
string
acpi: Change Processor ACPI Name (Intel only) The ACPI Spec 2.0 states, that Processor declarations should be made within the ACPI namespace \_SB and not \_PR anymore. \_PR is deprecated and is removed here for Intel CPUs only. Tested on: * X11SSH (Kabylake) * CFL Platform * Asus P8Z77-V LX2 and Windows 10 FWTS does not return FAIL anymore on ACPI tests Tested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: Ib101ed718f90f9056d2ecbc31b13b749ed1fc438 Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37814 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-12-18 15:07:59 +01:00
default "\\_SB.CP%02d"
arch/x86: Add Kconfig option for ACPI \_PR CPU name string Add a Kconfig option to change the \PR.CPxx name string. This provides some flexibility when working with table not generated by coreboot. Change-Id: Ibc0c56783c6da80501e2177de96a414b592cb74f Signed-off-by: Marc Jones <marcj303@gmail.com> Reviewed-on: https://review.coreboot.org/21210 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2017-08-26 02:54:23 +02:00
depends on HAVE_ACPI_TABLES
help
Sets the ACPI name string in the processor scope as written by
acpi: Change Processor ACPI Name (Intel only) The ACPI Spec 2.0 states, that Processor declarations should be made within the ACPI namespace \_SB and not \_PR anymore. \_PR is deprecated and is removed here for Intel CPUs only. Tested on: * X11SSH (Kabylake) * CFL Platform * Asus P8Z77-V LX2 and Windows 10 FWTS does not return FAIL anymore on ACPI tests Tested-by: Angel Pons <th3fanbus@gmail.com> Change-Id: Ib101ed718f90f9056d2ecbc31b13b749ed1fc438 Signed-off-by: Christian Walter <christian.walter@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37814 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-12-18 15:07:59 +01:00
the acpigen function. Default is \_SB.CPxx. Note that you need
arch/x86: Add Kconfig option for ACPI \_PR CPU name string Add a Kconfig option to change the \PR.CPxx name string. This provides some flexibility when working with table not generated by coreboot. Change-Id: Ibc0c56783c6da80501e2177de96a414b592cb74f Signed-off-by: Marc Jones <marcj303@gmail.com> Reviewed-on: https://review.coreboot.org/21210 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2017-08-26 02:54:23 +02:00
the \ escape character in the string.
arch/x86: allow timestamp source to not be TSC Some x86 platforms don't have a TSC that is invariant w.r.t. rate to get accurate timestamps. As such a different timestamp is required. Therefore, allow one to specify non-TSC timestamp source and not compile in the default x86 TSC code. BUG=b:72378235,b:72170796 Change-Id: I737fcbba60665b3bc2b5864269536fda78b44d90 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/23423 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org>
2018-01-25 01:35:58 +01:00
config COLLECT_TIMESTAMPS_NO_TSC
bool
default n
depends on COLLECT_TIMESTAMPS
help
Use a non-TSC platform-dependent source for timestamps.
config COLLECT_TIMESTAMPS_TSC
bool
default y if !COLLECT_TIMESTAMPS_NO_TSC
default n
depends on COLLECT_TIMESTAMPS
help
Use the TSC as the timestamp source.
arch/x86: add support for cache-as-ram paging Processors, such as glk, need to have paging enabled while in cache-as-ram mode because the front end is agressive about fetching lines into the L1I cache. If the line is dirty and in the L1D then it writes it back to "memory". However, in this case there is no backing store so the cache-as-ram data that was written back transforms to all 0xff's when read back in causing corruption. In order to mitigate the failure add x86 architecture support for enabling paging while in cache-as-ram mode. A Kconfig variable, NUM_CAR_PAGE_TABLE_PAGES, determines the number of pages to carve out for page tables within the cache-as-ram region. Additionally, the page directory pointer table is also carved out of cache-as-ram. Both areas are allocated from the persist-across-stages region of cache-as-ram so all stages utilizing cache-as-ram don't corrupt the page tables. The two paging-related areas are loaded by calling paging_enable_for_car() with the names of cbfs files to load the initial paging structures from. BUG=b:72728953 Change-Id: I7ea6e3e7be94a0ef9fd3205ce848e539bfbdcb6e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/25717 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org>
2018-04-18 09:00:27 +02:00
config PAGING_IN_CACHE_AS_RAM
bool
default n
depends on ARCH_X86
help
Chipsets scan select this option to preallocate area in cache-as-ram
for storing paging data structures. PAE paging is currently the
only thing being supported.
config NUM_CAR_PAGE_TABLE_PAGES
int
default 5
depends on PAGING_IN_CACHE_AS_RAM
help
The number of 4KiB pages that should be pre-allocated for page tables.
arch/x86: allow idt to be available to link in all stages Add Kconfig IDT_IN_EVERY_STAGE to optionally specify having the interrupt handling code available to all stages. In order to do this the idt setup is moved to a C module. The vecX entries are made global so that a table of references to all the interrupt vector entry points can be used to dynamically initialize the idt. The ramification for ramstage is that exceptions are initialized later (lib/hardwaremain.c). Not all stages initialize exceptions when this Kconfig variable is selected, but bootblock for the C, stages using assembly_entry.S, and of course ramstage do. Anything left out just needs a call to exception_init() at the right location. BUG=b:72728953 Change-Id: I4146a040e5e43bed7ccc6cb0a7dc2271f1e7b7fa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/25761 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2018-04-20 09:39:30 +02:00
# Provide the interrupt handlers to every stage. Not all
# stages may take advantage.
config IDT_IN_EVERY_STAGE
bool
default n
depends on ARCH_X86
arch/x86: Implement common CF9 reset It's very common across many x86 silicon vendors, so place it in `arch/x86/`. Change-Id: I06c27afa31e5eecfdb7093c02f703bdaabf0594c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/29054 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-10-10 22:44:20 +02:00
config HAVE_CF9_RESET
bool
config HAVE_CF9_RESET_PREPARE
bool
depends on HAVE_CF9_RESET
arch/x86: Clean up PIRQ_ROUTE This code is currently only used by via/epia-m850, it is also somewhat buggy. Change-Id: I140e15d584d3f60f7824bcb71ce63724c11e3f46 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34078 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-07-04 20:08:17 +02:00
config PIRQ_ROUTE
bool
default n
config MAX_PIRQ_LINKS
int
default 4
depends on PIRQ_ROUTE
help
This variable specifies the number of PIRQ interrupt links which are
routable. On most chipsets, this is 4, INTA through INTD. Some
chipsets offer more than four links, commonly up to INTH. They may
also have a separate link for ATA or IOAPIC interrupts. When the PIRQ
table specifies links greater than 4, pirq_route_irqs will not
function properly, unless this variable is correctly set.
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
arch/x86/tables: Move max ACPI table size to Kconfig The maximum ACPI table size is currently hardcoded to 144 KiB. When using QEMU with TPM enabled there is ~200 KiB of ACPI tables returned by the fw_cfg interface, so in order to allow this to be overridden by a mainboard move it to Kconfig. This is seen when using a TPM with qemu as it will hang when processing the fw_cfg tables. qemu-system-x86_64 \ -machine q35 -enable-kvm -vga virtio -serial stdio \ -drive 'id=hd,file=disk.bin' -bios coreboot.rom \ -chardev 'socket,id=swtpm,path=/tmp/swtpm/swtpm-sock' \ -tpmdev 'emulator,id=tpm0,chardev=swtpm' \ -device 'tpm-tis,tpmdev=tpm0' Change-Id: Ib5baa8fe12cb9027a340875f1ccf5fef6f9460bd Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39832 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2020-03-18 02:32:54 +01:00
config MAX_ACPI_TABLE_SIZE_KB
int
default 144
help
Set the maximum size of all ACPI tables in KiB.
arch/x86: Make X86 stages select ARCH_X86 Also, don't define the default as this results in spurious lines in the .config. TEST: Build all boards with where config.h differed with BUILD_TIMELESS=1 and remained the same Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-10 17:00:56 +01:00
endif
Reference in a new issue Copy permalink