2013-07-28 22:39:37 +02:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON
|
|
|
|
def_bool n
|
2018-10-01 19:17:11 +02:00
|
|
|
select SOUTHBRIDGE_INTEL_COMMON_RESET
|
|
|
|
|
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_RESET
|
|
|
|
bool
|
|
|
|
select HAVE_CF9_RESET
|
2017-08-20 20:36:08 +02:00
|
|
|
|
2015-12-26 08:33:16 +01:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_GPIO
|
|
|
|
def_bool n
|
2017-08-20 20:36:08 +02:00
|
|
|
|
2017-04-12 17:01:31 +02:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_SMBUS
|
|
|
|
def_bool n
|
2017-08-20 20:36:08 +02:00
|
|
|
select HAVE_DEBUG_SMBUS
|
|
|
|
|
2017-09-25 12:21:07 +02:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_SPI
|
|
|
|
def_bool n
|
|
|
|
select SPI_FLASH
|
|
|
|
|
sb/intel/common: Automatically generate ACPI PIRQ
Based on change I2b5d68adabf0840162c6f295af8d10d8d3007a34
(sb/intel/common: Add function to automatically generate ACPI PIRQ).
This adds functionality to generate PIRQ ACPI tables automatically based
on the chipset registers.
Mapping of PCI interrupt pin to PIRQ is done by the chipset-specific
intel_common_map_pirq() function, an shared implementation of which is
provided for the bd82x6x, i82801, i89xx, ibexpeak and lynxpoint
chipsets.
Example generated _PRT:
Scope (\_SB.PCI0)
{
Method (_PRT, 0, NotSerialized) // _PRT: PCI Routing Table
{
If (PICM)
{
Return (Package (0x09)
{
Package (0x04)
{
0x0002FFFF,
0x00000000,
0x00000000,
0x00000010
},
Package (0x04)
{
0x001BFFFF,
0x00000000,
0x00000000,
0x00000010
},
Package (0x04)
{
0x001CFFFF,
0x00000000,
0x00000000,
0x00000011
},
Package (0x04)
{
0x001CFFFF,
0x00000001,
0x00000000,
0x00000015
},
Package (0x04)
{
0x001CFFFF,
0x00000002,
0x00000000,
0x00000013
},
Package (0x04)
{
0x001DFFFF,
0x00000000,
0x00000000,
0x00000013
},
Package (0x04)
{
0x001FFFFF,
0x00000000,
0x00000000,
0x00000011
},
Package (0x04)
{
0x001FFFFF,
0x00000001,
0x00000000,
0x00000017
},
Package (0x04)
{
0x0004FFFF,
0x00000000,
0x00000000,
0x00000010
}
})
}
Else
{
Return (Package (0x09)
{
Package (0x04)
{
0x0002FFFF,
0x00000000,
\_SB.PCI0.LPCB.LNKA,
0x00000000
},
Package (0x04)
{
0x001BFFFF,
0x00000000,
\_SB.PCI0.LPCB.LNKA,
0x00000000
},
Package (0x04)
{
0x001CFFFF,
0x00000000,
\_SB.PCI0.LPCB.LNKB,
0x00000000
},
Package (0x04)
{
0x001CFFFF,
0x00000001,
\_SB.PCI0.LPCB.LNKF,
0x00000000
},
Package (0x04)
{
0x001CFFFF,
0x00000002,
\_SB.PCI0.LPCB.LNKD,
0x00000000
},
Package (0x04)
{
0x001DFFFF,
0x00000000,
\_SB.PCI0.LPCB.LNKD,
0x00000000
},
Package (0x04)
{
0x001FFFFF,
0x00000000,
\_SB.PCI0.LPCB.LNKB,
0x00000000
},
Package (0x04)
{
0x001FFFFF,
0x00000001,
\_SB.PCI0.LPCB.LNKH,
0x00000000
},
Package (0x04)
{
0x0004FFFF,
0x00000000,
\_SB.PCI0.LPCB.LNKA,
0x00000000
}
})
}
}
}
Change-Id: Ic6b8ce4a9db50211a9c26221ca10105c5a0829a0
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: https://review.coreboot.org/22810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-12-13 23:25:32 +01:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_PIRQ_ACPI_GEN
|
|
|
|
def_bool n
|
|
|
|
|
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_RCBA_PIRQ
|
|
|
|
def_bool n
|
|
|
|
select SOUTHBRIDGE_INTEL_COMMON_PIRQ_ACPI_GEN
|
|
|
|
|
sb/intel/*: add option to lockdown chipset on normal boot path
On platforms with a PCH, some registers within host bridge should be
locked down on each normal boot path (done by either coreboot or
payload) and S3 resume (always done by coreboot).
A function to perform such locking is implemented in src/northbridge/
intel/*/finalize.c, and is designed as the handler of an #SMI triggered
with outb(APM_CNT_FINALIZE, APM_CNT), but currently this #SMI is only
triggered during s3 resume, and not on normal boot path. This problem
has beed discussed in
https://mail.coreboot.org/pipermail/coreboot/2017-August/084924.html .
This time, an option "INTEL_CHIPSET_LOCKDOWN" within src/southbridge/
intel/common/Kconfig is added to control the actual locking, which
depends on several compatibility flags, including
"HAVE_INTEL_CHIPSET_LOCKDOWN".
In this commit, "ibexpeak", "bd82x6x", "fsp_bd82x6x", and "lynxpoint"
have the flag "HAVE_INTEL_CHIPSET_LOCKDOWN" selected.
The change is only well tested on Sandy Bridge, my Lenovo x230.
Change-Id: I43d4142291c8737b29738c41e8c484328b297b55
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/21129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-08-22 10:26:22 +02:00
|
|
|
config HAVE_INTEL_CHIPSET_LOCKDOWN
|
|
|
|
def_bool n
|
|
|
|
|
2018-01-25 11:30:22 +01:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_SMM
|
|
|
|
def_bool n
|
|
|
|
|
2018-10-30 14:28:32 +01:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_ACPI_MADT
|
|
|
|
bool
|
|
|
|
|
2018-11-30 10:53:50 +01:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON_FINALIZE
|
|
|
|
bool
|
|
|
|
|
2018-09-06 00:34:28 +02:00
|
|
|
config INTEL_DESCRIPTOR_MODE_CAPABLE
|
|
|
|
def_bool n
|
|
|
|
help
|
|
|
|
This config simply states that the platform is *capable* of running in
|
|
|
|
descriptor mode (when the descriptor in flash is valid).
|
|
|
|
|
2018-09-11 13:49:45 +02:00
|
|
|
config INTEL_DESCRIPTOR_MODE_REQUIRED
|
|
|
|
def_bool y if INTEL_DESCRIPTOR_MODE_CAPABLE
|
|
|
|
help
|
|
|
|
This config states descriptor mode is *required* for the platform to
|
|
|
|
function properly, or to function at all.
|
|
|
|
|
sb/intel/*: add option to lockdown chipset on normal boot path
On platforms with a PCH, some registers within host bridge should be
locked down on each normal boot path (done by either coreboot or
payload) and S3 resume (always done by coreboot).
A function to perform such locking is implemented in src/northbridge/
intel/*/finalize.c, and is designed as the handler of an #SMI triggered
with outb(APM_CNT_FINALIZE, APM_CNT), but currently this #SMI is only
triggered during s3 resume, and not on normal boot path. This problem
has beed discussed in
https://mail.coreboot.org/pipermail/coreboot/2017-August/084924.html .
This time, an option "INTEL_CHIPSET_LOCKDOWN" within src/southbridge/
intel/common/Kconfig is added to control the actual locking, which
depends on several compatibility flags, including
"HAVE_INTEL_CHIPSET_LOCKDOWN".
In this commit, "ibexpeak", "bd82x6x", "fsp_bd82x6x", and "lynxpoint"
have the flag "HAVE_INTEL_CHIPSET_LOCKDOWN" selected.
The change is only well tested on Sandy Bridge, my Lenovo x230.
Change-Id: I43d4142291c8737b29738c41e8c484328b297b55
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/21129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-08-22 10:26:22 +02:00
|
|
|
config INTEL_CHIPSET_LOCKDOWN
|
|
|
|
depends on HAVE_INTEL_CHIPSET_LOCKDOWN && HAVE_SMI_HANDLER && !CHROMEOS
|
|
|
|
#ChromeOS's payload seems to handle finalization on its on.
|
|
|
|
bool "Lock down chipset in coreboot"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Some registers within host bridge on particular chipsets should be
|
|
|
|
locked down on each normal boot path (done by either coreboot or payload)
|
|
|
|
and S3 resume (always done by coreboot). Select this to let coreboot
|
|
|
|
to do this on normal boot path.
|
2018-11-30 10:53:50 +01:00
|
|
|
|
|
|
|
if SOUTHBRIDGE_INTEL_COMMON_FINALIZE
|
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "Flash locking during chipset lockdown"
|
|
|
|
default LOCK_SPI_FLASH_NONE
|
|
|
|
|
|
|
|
config LOCK_SPI_FLASH_NONE
|
|
|
|
bool "Don't lock flash sections"
|
|
|
|
|
|
|
|
config LOCK_SPI_FLASH_RO
|
|
|
|
bool "Write-protect all flash sections"
|
|
|
|
help
|
|
|
|
Select this if you want to write-protect the whole firmware flash
|
|
|
|
chip. The locking will take place during the chipset lockdown, which
|
|
|
|
is either triggered by coreboot (when INTEL_CHIPSET_LOCKDOWN is set)
|
|
|
|
or has to be triggered later (e.g. by the payload or the OS).
|
|
|
|
|
|
|
|
NOTE: If you trigger the chipset lockdown unconditionally,
|
|
|
|
you won't be able to write to the flash chip using the
|
|
|
|
internal programmer any more.
|
|
|
|
|
|
|
|
config LOCK_SPI_FLASH_NO_ACCESS
|
|
|
|
bool "Write-protect all flash sections and read-protect non-BIOS sections"
|
|
|
|
help
|
|
|
|
Select this if you want to protect the firmware flash against all
|
|
|
|
further accesses (with the exception of the memory mapped BIOS re-
|
|
|
|
gion which is always readable). The locking will take place during
|
|
|
|
the chipset lockdown, which is either triggered by coreboot (when
|
|
|
|
INTEL_CHIPSET_LOCKDOWN is set) or has to be triggered later (e.g.
|
|
|
|
by the payload or the OS).
|
|
|
|
|
|
|
|
NOTE: If you trigger the chipset lockdown unconditionally,
|
|
|
|
you won't be able to write to the flash chip using the
|
|
|
|
internal programmer any more.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
endif
|