2013-07-28 22:39:37 +02:00
|
|
|
config SOUTHBRIDGE_INTEL_COMMON
|
|
|
|
def_bool n
|
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
|
|
|
|
|
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.
|