Commit Graph

7821 Commits

Author SHA1 Message Date
Duncan Laurie afad056c22 Add Intel Whitetip Mountain 2 mainboard
This is mostly a copy of Whitetip Mountain 1 with specific GPIO
map for this Customer Reference Board (CRB).

This mainboard currently has basic funcionality and is able to
boot a Linux Kernel but many of the new Haswell ULT specific
devices are not yet enabled.

Change-Id: I999452d86f00a2c245fa39b1b76080f6a3b1e352
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2725
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18 00:18:48 +01:00
Андрей Павлов ab9b71d54c superiotool: Add support for the IT8728F Super I/O
$ superiotool -d
superiotool r4.0-3712-gd549279
Found ITE IT8728F (id=0x8728, rev=0x1) at 0x2e
Register dump:
idx 02 07 20 21 22 23 24 2b  2e 2f
val 00 0a 87 28 01 00 00 40  00 00
def NA NA 87 28 01 00 00 MM  00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1
val 00 03 f0 06 02 00 00
def 00 03 f0 06 02 00 00
LDN 0x01 (COM1)
idx 30 60 61 70 f0 f1
val 01 03 f8 04 00 50
def 00 03 f8 04 00 50
LDN 0x02 (COM2)
idx 30 60 61 70 f0 f1
val 00 02 f8 03 00 50
def 00 02 f8 03 00 50
LDN 0x03 (Parallel port)
idx 30 60 61 62 63 70 74 f0
val 01 03 78 00 00 07 04 08
def 00 03 78 07 78 07 03 03
LDN 0x04 (Environment controller)
idx 30 60 61 62 63 70 f0 f1  f2 f3 f4 f5 f6 f9 fa fb
val 01 0a 30 0a 20 09 00 80  00 00 20 00 f0 48 00 00
def 00 02 90 02 30 09 00 00  00 00 00 MM MM MM MM MM
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 71 f0
val 01 00 60 00 64 01 02 08
def 01 00 60 00 64 01 02 48
LDN 0x06 (Mouse)
idx 30 70 71 f0
val 01 0c 02 00
def 00 0c 02 00
LDN 0x07 (GPIO)
idx 25 26 27 28 29 2a 2c 2d  60 61 62 63 64 65 70 71  72 73 74 b0 b1 b2 b3 b4  b8 b9 ba bb bc bd c0 c1  c2 c3 c4 c8 c9 ca cb cc  cd ce cf e0 e1 e2 e3 e4  e9 f0 f1 f2 f3 f4 f5 f6  f7 f8 f9 fa fb
val 00 f3 10 00 00 00 80 00  00 00 0a 00 00 00 00 00  20 00 00 00 00 00 00 00  20 00 00 00 00 00 01 00  00 40 00 01 00 00 00 00  00 00 00 00 00 00 00 00  21 10 42 00 00 00 00 1c  00 00 00 00 00
def 00 f3 00 00 00 00 03 00  00 00 00 00 00 00 00 00  20 38 00 00 00 00 00 00  20 00 00 00 00 00 01 00  00 40 00 01 00 00 40 00  00 00 00 00 00 00 00 00  MM 00 00 00 00 00 00 00  00 00 00 00 00
LDN 0x0a (Consumer IR)
idx 30 60 61 70 f0
val 00 03 10 0b 06
def 00 03 10 0b 06

Change-Id: Ifb45d28005d78b2a99d8552b59154d11bdf44f6f
Signed-off-by: Андрей Павлов <7134956@gmail.com>
Reviewed-on: http://review.coreboot.org/2775
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-03-17 23:20:38 +01:00
Stefan Reinauer 15ba2bcf2d Intel HD Audio: clean up initialization code
- Some initialization steps were done twice
- One step was missing for Panther Point HDA
- Added a 1ms delay after reset
- Increased timeout to 1ms for all codec operations

Change-Id: Ib751f1a16ccd88ea2fbbb2a10737f76277574026
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2518
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:54:56 +01:00
Aaron Durbin 6dcceddff5 x86 intel: Add Firmware Interface Table support
Haswell CPUs require a FIT table in the firmware. This commit
adds rudimentary support for a FIT table. The number of entries
in the table is based on a configuration option. The code only
generates a type 0 entry. A follow-on tool will need to be developed
to populate the FIT entries as well as checksumming the table.

Verified image has a FIT pointer and table when option is selected.

Change-Id: I3a314016a09a1cc26bf1fb5d17aa50853d2ef4f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2642
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:53:51 +01:00
Aaron Durbin 239c2e843f haswell platforms: restructure romstage main
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.

The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.

Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.

Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:53:31 +01:00
Duncan Laurie 218a6864ff Add Intel Whitetip Mountain 1 mainboard
Lots of things are still placeholder and need work.

Due to the useful GPIOs being run to either the EC or the SIO1007
I have hard coded developer mode on and recovery mode off.

Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:52:32 +01:00
Shawn Nematbakhsh c9fc0297ad bd82x6x: Add config option to force SATA link to different speeds.
Certain SATA devices claim to support SATA 6 Gbps, but in fact have
bugs. For these devices, add a config option to force the SATA link
speed to something other than default.

Change-Id: I2dc1793cd58771298a392345162d39d20eb0afbb
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:51:48 +01:00
Duncan Laurie 645b376ec8 Pantherpoint: Add XHCI device init
This enables power management and clock gating on XHCI.

Change-Id: I124ea6c5aca034b7ec4b5286d971c2adfce25c88
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:51:05 +01:00
Aaron Durbin 8aa210bbf0 bd82x6x: don't use absolute symbols
objcopy -B provides symbols of the form _binary_<name>_(start|end|size).
However, the _size variant is an absoult symbol.  If one wants to
relocate the smi loading the _size symbol will be relocated which is
wrong since it is suppose to be a fixed size. There is no way to
distinguish symbols that shouldn't be relocated vs ones that can.
Instead use the _start and _end variants to determine the size.

Change-Id: I55192992cf36f62a9d8dd896e5fb3043a3eacbd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2760
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:50:04 +01:00
Marc Jones 058d70f163 Add bd82x6x XHCI(USB3) S3/S4 workaround
The bd82x6x requires some additional setting on S3/S4 entry.

Change-Id: I24489ab94dd7cd5a4a64044f25153f5b01a45b77
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2759
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:49:34 +01:00
Marc Jones 783f226208 Add bd82x6x PCH functions to SMM
Add the PCH function to SMM for follow-on SMM patches that
require these functions.

Change-Id: I7f3a512c5e98446e835b59934d63a99e8af15280
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2758
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 22:49:01 +01:00
Aaron Durbin e6c3b1d30d haswell: include TSEG region in cacheable memory
The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG
region is setup as cacheable through the MTTRs, accesses to the TSEG
region before SMM relocation are cached. This allows for the setup of
SMM relocation to be faster by caching accesses to the future TSEG
(SMRAM) memory.

MC MAP: TOM: 0x140000000
MC MAP: TOUUD: 0x18f600000
MC MAP: MESEG_BASE: 0x13f000000
MC MAP: MESEG_LIMIT: 0x7fff0fffff
MC MAP: REMAP_BASE: 0x13f000000
MC MAP: REMAP_LIMIT: 0x18f5fffff
MC MAP: TOLUD: 0xafa00000
MC MAP: BGSM: 0xad800000
MC MAP: BDSM: 0xada00000
MC MAP: TESGMB: 0xad000000
MC MAP: GGC: 0x209

TSEG->BGSM:
   PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4
BGSM->TOLUD:
   PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5

Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range:  512MB, type WB
Setting variable MTRR 2, base: 2560MB, range:  256MB, type WB
Adding hole at 2776MB-2816MB
Setting variable MTRR 3, base: 2776MB, range:    8MB, type UC
Setting variable MTRR 4, base: 2784MB, range:   32MB, type UC
Zero-sized MTRR range @0KB
 Allocate an msr - basek = 00400000, sizek = 0023d800,
Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB
Setting variable MTRR 6, base: 6144MB, range:  256MB, type WB
Adding hole at 6390MB-6400MB
Setting variable MTRR 7, base: 6390MB, range:    2MB, type UC

MTRR translation from MB to addresses:

MTRR 0: 0x00000000 -> 0x80000000 WB
MTRR 1: 0x80000000 -> 0xa0000000 WB
MTRR 2: 0xa0000000 -> 0xb0000000 WB
MTRR 3: 0xad800000 -> 0xae000000 UC
MTRR 4: 0xae000000 -> 0xb0000000 UC

I'm not a fan of the marking physical address space with MTRRs as being
UC which is PCI space, but it is technically correct.

Lastly, drop a comment describing AP startup flow through coreboot.

Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2690
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 20:05:15 +01:00
Patrick Georgi 86a1110837 i945: Replace some two magic values by defined names
Devoutly to be wish'd. To die,—to sleep;—
To sleep! perchance to dream:—ay, there's the rub;
For in that sleep of death what dreams may come,

(Since who could argue with William Shakespeare?)

Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/2733
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-03-17 19:59:20 +01:00
Mike Loptien 594ea4ac5f ASROCK Fam14 DSDT: Add secondary bus range to PCI0
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'

By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`.  PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge.  However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.

This is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/

Change-Id: I5184df8deb7b5d2e15404d689c16c00493eb01aa
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2736
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:55:59 +01:00
Mike Loptien 8c72670ba5 AMD Fam14 DSDT: Remove INI method from AZHD device
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table.  It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method.  We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space.  The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values.  And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.

In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether.  I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.

FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts

This is the same chagne as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/

Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:55:43 +01:00
Mike Loptien 60d84ca22b ASROCK Fam14 DSDT: Remove INI method from AZHD device
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table.  It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method.  We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space.  The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values.  And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.

In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether.  I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.

FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts

This is the same change as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/

Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:55:29 +01:00
Mike Loptien 109c08e05a Lippert Fam14 DSDT: Remove INI method from AZHD device
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table.  It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method.  We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space.  The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values.  And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.

In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether.  I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.

FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts

This is the same change as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/

Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:55:15 +01:00
Mike Loptien 42ad200657 Lippert Fam14 DSDT: Add secondary bus range to PCI0
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'

By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`.  PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge.  However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.

This is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/

Change-Id: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2737
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:55:03 +01:00
Mike Loptien 00a0e76bc5 AMD Fam14 DSDT: Add OSC method
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware.  This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer.  This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword.  The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features.  We do not want to have control over
anything so let the OS control as much as it can.

The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.

This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/

Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:54:40 +01:00
Mike Loptien 9c3d112bb6 ASROCK Fam14 DSDT: Add OSC method
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware.  This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer.  This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword.  The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features.  We do not want to have control over
anything so let the OS control as much as it can.

The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.

This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/

Change-Id: I2701d915338294bdade2ad334b22a51db980892e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:54:23 +01:00
Mike Loptien 061c66406f Lippert Fam14 DSDT: Add OSC method
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware.  This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer.  This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword.  The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features.  We do not want to have control over
anything so let the OS control as much as it can.

The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.

This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/

Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17 19:54:07 +01:00
Duncan Laurie 71346c064b lynxpoint: Add support for disabling ULT devices
These enables are hidden behind IOBP for some reason.

Boot to linux with SDIO disabled and see that
the SDIO driver does not load and crash the system.

Change-Id: Icfbfa117e9e57a51d32db7f6366a9d0d790adcf0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2695
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17 00:36:24 +01:00
Ronald G. Minnich aa3f4287d4 stddef.h: Add standard defines for KiB, MiB, GiB, and TiB
Paul points out that some people like 1024*1024, others like
1048576, but in any case these are all open to typos.

Define KiB, MiB, GiB, and TiB as in the standard so people can use them.

Change-Id: Ic1b57e70d3e9b9e1c0242299741f71db91e7cd3f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2769
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-03-16 16:15:01 +01:00
Aaron Durbin 5c66f08a3a haswell: don't add a 0-sized memory range resource
It's possible that TOUUD can be 4GiB in a small physical memory
configuration. Therefore, don't add a 0-size memory range resouce
in that case.

Change-Id: I016616a9d9d615417038e9c847c354db7d872819
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2691
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-16 04:58:18 +01:00
Ronald G. Minnich c2c97231e3 Show the device tree.
This is a bit of a hack but it's very handy. It compiles in your static.c
and then shows what coreboot would see when it is run. It uses your static.c
and functions pulled from src/device/device_util.c.
I've already used it to debug problems with the snow device tree.

I'm waiting someone to tell me this is already written :-)

Change-Id: Ia8c8a5d08d8757bec49eaf70473efa701bc56581
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2767
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-16 04:30:16 +01:00
Ronald G. Minnich 20ff75f1fc google/snow: rename a file so that it is clear what board it is for
One might wonder what a board named 'build' does. Rename the file to
build-snow. The fact that it is in a directory with google in the name
should be enough to identify the vendor.

Change-Id: I0b473cdce67d56fc6b92032b55180523eb337d66
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2766
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-16 04:07:35 +01:00
Patrick Georgi 039223a474 gitmodules: Ignore 3rdparty in "diff family"
This should help avoid wrong 3rdparty commit ids
creeping in.

Change-Id: I2134ad1d3ad0237ef3f12baf4d4aafb02009e7bc
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2768
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2013-03-16 04:07:14 +01:00
Ronald G. Minnich 69efaa0388 Google Link: Add remaining code to support native graphics
The Link native graphics commit 49428d84 [1]

    Add support for Google's Chromebook Pixel

was missing some of the higher level bits, and hence could not be
used.  This is not new code -- it has been working since last
August -- so the effort now is to get it into the tree and structure
it in a way compatible with upstream coreboot.

1. Add options to src/device/Kconfig to enable native graphics.
2. Export the MTRR function for setting variable MTRRs.
3. Clean up some of the comments and white space.

While I realize that the product name is Pixel, the mainboard in the
coreboot tree is called Link, and that name is what we will use
in our commits.

[1] http://review.coreboot.org/2482

Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2531
Tested-by: build bot (Jenkins)
2013-03-15 20:21:51 +01:00
Mike Loptien 26855fc70b AMD Fam14 DSDT: Add secondary bus range to PCI0
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'

By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`.  PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge.  However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.

This is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/

Change-Id: I9017a7619b3b17e0e95ad0fe46d0652499289b00
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 19:39:35 +01:00
Stefan Reinauer c4dfae835f Update 3rdparty mark to latest repository
For google/stout binaries

Apparently the actual marker got lost in the rebase / change of the
commit message.

Change-Id: I4f18b9ddba326988b58f2595c0025a113feb0d68
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2734
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 19:09:08 +01:00
Wolfgang Kamp 9ae1eb6961 Super I/O W83627DHG: Enable UART B by redirecting pins
Pins 78-85 are set to GPIO after power on or reset. To enable
UART B the pins must be redirected to it.

Look at W83627DHG databook version 1.4 page 185 Chip
(global) Control Register CR2C.

Change-Id: I12b094a60d9c5cb2447a553be4679a4605e19845
Signed-off-by: Wolfgang Kamp <wmkamp@datakamp.de>
Reviewed-on: http://review.coreboot.org/2626
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-03-15 17:51:48 +01:00
Mike Loptien 8d629c14eb Persimmon DSDT: Remove INI method from AZHD device
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table.  It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method.  We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space.  The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values.  And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.

In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether.  I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.

FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts

Change-Id: If8d86f959822d528c44ab011a851659d486289b5
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 17:07:01 +01:00
Mike Loptien e31c0ed9b5 Persimmon DSDT: Add OSC method
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware.  This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer.  This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword.  The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features.  We do not want to have control over
anything so let the OS control as much as it can.

The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.

Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15 17:06:23 +01:00
Stefan Reinauer 35c2f4fd4a Drop CHIP_NAME from intel/baskingridge
It's no longer required.

Change-Id: I621226a3bdfba9bc8edfd6e511a5337ae603ae19
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2723
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-03-15 16:59:16 +01:00
Aaron Durbin 1570260ba1 haswell: Fix BDSM and BGSM indicies in memory map
This wasn't previously spotted because the printk's were correct.
However if one needed to get the value of the BDSM or BGSM register
the value would reflect the other register's value.

Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2689
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15 16:58:54 +01:00
Aaron Durbin 1fef1f5177 haswell: reserve default SMRAM space
Currently the OS is free to use the memory located at the default
SMRAM space because it is not marked reserved in the e820. This can
lead to memory corruption on S3 resume because SMM setup doesn't save
this range before using it to relocate SMRAM.

Resulting tables:

	coreboot memory table:
	 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
	 1. 0000000000001000-000000000002ffff: RAM
	 2. 0000000000030000-000000000003ffff: RESERVED
	 3. 0000000000040000-000000000009ffff: RAM
	 4. 00000000000a0000-00000000000fffff: RESERVED
	 5. 0000000000100000-0000000000efffff: RAM
	 6. 0000000000f00000-0000000000ffffff: RESERVED
	 7. 0000000001000000-00000000acebffff: RAM
	 8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
	 9. 00000000ad000000-00000000af9fffff: RESERVED
	10. 00000000f0000000-00000000f3ffffff: RESERVED
	11. 00000000fed10000-00000000fed19fff: RESERVED
	12. 00000000fed84000-00000000fed84fff: RESERVED
	13. 0000000100000000-000000018f5fffff: RAM

	e820 map has 13 items:
	  0: 0000000000000000 - 0000000000030000 = 1 RAM
	  1: 0000000000030000 - 0000000000040000 = 2 RESERVED
	  2: 0000000000040000 - 000000000009f400 = 1 RAM
	  3: 000000000009f400 - 00000000000a0000 = 2 RESERVED
	  4: 00000000000f0000 - 0000000000100000 = 2 RESERVED
	  5: 0000000000100000 - 0000000000f00000 = 1 RAM
	  6: 0000000000f00000 - 0000000001000000 = 2 RESERVED
	  7: 0000000001000000 - 00000000acec0000 = 1 RAM
	  8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED
	  9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED
	  10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED
	  11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED
	  12: 0000000100000000 - 000000018f600000 = 1 RAM

Booted and checked e820 as well as coreboot table information.

Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2688
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15 16:58:37 +01:00
Aaron Durbin c12ef9723e haswell: resource allocation
The previous code w.r.t. resource allocation was getting lucky
based on the way fixed mmio resources on the system were being
chosen. Namely, PCIEXBAR was the lowest mmio space and the other
fixed non-standar BARs were above it. The resource allocator would
then start allocating standard BARs below that.

On top of that other resources were being added when
dev_ops->set_resources() was being called on the PCI domain. At that
point the PCI range limit were already picked for where to start
allocating from.

To ensure we no longer get lucky during resource allocation add the
fixed resources in the host bridge and add the memory controller
cacheable memory areas. With those resources added the range limit
for standard PCI BARs is chosen properly.

Depending on haswell board configurations we may need to adjust and
pass in the size of physical address space needed for PCI resources
to the reference code. For the time being the CRBs appear to be OK.

Lastly, remove the SNB workaround for reserving 2MiB at 1GiB and 512MiB.

Output from 6GiB memory configuration:
	MC MAP: TOM: 0x140000000
	MC MAP: TOUUD: 0x18f600000
	MC MAP: MESEG_BASE: 0x13f000000
	MC MAP: MESEG_LIMIT: 0x7fff0fffff
	MC MAP: REMAP_BASE: 0x13f000000
	MC MAP: REMAP_LIMIT: 0x18f5fffff
	MC MAP: TOLUD: 0xafa00000
	MC MAP: BDSM: 0xada00000
	MC MAP: BGSM: 0xad800000
	MC MAP: TESGMB: 0xad000000
	MC MAP: GGC: 0x209

	coreboot memory table:
	 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
	 1. 0000000000001000-000000000009ffff: RAM
	 2. 00000000000a0000-00000000000fffff: RESERVED
	 3. 0000000000100000-0000000000efffff: RAM
	 4. 0000000000f00000-0000000000ffffff: RESERVED
	 5. 0000000001000000-00000000acebffff: RAM
	 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
	 7. 00000000ad000000-00000000af9fffff: RESERVED
	 8. 00000000f0000000-00000000f3ffffff: RESERVED
	 9. 00000000fed10000-00000000fed17fff: RESERVED
	10. 00000000fed18000-00000000fed18fff: RESERVED
	11. 00000000fed19000-00000000fed19fff: RESERVED
	12. 00000000fed84000-00000000fed84fff: RESERVED
	13. 0000000100000000-000000018f5fffff: RAM

	e820 map has 11 items:
	  0: 0000000000000000 - 000000000009fc00 = 1 RAM
	  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
	  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
	  3: 0000000000100000 - 0000000000f00000 = 1 RAM
	  4: 0000000000f00000 - 0000000001000000 = 2 RESERVED
	  5: 0000000001000000 - 00000000acec0000 = 1 RAM
	  6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED
	  7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED
	  8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED
	  9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED
	  10: 0000000100000000 - 000000018f600000 = 1 RAM

Output from 4GiB memory configuration:
	MC MAP: TOM: 0x100000000
	MC MAP: TOUUD: 0x14f600000
	MC MAP: MESEG_BASE: 0xff000000
	MC MAP: MESEG_LIMIT: 0x7fff0fffff
	MC MAP: REMAP_BASE: 0x100000000
	MC MAP: REMAP_LIMIT: 0x14f5fffff
	MC MAP: TOLUD: 0xafa00000
	MC MAP: BDSM: 0xada00000
	MC MAP: BGSM: 0xad800000
	MC MAP: TESGMB: 0xad000000
	MC MAP: GGC: 0x209

	coreboot memory table:
	 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
	 1. 0000000000001000-000000000009ffff: RAM
	 2. 00000000000a0000-00000000000fffff: RESERVED
	 3. 0000000000100000-0000000000efffff: RAM
	 4. 0000000000f00000-0000000000ffffff: RESERVED
	 5. 0000000001000000-00000000acebffff: RAM
	 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
	 7. 00000000ad000000-00000000af9fffff: RESERVED
	 8. 00000000f0000000-00000000f3ffffff: RESERVED
	 9. 00000000fed10000-00000000fed17fff: RESERVED
	10. 00000000fed18000-00000000fed18fff: RESERVED
	11. 00000000fed19000-00000000fed19fff: RESERVED
	12. 00000000fed84000-00000000fed84fff: RESERVED
	13. 0000000100000000-000000014f5fffff: RAM

	e820 map has 11 items:
	  0: 0000000000000000 - 000000000009fc00 = 1 RAM
	  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
	  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
	  3: 0000000000100000 - 0000000000f00000 = 1 RAM
	  4: 0000000000f00000 - 0000000001000000 = 2 RESERVED
	  5: 0000000001000000 - 00000000acec0000 = 1 RAM
	  6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED
	  7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED
	  8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED
	  9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED
	  10: 0000000100000000 - 000000014f600000 = 1 RAM

Output from 2GiB memory configuration:
	MC MAP: TOM: 0x40000000
	MC MAP: TOUUD: 0x100600000
	MC MAP: MESEG_BASE: 0x3f000000
	MC MAP: MESEG_LIMIT: 0x7fff0fffff
	MC MAP: REMAP_BASE: 0x100000000
	MC MAP: REMAP_LIMIT: 0x1005fffff
	MC MAP: TOLUD: 0x3ea00000
	MC MAP: BDSM: 0x3ca00000
	MC MAP: BGSM: 0x3c800000
	MC MAP: TESGMB: 0x3c000000
	MC MAP: GGC: 0x209

	coreboot memory table:
	 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
	 1. 0000000000001000-000000000009ffff: RAM
	 2. 00000000000a0000-00000000000fffff: RESERVED
	 3. 0000000000100000-0000000000efffff: RAM
	 4. 0000000000f00000-0000000000ffffff: RESERVED
	 5. 0000000001000000-000000003bebffff: RAM
	 6. 000000003bec0000-000000003bffffff: CONFIGURATION TABLES
	 7. 000000003c000000-000000003e9fffff: RESERVED
	 8. 00000000f0000000-00000000f3ffffff: RESERVED
	 9. 00000000fed10000-00000000fed17fff: RESERVED
	10. 00000000fed18000-00000000fed18fff: RESERVED
	11. 00000000fed19000-00000000fed19fff: RESERVED
	12. 00000000fed84000-00000000fed84fff: RESERVED
	13. 0000000100000000-00000001005fffff: RAM

	e820 map has 11 items:
	  0: 0000000000000000 - 000000000009fc00 = 1 RAM
	  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
	  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
	  3: 0000000000100000 - 0000000000f00000 = 1 RAM
	  4: 0000000000f00000 - 0000000001000000 = 2 RESERVED
	  5: 0000000001000000 - 000000003bec0000 = 1 RAM
	  6: 000000003bec0000 - 000000003ea00000 = 2 RESERVED
	  7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED
	  8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED
	  9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED
	  10: 0000000100000000 - 0000000100600000 = 1 RAM

Verified through debug messages that range limits as well as
resources were being properly honored.

Change-Id: I2faa7d8a2a34a6a411a2885afb3b5c3fa1ad9c23
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2687
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2013-03-15 15:24:31 +01:00
Aaron Durbin 6f561afa4a lynxpoint: lpc resource reservations
This commit updates the Lynx Point resource reservations before
the coreboot allocator assigns resources. There is no need to mark
anything as subtractive decode because there are no devices/buses
linked to the LPC device.

The I/O range reservations consists of claiming the first 4KiB
of I/O space. The PMBASE, GPIOBASE, and LPC generic I/O decode
ranges are checked against the default claimed range. If those
ranges overlap or fall outside of the default range then those
resources are added.

The MMIO range reservations consist of claiming everything from
the I/O APIC to 4GiB. The RCBA and the LPC Generic Memory range
register are then conditionally added if they fall outside of
the default MMIO range.

Change-Id: I0f560a03814a2b15961fdbe61e4164cd54cff7a5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2682
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14 20:18:57 +01:00
Duncan Laurie 26e7dd703d haswell: more ULT/LP support and minor tweaks
- Add ME device ID for Lynxpoint LP
- Add GPU device IDs for ULT
- SATA init tweaks from checking against DXE reference code
- Remove the ICH7 from the SPI driver so it works on all lynxpoint
without having to add more LPC device ID checks
- Add function disable for audio dsp and xhci, remove PCI bridge
- Add interrupt route registers for new devices (needs romstage setup)

Change-Id: Idb48f50d0bacb6bf90531c3834542b9abb54fb8a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2680
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14 20:16:26 +01:00
Duncan Laurie eb58bc5af6 baskingridge: Report static temperature in _TMP
The current code is attempting to convert from an invalid
starting temperature.  Since we aren't sure where the temperature
will come from yet just return a static value.

This stops the kernel from going to S5 on boot because it
thinks the temperature is too high.

Change-Id: I433fa407e545458344af5842b353df5bc71bfdad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2679
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14 20:15:08 +01:00
Aaron Durbin ed7b52d3cb haswell: remove CONFIG_GFXUMA
This option is not required for haswell. Enabling the option doesn't
do anything aside from complicate mtrr calculation. Therefore, remove
it.

Change-Id: I897523ff7d3606eb89961674c2eb3d384e584857
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2678
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14 20:13:41 +01:00
Aaron Durbin f7fa218359 x86: improve lb_cleanup_memory_ranges
There are 2 issues in lb_cleanup_memory_ranges(). The first
is that during sort there is a neighbor comparison that initially
starts with the current entry. The second issue is that merging
has an off by one comparison for adjacent entries.

Before:
	coreboot memory table:
	 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
	 1. 0000000000001000-000000000009ffff: RAM
	 2. 00000000000a0000-00000000000fffff: RESERVED
	 3. 0000000000100000-0000000000efffff: RAM
	 4. 0000000000f00000-0000000000ffffff: RESERVED
	 5. 0000000001000000-00000000acebffff: RAM
	 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
	 7. 00000000ad000000-00000000af9fffff: RESERVED
	 8. 00000000f0000000-00000000f3ffffff: RESERVED
	 9. 00000000fed10000-00000000fed17fff: RESERVED
	10. 00000000fed18000-00000000fed18fff: RESERVED
	11. 00000000fed19000-00000000fed19fff: RESERVED
	12. 00000000fed84000-00000000fed84fff: RESERVED
	13. 0000000100000000-000000018f5fffff: RAM

After:
	coreboot memory table:
	 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
	 1. 0000000000001000-000000000009ffff: RAM
	 2. 00000000000a0000-00000000000fffff: RESERVED
	 3. 0000000000100000-0000000000efffff: RAM
	 4. 0000000000f00000-0000000000ffffff: RESERVED
	 5. 0000000001000000-00000000acebffff: RAM
	 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
	 7. 00000000ad000000-00000000af9fffff: RESERVED
	 8. 00000000f0000000-00000000f3ffffff: RESERVED
	 9. 00000000fed10000-00000000fed19fff: RESERVED
	10. 00000000fed84000-00000000fed84fff: RESERVED
	11. 0000000100000000-000000018f5fffff: RAM

Change-Id: I656aab61b0ed4711c9dceaedb81c290d040ffdec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2671
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14 20:13:19 +01:00
Aaron Durbin 0160d76152 baskingridge: dev, recovery, and WP switch support
This commit adds support for the deveveloper, recovery,
and write protect querying. It just uses jumpers on the
Basking Ridge board.

Noted ability to togggle jumpers results in toggling the
respective modes.

Change-Id: Iac189a1fa0245654591e2e9075380db422a329a0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2676
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:28:25 +01:00
Aaron Durbin bdd89d0dc2 baskingridge: update gpio map documentation
While looking at the Basking Ridge schematic I noticed some changes
and wanted to make sure they were reflected in the GPIO map.

Change-Id: I686653c164314ae9f68c42331d2f950751411d4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2675
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:28:19 +01:00
Aaron Durbin 7116129899 haswell: Add VGA PCI ID mappings
Needed to map VGA OPROM IDs to actual device IDs

Change-Id: I6743905c3db52519bf18f4bcc1a972aec43d3e9d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2674
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:28:08 +01:00
Aaron Durbin ef8f4c78a5 baskingridge: zero out alt_gp_smi_en in devicetree
The baskingridge has a non-zero alt_gp_smi_en value in the
devicetree.cb file. It has just to be determined which GPI
pins should trigger an SMI on basking ridge. Without this change
the board would hang during boot (presumably through a SMI flood).

No more hangs once the value is zero.

Change-Id: I9704071bb7966bd3d0bbbc4aafede3f42d829b17
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2673
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14 18:27:33 +01:00
Stefan Reinauer e265d20937 baskingridge: rename graysreef to baskingridge
The Grays Reef CRB is deprecated by order of Intel. Basking Ridge
is the new hotness. Therefore, rename graysreef to basking ridge.

Signed-off-by: Aaron Durbin <adurbin@chromium.org>

Change-Id: I203497e165d8efc99d3438c4c548140a6e9cc649
Reviewed-on: http://review.coreboot.org/2672
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:27:02 +01:00
Duncan Laurie 74c0d05cf5 lynxpoint: Update device IDs and clock gating setup
- Add device IDs for lynxpoint mobile and LP variants.
- Update the clock gating setup based on BWG
- Update the SATA programming based on BWG
- Add a DEVSLP0 mux config register

Change-Id: Icf4d7bab7f3df7adef5eb7c5e310a6995227a0e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2649
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:25:10 +01:00
Duncan Laurie 045f153a4f lynxpoint: Add new GPIO interface for Lynxpoint-LP
The low power variant of the chipset introduces a completely
new interface to the GPIOs.

This is a 1KB region and so needs to be moved as well so it does
not conflict with other IO regions.

Also expose the gpio_get functions to ramstage and move the
prototypes to pch.h so they can be used for both GPIO interfaces.

Change-Id: I20bc18669525af16de8cdf99f0ccfa9612be63ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2648
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:24:32 +01:00
Duncan Laurie 51254049b9 haswell: Add ULT CPUID and updated microcode
This adds microcode ffff000a and the CPUIDs for ULT.

Change-Id: I341c1148a355d8373b31032b9f209232bd03230a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2647
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14 18:24:27 +01:00