coreboot.git
7 years agoconroe-xfire-esata2: updated device tree (to make it build again) conroe-xfire-esata2
Paul Kocialkowski [Sat, 16 Mar 2013 11:06:27 +0000 (12:06 +0100)]
conroe-xfire-esata2: updated device tree (to make it build again)

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
7 years agoW83627EHG: Added 48Mhz Clock selection
Paul Kocialkowski [Thu, 16 Aug 2012 13:41:33 +0000 (15:41 +0200)]
W83627EHG: Added 48Mhz Clock selection

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
7 years agoConRoeXFire-eSATA2: Minimal support with SuperIO serial working
Paul Kocialkowski [Thu, 16 Aug 2012 13:39:40 +0000 (15:39 +0200)]
ConRoeXFire-eSATA2: Minimal support with SuperIO serial working

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
7 years agoAMD Fam14 DSDT: Add secondary bus range to PCI0
Mike Loptien [Fri, 15 Mar 2013 16:53:40 +0000 (10:53 -0600)]
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>
7 years agoUpdate 3rdparty mark to latest repository
Stefan Reinauer [Fri, 15 Mar 2013 17:04:20 +0000 (10:04 -0700)]
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>
7 years agoSuper I/O W83627DHG: Enable UART B by redirecting pins
Wolfgang Kamp [Mon, 11 Mar 2013 15:35:42 +0000 (16:35 +0100)]
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)
7 years agoPersimmon DSDT: Remove INI method from AZHD device
Mike Loptien [Thu, 14 Mar 2013 22:07:09 +0000 (16:07 -0600)]
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>
7 years agoPersimmon DSDT: Add OSC method
Mike Loptien [Tue, 12 Mar 2013 16:21:24 +0000 (10:21 -0600)]
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>
7 years agoDrop CHIP_NAME from intel/baskingridge
Stefan Reinauer [Thu, 14 Mar 2013 20:00:14 +0000 (13:00 -0700)]
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)
7 years agohaswell: Fix BDSM and BGSM indicies in memory map
Aaron Durbin [Sat, 22 Dec 2012 04:18:58 +0000 (22:18 -0600)]
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>
7 years agohaswell: reserve default SMRAM space
Aaron Durbin [Wed, 19 Dec 2012 23:15:43 +0000 (17:15 -0600)]
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>
7 years agohaswell: resource allocation
Aaron Durbin [Tue, 18 Dec 2012 20:22:49 +0000 (14:22 -0600)]
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)
7 years agolynxpoint: lpc resource reservations
Aaron Durbin [Wed, 19 Dec 2012 20:38:01 +0000 (14:38 -0600)]
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>
7 years agohaswell: more ULT/LP support and minor tweaks
Duncan Laurie [Wed, 19 Dec 2012 17:12:31 +0000 (09:12 -0800)]
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>
7 years agobaskingridge: Report static temperature in _TMP
Duncan Laurie [Wed, 19 Dec 2012 17:14:10 +0000 (09:14 -0800)]
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>
7 years agohaswell: remove CONFIG_GFXUMA
Aaron Durbin [Tue, 18 Dec 2012 20:18:53 +0000 (14:18 -0600)]
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>
7 years agox86: improve lb_cleanup_memory_ranges
Aaron Durbin [Tue, 18 Dec 2012 23:01:57 +0000 (17:01 -0600)]
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>
7 years agobaskingridge: dev, recovery, and WP switch support
Aaron Durbin [Thu, 13 Dec 2012 22:51:41 +0000 (16:51 -0600)]
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>
7 years agobaskingridge: update gpio map documentation
Aaron Durbin [Thu, 13 Dec 2012 22:50:10 +0000 (16:50 -0600)]
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>
7 years agohaswell: Add VGA PCI ID mappings
Aaron Durbin [Thu, 13 Dec 2012 22:43:32 +0000 (16:43 -0600)]
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>
7 years agobaskingridge: zero out alt_gp_smi_en in devicetree
Aaron Durbin [Wed, 12 Dec 2012 18:32:43 +0000 (12:32 -0600)]
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>
7 years agobaskingridge: rename graysreef to baskingridge
Stefan Reinauer [Tue, 12 Mar 2013 21:32:26 +0000 (14:32 -0700)]
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>
7 years agolynxpoint: Update device IDs and clock gating setup
Duncan Laurie [Mon, 17 Dec 2012 19:31:40 +0000 (11:31 -0800)]
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>
7 years agolynxpoint: Add new GPIO interface for Lynxpoint-LP
Duncan Laurie [Mon, 17 Dec 2012 19:29:10 +0000 (11:29 -0800)]
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>
7 years agohaswell: Add ULT CPUID and updated microcode
Duncan Laurie [Mon, 17 Dec 2012 19:24:45 +0000 (11:24 -0800)]
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>
7 years agohaswell: Add ULT device IDs
Duncan Laurie [Mon, 17 Dec 2012 19:22:57 +0000 (11:22 -0800)]
haswell: Add ULT device IDs

Device IDs for northbridge and GPU.

Also mask off the lock bit in the memory map registers.

Change-Id: I9a4955d4541b938285712e82dd0b1696fa272b63
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2646
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agolynxpoint: Add Kconfig entry for Low Power chipset
Duncan Laurie [Mon, 17 Dec 2012 19:11:26 +0000 (11:11 -0800)]
lynxpoint: Add Kconfig entry for Low Power chipset

There are enough subtle differences that it is useful to have
a Kconfig entry to differentiate the ULT/LP chipet from the
desktop/mobile versions.

Change-Id: I04ca1bc6f90bcf9e6994ea7125c98347e8def898
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2645
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agolynxpoint: ME to BIOS Payload Updates
Aaron Durbin [Wed, 12 Dec 2012 18:40:33 +0000 (12:40 -0600)]
lynxpoint: ME to BIOS Payload Updates

This commit contains a bevy of updates:

- PCI device id is updated to match Lynx Point EDS in the ME driver.
- Allocate the memory to store the consumption of the MBP.
- me_bios_payload structure is now a structure of pointers that point
  into the allocated memory.
- The ICC profile structure was updated to correctly reflect the
  documentation.

Verfied that output of MBP reading can handle unknown items.

Change-Id: I43cc45e6b797444c105e7c842eb5684e9c104687
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2641
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolynx point: add new ME status information
Aaron Durbin [Tue, 11 Dec 2012 23:17:38 +0000 (17:17 -0600)]
lynx point: add new ME status information

According to the 0.8.0 ME BWG this is a new state. It's not very clear
what exactly it entails, but the Basking Ridge CRB was tripping it when
MRC_DEBUG was enabled (presumably because of a DID timeout).

Instead of 0x17 one can now see the proper message for this state.

Change-Id: I5bda1de7d3d957d38a4760a02dcd170ec48782e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2640
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agograysreef: update platform information
Aaron Durbin [Fri, 2 Nov 2012 14:19:43 +0000 (09:19 -0500)]
graysreef: update platform information

Some of the Lynx Point ids were off. Correct those and make
the pei data BAR fields consistent with the others.

Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2622
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoOT200: reset MFGTP7 (backlight pwm)
Christian Gmeiner [Tue, 12 Mar 2013 10:07:07 +0000 (11:07 +0100)]
OT200: reset MFGTP7 (backlight pwm)

The CS5536 companion device has three different power domains.
* working domain
* standby domain
* RTC domain

When the system is "off" only the standby domain is powered.
MFGPT[7:6] are member of the standby power domain.

MFGPT7 is used to control the backlight of the device and so the
timer gets used and configured during system boot. If the system
does a reboot the timer stays configured and the Linux driver
can not use it:
   "ot200-backlight: ot200-backlight.0: MFGPT 7 not availale"

The cs5535-mfgpt has a function to hard-reset all MFGPTs but the
system hangs after the first access to a MFGPT register - cause
unknown.

/*
 * This is a sledgehammer that resets all MFGPT timers. This is required by
 * some broken BIOSes which leave the system in an unstable state
 * (TinyBIOS 0.98, for example; fixed in 0.99).  It's uncertain as to
 * whether or not this secret MSR can be used to release individual timers.
 * Jordan tells me that he and Mitch once played w/ it, but it's unclear
 * what the results of that were (and they experienced some instability).
 */
static void reset_all_timers(void)
{
uint32_t val, dummy;

/* The following undocumented bit resets the MFGPT timers */
val = 0xFF; dummy = 0;
wrmsr(MSR_MFGPT_SETUP, val, dummy);
}

After playing around with this undocumented MSR it looks like I only
need to set bit 7 to free the MFGPT7.

BTW, all MFGPT[0:5] will be reset during pll_reset().

Change-Id: I54a8d479ce495b0fc2f54db766a8d793bbb5d704
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2527
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agohaswell: remove GPIO60 memory reset gate on S3 transition
Duncan Laurie [Wed, 12 Dec 2012 17:22:34 +0000 (09:22 -0800)]
haswell: remove GPIO60 memory reset gate on S3 transition

This is no longer tied to a GPIO but has a proper chipset pin.

Change-Id: Iba70338e8c67e3c3c1cb32e69bfea1282fda8cb5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2643
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: remove explicit pcie config accesses
Aaron Durbin [Thu, 1 Nov 2012 04:05:25 +0000 (23:05 -0500)]
haswell: remove explicit pcie config accesses

Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.

Change-Id: I8406cec16c1ee1bc205b657a0c90beb2252df061
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2618
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolynxpoint: PMIR register rename
Aaron Durbin [Fri, 2 Nov 2012 14:10:30 +0000 (09:10 -0500)]
lynxpoint: PMIR register rename

The register that controls global reset is named the Power
Mangement Initialization Regiser (PMIR). Update the defines
to reflect the documentation.

Additionally, there is no core well reset control according to the
EDS. There is, however, a CF9 lock field to lock this register down.

Change-Id: I773c33bec63a06cdb869eb9f94553d476e492798
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2619
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolynxpoint: Management Engine Updates
Aaron Durbin [Fri, 2 Nov 2012 14:16:46 +0000 (09:16 -0500)]
lynxpoint: Management Engine Updates

The ME9 requirements have added some registers and changed some
of the MBP state machine. Implement the changes found so far in
the ME9 BWG. There were a couple of reigster renames, but the
majority of th churn in the me.h header file is just introducing
the data structures in the same order as the ME9 BWG.

Change-Id: I51b0bb6620eff4979674ea99992ddab65a8abc18
Signed-Off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2620
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: Properly Guard Engergy Policy by CPUID
Aaron Durbin [Tue, 11 Dec 2012 23:15:13 +0000 (17:15 -0600)]
haswell: Properly Guard Engergy Policy by CPUID

The IA32_ENERGY_PERFORMANCE_BIAS MSR can only be read or written
to if the CPU supports it. The support is indicated by ECX[3] for
cpuid(6). Without this guard, some Haswell parts would GP# fault
in this routine.

No more GP# while running on haswell CRBs.

Change-Id: If41e1e133e5faebb3ed578cba60743ce7e1c196f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2639
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
7 years agohaswell: add PCI id support
Aaron Durbin [Tue, 11 Dec 2012 23:13:17 +0000 (17:13 -0600)]
haswell: add PCI id support

In order for coreboot to assign resources properly the pci
drivers need to have th proper device ids. Add the host controller
and the LPC device ids for Lynx Point.

Resource assignment works correctly now w/o odd behavior because
of conflicts.

Change-Id: Id33b3676616fb0c428d84e5fe5c6b8a7cc5fbb62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2638
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
7 years agohaswell: Remove logic to send dram init done to ME
Aaron Durbin [Fri, 7 Dec 2012 15:50:40 +0000 (09:50 -0600)]
haswell: Remove logic to send dram init done to ME

The reference code sends the dram init done command to the ME.
Therefore, there is no need for coreboot to do this.

Change-Id: I6837d6c50bbb7db991f9d21fc9cdba76252c1b7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2633
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agobasking ridge: update gpio, spd addresses, and OC
Aaron Durbin [Fri, 7 Dec 2012 15:47:16 +0000 (09:47 -0600)]
basking ridge: update gpio, spd addresses, and OC

Even though this is under the graysreef board it really
applies to the Basking Ridge board. A subsequent patch will
rename graysreef to baskingridge.

The GPIO pins were updated to reflect the Basking Ridge schematics
as well as the DIMM spd addresses and USB over current pins.

Change-Id: Ice4e05f5203de3024cd463dfccf0bcfec1e247c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2632
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: notes and updates.
Aaron Durbin [Thu, 29 Nov 2012 23:21:51 +0000 (17:21 -0600)]
haswell: notes and updates.

Add a FIXME about checking a MCHBAR register that isn't setup yet.
Also, remove revision updating because I can't find anything in the
docs that suggest this is required for haswell.

Change-Id: Ia8a6e08f82e18789e31c6c2ec2c1d63740c18dc4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2631
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: align pei_data structure with intel-framework
Aaron Durbin [Thu, 29 Nov 2012 23:18:53 +0000 (17:18 -0600)]
haswell: align pei_data structure with intel-framework

The intel-framework code has an updated pei_data structure.
Use the new structure and revision. Also, remove the scrambler
seed saving in CMOS since that appears to be handled in the saved
data from the reference code.

Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2630
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: use #defines for constants in udelay.c
Aaron Durbin [Mon, 12 Nov 2012 16:14:55 +0000 (10:14 -0600)]
haswell: use #defines for constants in udelay.c

Change the hard coded values in udelay.c to use the #defines
for MSRs and BCLK.

Change-Id: I2bbeb0b478d2e3ca155e8f82006df86c29a4f018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2629
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoMainboard: Add support for Grays Reef
Aaron Durbin [Tue, 30 Oct 2012 14:09:39 +0000 (09:09 -0500)]
Mainboard: Add support for Grays Reef

Grays Reef is one of Intel's CRBs for the Haswell processor. The
platform is named Shark Bay.

GPIOs were the main focus so IRQ routing and ACPI still needs to be
further looked at.

Change-Id: Ie94b7af66f772714992a92612c76ca93b9b27088
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2621
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: Add LPT LP device IDs to platform report
Duncan Laurie [Thu, 10 Jan 2013 21:23:48 +0000 (13:23 -0800)]
haswell: Add LPT LP device IDs to platform report

Boot haswell ULT and see LPT reported properly.

Change-Id: I48344a8dde6adbbf331c91231342de45b1b6c32a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2697
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: Update GPU power management setup
Duncan Laurie [Thu, 10 Jan 2013 21:23:04 +0000 (13:23 -0800)]
haswell: Update GPU power management setup

This is the steps outlined in the BWG.

It seems this is a lot simpler now (so far) which is good.

To test, boot to chromeos with 3.7 kernel + i915.preliminary_hw_support=1 and
see that the i915 driver complains a lot less than before and that a
splashscreen is displayed.

Change-Id: I722c90ecd351860949cedab24533f6c10e5b90e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2696
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolynxpoint: Update IOBP programming method
Duncan Laurie [Thu, 10 Jan 2013 21:19:23 +0000 (13:19 -0800)]
lynxpoint: Update IOBP programming method

This follows the new method outlined in the LPT BWG.

It is also very pedantic about its operation so it
is easier to read and compare against the docs and
the reference code implementation.

Change-Id: I235d634cded0c75ec0e9f53488f5b366107a18fa
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2694
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agox86: SMM Module Support
Aaron Durbin [Thu, 3 Jan 2013 23:38:47 +0000 (17:38 -0600)]
x86: SMM Module Support

Add support for SMM modules by leveraging the RMODULE lib. This allows
for easier dynamic SMM handler placement. The SMM module support
consists of a common stub which puts the executing CPU into protected
mode and calls into a pre-defined handler. This stub can then be used
for SMM relocation as well as the real SMM handler. For the relocation
one can call back into coreboot ramstage code to perform relocation in
C code.

The handler is essentially a copy of smihandler.c, but it drops the TSEG
differences. It also doesn't rely on the SMM revision as the cpu code
should know what processor it is supported.

Ideally the CONFIG_SMM_TSEG option could be removed once the existing
users of that option transitioned away from tseg_relocate() and
smi_get_tseg_base().

The generic SMI callbacks are now not marked as weak in the
declaration so that there aren't unlinked references. The handler
has default implementations of the generic SMI callbacks which are
marked as weak. If an external compilation module has a strong symbol
the linker will use that instead of the link one.

Additionally, the parameters to the generic callbacks are dropped as
they don't seem to be used directly. The SMM runtime can provide the
necessary support if needed.

Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2693
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: add support for vboot_handoff
Aaron Durbin [Fri, 8 Mar 2013 05:22:24 +0000 (23:22 -0600)]
libpayload: add support for vboot_handoff

The vboot_handoff structure needs to be parsed from the coreboot tables.
Add a placeholder in sysinfo as well as the ability to parse the
coreboot table entry concering the vboot_handoff structure.

Built with unified boot loader and ebuild changes. Can find and use
the VbInitParams for doing kernel selection.

Change-Id: If40a863b4a445fa5f7814325add03355fd0ac647
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2720
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Turn the endian conversion macros into functions.
Gabe Black [Fri, 8 Mar 2013 12:38:13 +0000 (04:38 -0800)]
libpayload: Turn the endian conversion macros into functions.

In their current macro form, any arguments that are expressions will be
evaluated multiple times. That can cause problems if they have side effects,
and might not even compile if the overall expression is ambiguous, for
instance if you pass in foo++.

Built with code that previously wouldn't compile because the macros
expanded to ambiguous expressions.

Change-Id: I378c04d7aff5b4ad40581930ce90e49ba7df1d3e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoSupport ITE IT8518 embedded controller running Quanta's firmware
Stefan Reinauer [Thu, 14 Mar 2013 00:03:04 +0000 (17:03 -0700)]
Support ITE IT8518 embedded controller running Quanta's firmware

Change-Id: Ib406b9d5005243d79eea5d2c0c6c86b5aa949891
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2721
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Generalize and redistribute timekeeping code
Gabe Black [Sat, 23 Feb 2013 00:38:53 +0000 (16:38 -0800)]
libpayload: Generalize and redistribute timekeeping code

The timekeeping code in libpayload was dependent on rdtsc, and when it was
split up by arch, that code was duplicated even though it was mostly the same.
This change factors out actually reading the count from the timer and the
speed of the timer and puts the definitions of ndelay, udelay, mdelay and
delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value
functions which used to be in depthcharge were moved over to libpayload's
arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those
functions are omitted with the intention that they'll be implemented by a
specific timer driver chosen elsewhere.

Change-Id: I9c919bed712ace941f417c1d58679d667b2d8269
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2717
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Put dump_td/dump_ed in ohci.c behind #ifdef USB_DEBUG
Gabe Black [Wed, 16 Jan 2013 11:18:45 +0000 (03:18 -0800)]
libpayload: Put dump_td/dump_ed in ohci.c behind #ifdef USB_DEBUG

This function is static and not used in that file. To avoid the compiler
complaining about that fact, put the two functions and the call to dump_ed
(currently #if 0) behind #ifdef USB_DEBUG

Change-Id: Ic373313b5fff81f09800f286b32238350ab699c6
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: always use MMIO PCI config accesses
Aaron Durbin [Thu, 1 Nov 2012 03:57:16 +0000 (22:57 -0500)]
haswell: always use MMIO PCI config accesses

Add a bootblock.c file for the northbridge and setup the
PCIEXBAR as the first thing using IO PCI config acceses.
After that all PCI config accesses can use MMIO.

Change-Id: I51d229c626c45705dda1757c2f14265cbc0e6183
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2617
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agohaswell: Add initial support for Haswell platforms
Aaron Durbin [Tue, 30 Oct 2012 14:03:43 +0000 (09:03 -0500)]
haswell: Add initial support for Haswell platforms

The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore,
the southbridge support is included as well. The basis for this code is
the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires
more attention, but this is a good starting point.

This code partially gets up through the romstage just before training
memory on a Haswell reference board.

Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2616
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Don't declare the loop counter within the for loop
Gabe Black [Sat, 2 Mar 2013 11:32:19 +0000 (03:32 -0800)]
libpayload: Don't declare the loop counter within the for loop

'for' loop initial declarations are only allowed in C99 mode

I didn't realize we don't enable 14 year old features when building
libpayload, and I must have accidentally not rebuilt everything when making my
final tweaks to my earlier change.

Change-Id: I6caeeffad177b6d61fa30175f767e85084c061f4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2718
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
7 years agoexynos5250: add RAM resource beginning at physical address
David Hendricks [Wed, 13 Mar 2013 03:16:44 +0000 (20:16 -0700)]
exynos5250: add RAM resource beginning at physical address

The original code attempted to reserve a space in RAM for coreboot to
remain resident. This turns out not to be needed, and breaks things
for the kernel since the exynos5250-smdk5250 kernel device tree starts
RAM at 0x40000000.

(This patch was originally by Gabe, I'm just uploading it)

Change-Id: I4536edaf8785d81a3ea008216a2d57549ce5edfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2698
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
7 years agoEagleheights DSDT: Grant OS control through OSC
Mike Loptien [Wed, 13 Mar 2013 22:28:16 +0000 (16:28 -0600)]
Eagleheights DSDT: Grant OS control through OSC

Change the OSC method to actually grant control of
PCIe capabilities to the OS instead of granting no
control.  I believe the logic was backwards in the
original commit.  Bits should be set when granting
control and cleared when not granting control.  By
setting the return value to 0x00, we effectively
tell the OS that it cannot control any PCIe
capability.  See section 6.2.9 of the ACPI spec
version 3.0 for more information.

This edit is a duplication of the OSC method that
is in the src/southbridge/intel/bd82x6x/pch.asl
file.

Change-Id: Id2462ab12203afceb9033f24d06b4dfbf2236d2e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2714
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Don't do unaligned accesses during LZMA decompression
Gabe Black [Wed, 6 Mar 2013 12:46:00 +0000 (04:46 -0800)]
libpayload: Don't do unaligned accesses during LZMA decompression

Use memcpy to access a uint32_t that's inherently unaligned due to the layout
of the LZMA header format.

Built and booted on Daisy and saw a data abort go away. Built and booted
into developer mode on Link and verified that bitmaps were
decompressed/displayed correctly.

Change-Id: Id3ae746c04d23bcb0345cb71797bfa219479cc8f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2670
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Add size_t and ssize_t types for ARM and x86
Gabe Black [Wed, 27 Feb 2013 07:18:24 +0000 (23:18 -0800)]
libpayload: Add size_t and ssize_t types for ARM and x86

Some new TPM drivers in depthcharge require that type. I added it to
arch/types.h which seemed appropriate, but I'm not sure that's exactly the
right header to use, or in other words if you'd get that type from libpayload
the same way you'd get it if you were building a standard Linux program.

Also, I attempted to determine what underlying types gcc would use, and while
I think I picked the right ones I'm not 100% certain of that either.

Change-Id: Ic5c0b4173c8565ede3bfce8870976d596d69e51d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2669
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Move over to the payload's stack during startup
Gabe Black [Wed, 27 Feb 2013 03:08:28 +0000 (19:08 -0800)]
libpayload: Move over to the payload's stack during startup

Don't keep using the coreboot stack on ARMv7.

Change-Id: I734c5d77f8584e30ee0c720d41e21e3040f56db4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2668
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoexynos5250/snow: enable branch prediction
David Hendricks [Wed, 13 Mar 2013 05:00:43 +0000 (22:00 -0700)]
exynos5250/snow: enable branch prediction

This enables branch prediction. We can probably find a better place
to do this, but for now we'll do it in snow's romstage main().

Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2701
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: ARCH-$(CONFIG_ARCH_ARMV7) was defined twice, make one POWERPC
Gabe Black [Wed, 16 Jan 2013 11:18:02 +0000 (03:18 -0800)]
libpayload: ARCH-$(CONFIG_ARCH_ARMV7) was defined twice, make one POWERPC

Change-Id: Ia85a7cd6a0b85119cce6b2f9c42a7fc31ffd9f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2654
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Add usb_generic_(create|remove) functions for unrecognized devices
Gabe Black [Sat, 2 Feb 2013 04:19:27 +0000 (20:19 -0800)]
libpayload: Add usb_generic_(create|remove) functions for unrecognized devices

It might be useful to provide a USB driver in the payload itself instead of in
libpayload. For example there are multiple payloads being built and linked
against the same libpayload, and they might not need or even want to have the
same set of drivers installed.

This change adds two new functions, usb_generic_create and usb_generic_remove,
which behave like the usbdisk_create and usbdisk_remove functions which are
defined for USB mass storage devices. If a USB device isn't recognized and
claimed by one of the built in USB class drivers (currently hub, hid, and msc)
and the create function is defined, then it will be called to give the payload
a chance to use the device. Once it's removed, if usb_generic_remove is
defined it will be called, effectively giving the payload notice.

Built and booted depthcharge on Link. Built depthcharge for Daisy. Built
a netbooting payload, called usb_poll() with those functions implemented, and
verified that they were called and that the devices they were told about were
reasonable and the same as what was reported by lsusb in the booted system.

Change-Id: Ief7c0a513b60849fbf2986ef4ae5c9e7825fef16
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2666
Tested-by: build bot (Jenkins)
Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Split EHCI bulk transfers on packet boundaries over qTDs
Julius Werner [Sat, 12 Jan 2013 00:25:52 +0000 (16:25 -0800)]
libpayload: Split EHCI bulk transfers on packet boundaries over qTDs

EHCI controllers see transfers as a queue of transfer descriptors
(qTDs), each of which can represent an aligned area of up to 20KB. Each
qTD is processed separately, which means that a single USB packet cannot
span multiple qTDs.

While this should not be a problem according to the specification, some
USB storage devices seem to get confused when a packet in the middle of
a transfer is smaller than the maximum packet size (512 bytes) due to
falling on a qTD boundary. This patch aligns the total transfer length
per qTD to 512 bytes to avoid that problem (any excess bytes will simply
roll over to the next qTD).

Change-Id: I0b5db07507699a3861b30c1a5ee774c45dda7fdd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/2651
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: add support for 64-bit EHCI controllers
Vincent Palatin [Fri, 26 Oct 2012 00:38:43 +0000 (17:38 -0700)]
libpayload: add support for 64-bit EHCI controllers

Initialize the high part of the address
and use 64-bit compatible descriptors.
(waste a few bytes on 32-bit but should be harmless)

Read USB stick on a SandyBridge system which has 64-bit EHCI.

Change-Id: I59cc842459acecdde8f8bdd4795ebfeccb842c8f
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2650
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Stub out time keeping functions for ARM as well
Gabe Black [Fri, 18 Jan 2013 23:04:07 +0000 (15:04 -0800)]
libpayload: Stub out time keeping functions for ARM as well

These were currently stubbed out for PowerPC but not for ARM.

Change-Id: I08f45174877bf5751d972078b8c53d82898b7f2b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2655
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: If no video drivers initialize in video_init, return 1.
Gabe Black [Tue, 15 Jan 2013 23:48:55 +0000 (15:48 -0800)]
libpayload: If no video drivers initialize in video_init, return 1.

Change-Id: I56f810dfa6654ac1e9d1696ad15e7f1b8bfe59bd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2652
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agolibpayload: If there's no IO address space, don't try to use it for serial
Gabe Black [Sat, 19 Jan 2013 02:37:29 +0000 (18:37 -0800)]
libpayload: If there's no IO address space, don't try to use it for serial

Change-Id: I01b1fa42139af925716cd5d57f96dc24da6df5a7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2660
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: If there's no IO space, complain if the serial claims to use it
Gabe Black [Sat, 19 Jan 2013 02:24:46 +0000 (18:24 -0800)]
libpayload: If there's no IO space, complain if the serial claims to use it

Change-Id: I36c750d520ff034c9ca9b9af46bd99bd49af7355
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2659
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Consolidate io vs. mem mapped serial into accessor functions
Gabe Black [Sat, 19 Jan 2013 02:04:44 +0000 (18:04 -0800)]
libpayload: Consolidate io vs. mem mapped serial into accessor functions

This way we won't have two copies of the hardware init function, and three
copies of the putchar, havechar, and getchar functions.

Change-Id: Ifda7fec5d582244b0e163ee93ffeedeb28ce48da
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2657
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Make whether or not there's an IO address space configurable
Gabe Black [Fri, 18 Jan 2013 23:49:00 +0000 (15:49 -0800)]
libpayload: Make whether or not there's an IO address space configurable

Default it to no to be consistent with the other architecture wide options
(endianness), and turn it on explicitly for x86 and PowerPC.

Change-Id: Idda26d580156bbbf08ea11b28abe75cfa6b594b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2658
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoUpdate 3rdparty mark to latest repository
Stefan Reinauer [Mon, 11 Mar 2013 21:50:30 +0000 (14:50 -0700)]
Update 3rdparty mark to latest repository

For google/stout binaries

Change-Id: I4ef3f9cc35dfb6d27e1c9f074759f0e3ddee73c4
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2635
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Start using only internal and compiler headers.
Ronald G. Minnich [Wed, 13 Mar 2013 20:42:55 +0000 (13:42 -0700)]
libpayload: Start using only internal and compiler headers.

When building other payloads with lpgcc the -nostdinc flag was injected into
CFLAGS, but when building libpayload itself some headers were being used from
the host system. This change puts -nostdinc into the Makefile and xcompile
script, fixes up one include path in include/inttypes.h, adds the compiler
provided include directory to the include search path, and deletes the two now
redundant stdint.h files.

BUG=None
TEST=With this and other changes, built libpayload and depthcharge for Daisy,
Link, and Fox.
BRANCH=None

Change-Id: Ia7817fceab5297cd82ccc0d392330de0df61980e
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2710
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
7 years agolibpayload: Add more parenthesis to the endian conversion macros
Gabe Black [Thu, 31 Jan 2013 12:27:39 +0000 (04:27 -0800)]
libpayload: Add more parenthesis to the endian conversion macros

There weren't enough parenthesis in the macros so operations might only apply
to the last part of an expression passed in as an argument.

Change-Id: I5afb406f9409986e45bbbc598bcbd0dd8507ed35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2665
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agolibpayload: Make the source for lzma decompression const
Gabe Black [Tue, 12 Feb 2013 04:43:45 +0000 (20:43 -0800)]
libpayload: Make the source for lzma decompression const

Change-Id: I9a16331dedc97f17af94bf2cf535a9c93d1729a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2667
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
7 years agosrc/mainboard: Drop redundant `CHIP_NAME` again for new ports
Paul Menzel [Wed, 13 Mar 2013 12:29:44 +0000 (13:29 +0100)]
src/mainboard: Drop redundant `CHIP_NAME` again for new ports

Since commit »Drop redundant CHIP_NAME in mainboard.c« (a93c3fe7) [1]
`CHIP_NAME` is unneeded for mainboards as the name is composed
automatically in `src/devices/root_device.c` from the strings in
Kconfig.

Unfortunately the ports for Google Butterfly, Link and Parrot as
as well as IEI PM-LX2-800-R10 introduced CHIP_NAME again. So drop
it again too.

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

Change-Id: Ice7577a2a5c6070e196f2647c440b7a8e140e27e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2708
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayloads: Provide BSD/glibc style endian functions.
Hung-Te Lin [Wed, 13 Mar 2013 10:08:29 +0000 (18:08 +0800)]
libpayloads: Provide BSD/glibc style endian functions.

The functions in endian.h (betoh{l,w,ll} and others) were named differently from
the well-known BSD/glibc style endian functions (ex, betoh{16,32,64}). We should
provide the BSD/glibc style functions to prevent confusion.

Change-Id: Ia3bee481ba7989ac25b79ddb89bc6819d52fd8c3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2705
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoexynos5250: Don't set PS_HOLD in bootblock_cpu_init
David Hendricks [Wed, 13 Mar 2013 04:38:19 +0000 (21:38 -0700)]
exynos5250: Don't set PS_HOLD in bootblock_cpu_init

PS_HOLD gets set in exynos' power_init().

Change-Id: Ib08e0afcad23cbd07dc7e3727fd958a1bc868b5a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2700
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoexynos5250/snow: call PMIC's power_init() function
David Hendricks [Wed, 13 Mar 2013 04:28:07 +0000 (21:28 -0700)]
exynos5250/snow: call PMIC's power_init() function

Call the power_init() function. We appear to have forgotten about it
when deprecating lowlevel_init_subsystems(), but it didn't seem to
cause problems until we got to doing more interesting stuff recently.

There are some clean-ups to do from the original code, such as not
attempting to configure I2C from PMIC code, which we'll get around
to in follow-up patches.

(Credit to Gabe for spotting this)

Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2699
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agolibpayload: Remove unnecessary include of arch/msr.h
Gabe Black [Fri, 18 Jan 2013 23:14:03 +0000 (15:14 -0800)]
libpayload: Remove unnecessary include of arch/msr.h

The functions defined in that header aren't used anywhere in the actual code,
and that include breaks things on ARM.

Built for ARM with COREBOOT_VIDEO_CONSOLE turned on and saw compiler
errors go away.

Change-Id: I56d6fe5e00c8fccda6e31ef8752326bd36398e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2656
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agolibpayload: In the USBMSC read_capacity function, make buf an array of u32.
Gabe Black [Wed, 16 Jan 2013 00:22:04 +0000 (16:22 -0800)]
libpayload: In the USBMSC read_capacity function, make buf an array of u32.

That way when it's treated as a u32 when its value is extracted for numblocks
and blocksize below, it doesn't make the compiler unhappy, and it ensures that
the buffer will be properly aligned on architectures where that sort of thing
matters.

Built and saw warnings about type punning go away.

Change-Id: I254e0b5e70847112d660675b7df0ac9cb52e4051
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2653
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agoAMD CIMx SB800: Enable AHCI mode for SATA controller by default
Paul Menzel [Tue, 12 Mar 2013 11:41:40 +0000 (12:41 +0100)]
AMD CIMx SB800: Enable AHCI mode for SATA controller by default

The current default is IDE mode which is slower compared to AHCI
mode. Therefore use AHCI mode by default.

A similar change was made for AMD Persimmon in commit
»Enable SATA AHCI for faster boot with SeaBIOS.« (96be74c7) [1]
but was indirectly reverted by »sb800: Add sata ahci/raid mode
kconfig option« (d4a0e7d0) [2].

[1] http://review.coreboot.org/220
[2] http://review.coreboot.org/225

Change-Id: I4fa31b0a3280891e7a3f37675ae8415205818947
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2661
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agowatchdog.h: Fix compile time error on disabling watchdog handling
Patrick Georgi [Mon, 11 Mar 2013 17:32:50 +0000 (18:32 +0100)]
watchdog.h: Fix compile time error on disabling watchdog handling

There's a compile time error that we didn't catch since the
board defaults as used by the build bot won't expose it.

Just make watchdog_off() a no-op statement so there aren't any
stray semicolons in the preprocessor output.

Change-Id: Ib5595e7e8aa91ca54bc8ca30a39b72875c961464
Reported-by: 'lautriv' on irc.freenode.net/#coreboot
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2627
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agolibpayload: Fix reading x86 CBFS images from RAM
Patrick Georgi [Sat, 9 Mar 2013 09:52:50 +0000 (10:52 +0100)]
libpayload: Fix reading x86 CBFS images from RAM

Three issues:
 1. the hardcoded dereferenced pointer at 0xfffffffc
 2. "RAM media" has no idea about ROM relative addresses
 3. off-by-one in RAM media: it's legal to request 4 bytes from 0xfffffffc

Change-Id: I671ac12d412c71dc8e8e6114f2ea13f58dd99c1d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2624
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
7 years agoFix 'git describe' invocation
Vadim Bendebury [Mon, 10 Dec 2012 23:47:23 +0000 (15:47 -0800)]
Fix 'git describe' invocation

The 'git describe' command is used to obtain the source tree status
information when building coreboot. As used this command expects git
tags to be defined, so it can report the discrepancy between the
current state of the tree and the latest tag.

The problem is that the coreboot source tree does not have any git
tags defined, so when 'git describe' is invoked, it reports "fatal: No
names found, cannot describe anything.". This scary message can be
seen on the console during coreboot builds.

The solution is to add --always to the `git describe' invocation,
which causes it to report the discrepancy with the latest sha1, if
any, which is better than nothing.

  $ rm -rf /tmp/li && mkdir /tmp/li
  $ cp configs/config.link .config
  $ make obj=/tmp/li oldconfig
  $ make obj=/tmp/li
  $ grep COREBOOT_VERSION /tmp/li/build.h
  #define COREBOOT_VERSION "1623c06"
  $ echo '#' >> Makefile.inc
  $ grep COREBOOT_VERSION /tmp/li/build.h
  $ make obj=/tmp/li
  #define COREBOOT_VERSION "1623c06-dirty"
  $ git checkout Makefile.inc

Change-Id: Ia77428b7cd765cbbd59bdbf8251b7bef489d47a5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/2637
Tested-by: build bot (Jenkins)
7 years agopci.h: Drop unused `mainboard_pci_subsystem*` prototypes
Patrick Georgi [Sat, 9 Mar 2013 12:24:43 +0000 (13:24 +0100)]
pci.h: Drop unused `mainboard_pci_subsystem*` prototypes

We used to allow mainboards to override subsystems using
mainboard_pci_subsystem_vendor_id and mainboard_pci_subsystem_device_id.

Mechanisms have changed and the only occurrence of these names is in
the header.

Change-Id: Ic2ab13201a2740c98868fdf580140b7758b62263
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2625
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
7 years agoASUS M5A88-V: Kconfig: Fix mainboard model name
Paul Menzel [Fri, 8 Mar 2013 11:10:16 +0000 (12:10 +0100)]
ASUS M5A88-V: Kconfig: Fix mainboard model name

Despite everywhere the model name M5A88-V is used, in Kconfig the
string M5A88PM-V is used. Searching for that model string on the
WWW does not return anything which is unrelated to coreboot, so
change that string to M5A88-V.

Change-Id: I25cf9d4a5fc3f9b9356e8616452066ebf873f44c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2613
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: QingPei Wang <wangqingpei@gmail.com>
7 years agoAdd Intel Panther Point USB3 initialization
Marc Jones [Tue, 13 Nov 2012 22:07:45 +0000 (15:07 -0700)]
Add Intel Panther Point USB3 initialization

Add PEI updates and ACPI updates for supporting EHCI to XHCI
USB port support.

Change-Id: I9ace68a1b3950771aefb96c1319b8899291edd9a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2519
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
7 years agoPersimmon DSDT: Add secondary bus range to PCI0
Mike Loptien [Tue, 5 Mar 2013 21:21:28 +0000 (14:21 -0700)]
Persimmon 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 change will apply to other AMD mainboards and
will be in a different commit.

Change-Id: I44f22bc03a0dcbcd2594d4291508826cc2146860
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2592
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agoEliminate do_div().
David Hendricks [Thu, 7 Mar 2013 04:43:55 +0000 (20:43 -0800)]
Eliminate do_div().

This eliminates the use of do_div() in favor of using libgcc
functions.

This was tested by building and booting on Google Snow (ARMv7)
and Qemu (x86). printk()s which use division in vtxprintf() look good.

Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
7 years agoAMD Inagua: Use SPD read code from F14 wrapper
Kimarie Hoot [Wed, 6 Mar 2013 23:18:09 +0000 (16:18 -0700)]
AMD Inagua: Use SPD read code from F14 wrapper

Changes:
 - Get rid of the inagua mainboard specific code and use the
   platform generic function wrapper that was added in change
   http://review.coreboot.org/#/c/2497/
   AMD f14: Add SPD read functions to wrapper code

 - Move DIMM addresses into devicetree.cb

 - Add the ASF init that used to be in the SPD read code into
   mainboard_enable()

Notes:
 - The DIMM reads only happen in romstage, so the function is not
   available in ramstage.  Point the read-SPD callback to a generic
   function in ramstage.

Change-Id: Id05227fcf18c6ab94ffe1beb50b533ab7b0535db
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2607
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agoAMD CIMx SB800 boards: platform_cfg.h: Integrate Kconfig SATA Mode choice
Paul Menzel [Sun, 3 Mar 2013 09:56:15 +0000 (10:56 +0100)]
AMD CIMx SB800 boards: platform_cfg.h: Integrate Kconfig SATA Mode choice

Currently for Advansus A785E-I, ASRock E350M1 and ASUS M5A88-V
despite what is chosen in Kconfig »Chipset« menu item,

    $ more .config
    […]
    # CONFIG_ENABLE_IDE_COMBINED_MODE is not set
    CONFIG_IDE_COMBINED_MODE=0x1
    # CONFIG_SB800_SATA_IDE is not set
    CONFIG_SB800_SATA_AHCI=y
    # CONFIG_SB800_SATA_RAID is not set
    CONFIG_SB800_SATA_MODE=0x2
    […]

the SATA controller is put into IDE mode.

    $ lspci -nn | grep SATA
    00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (rev 40)

Commit »sb800: Add sata ahci/raid mode kconfig option«
(d4a0e7d0) [1] added the options above to configure the mode
using Kconfig and some SB800 boards were adapted already. For
example commit »persimmon: sb800 sata mode configure update«
(1386fa74) [2] did so for AMD Persimmon.

Doing the same by assigning the Kconfig variable to the value in
`platform_cfg.h` integrates this with the three remaining boards
listed above.

The patch is successfully tested with the ASRock E350M1.

    $ lspci -nn | grep SATA
    00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)

[1] http://review.coreboot.org/225
[2] http://review.coreboot.org/227

Change-Id: I227257e2c8f04f18c27ff00fe62d42e372de67e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2610
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
7 years agoAMD Persimmon: mainboard.c: Make comment generic to reduce difference
Paul Menzel [Thu, 7 Mar 2013 21:41:25 +0000 (22:41 +0100)]
AMD Persimmon: mainboard.c: Make comment generic to reduce difference

Replace »persimmon« by »board« in comment to keep `diff` output
between boards small.

Change-Id: Ieae2a63782c488ae35f22eb30f5b1049200d12c8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
7 years agoAMD Union Station: Use SPD read code from F14 wrapper
Kimarie Hoot [Thu, 7 Mar 2013 16:10:29 +0000 (09:10 -0700)]
AMD Union Station: Use SPD read code from F14 wrapper

Changes:
 - Get rid of the union_station mainboard specific code and
   use the platform generic function wrapper that was added
   in change http://review.coreboot.org/#/c/2497/
   AMD f14: Add SPD read functions to wrapper code

 - Move DIMM addresses into devicetree.cb

 - Add the ASF init that used to be in the SPD read code into
   mainboard_enable()

Notes:
 - The DIMM reads only happen in romstage, so the function is not
   available in ramstage.  Point the read-SPD callback to a generic
   function in ramstage.

Change-Id: I19d6b0d674b67294519383f80928471b37da1e14
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2609
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agoAMD South Station: Use SPD read code from F14 wrapper
Kimarie Hoot [Thu, 7 Mar 2013 15:54:36 +0000 (08:54 -0700)]
AMD South Station: Use SPD read code from F14 wrapper

Changes:
 - Get rid of the south_station mainboard specific code and
   use the platform generic function wrapper that was added
   in change http://review.coreboot.org/#/c/2497/
   AMD f14: Add SPD read functions to wrapper code

 - Move DIMM addresses into devicetree.cb

 - Add the ASF init that used to be in the SPD read code into
   mainboard_enable()

Notes:
 - The DIMM reads only happen in romstage, so the function is not
   available in ramstage.  Point the read-SPD callback to a generic
   function in ramstage.

Change-Id: If4291d25ea81bf375f55b64c07c223a847a211d0
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2608
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
7 years agoARMV7 and Google/Snow: Add exception support code to the ramstage
Ronald G. Minnich [Thu, 7 Mar 2013 23:23:45 +0000 (15:23 -0800)]
ARMV7 and Google/Snow: Add exception support code to the ramstage

This is previously used exception code from libpayload.
On startup it installs and then tests an exception handler.
The test is an unaligned memory operation.

Yes, we've seen what might be exceptions in the ramstage, and
it makes sense to handle them. This code is identical in structure
and operation to the previously committed payload exception handler,
though we reserve the right to change it as circumstances require.

The remaining question is whether we need it in romstage.

Change-Id: I24484686c33c9757af8ba171ebae9773828fb69d
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2614
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
7 years agoAGESA: Fix CR0_PE bit define
Konstantin Aladyshev [Wed, 6 Mar 2013 18:13:42 +0000 (22:13 +0400)]
AGESA: Fix CR0_PE bit define

AGESA code has wrong definition of CR0_PE bit (1 instead of 0).

PE [Protected Mode Enable] is 0 bit in CR0 register
(If PE=1, system is in protected mode, else system is in real mode)

Bit 1 is MP [Monitor co-processor]
(Controls interaction of WAIT/FWAIT instructions with TS flag in CR0)

System uses CR0_PE define, but I didn't expect any consequences because of this bug.

Change-Id: I54d9a8c0ee3af0a2e0267777036f227a9e05f3e1
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2591
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agoSupermicro H8QGI: set up right frequency limits for memory controller
Konstantin Aladyshev [Wed, 6 Mar 2013 17:39:40 +0000 (21:39 +0400)]
Supermicro H8QGI: set up right frequency limits for memory controller

According to BKDG:
"Memory controller (MCT) and DRAM controllers (DCTs) additions:
• Support for 933 MHz (1866 MT/s) MEMCLK frequency."

Change-Id: I6f307ce3fcb355d5445f1ea86def73a41b928a57
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2589
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agoAGESA: Fix bug in AMD_DISABLE_STACK_FAMILY_HOOK_F15
Konstantin Aladyshev [Wed, 6 Mar 2013 15:58:38 +0000 (19:58 +0400)]
AGESA: Fix bug in AMD_DISABLE_STACK_FAMILY_HOOK_F15

_RDMSR instruction loads the contents of a 64-bit model specific register (MSR)
specified in the ECX register into registers EDX:EAX.
The EDX register is loaded with the high-order 32 bits of the MSR
and the EAX register is loaded with the low-order 32 bits.

EDX:EAX = MSR[ECX]

So bit 49 will be contained in EDX register.

Buggy code instead of bit 49 (CombineCr0Cd) sets bit [49-32=17] (PfcStrideDis).
PfcStrideDis bit disables stride prefetch generation. This leads to memory
bandwidth loss.

_________

Supermicro H8QGI board

After applying this change i observed huge memory bandwidth increase in tests
that runs on small amount of cores. But unfortunately it doesn't affect
overall bandwidth results on 4P system with 48 cores.
So i think that in this system leading limiting factor is
AMD HT-ASSIST feature (Probe filter).

But right now it is not working. System stucks in Linux boot. I have done
some experiments and figured out that stuck happens when system have cores in
compute unit (CU) other than CU with BSC (boot strap core).
CU is two cores (primary and seconary) that shares some things (L2 cache, FPU ...)
So with probe filter i can boot Linux with one (BSC)
or two (BSC + secondary core in its CU) cores.
And with this configuration i can see memory bandwidth on 1 core (or two cores)
close to original bios.

Change-Id: I5a95f5b753d600c70d3c93d36fecc687610c61cd
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2588
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
7 years agoFrontRunner/Toucan-AF: lower SPI speed to 22 MHz
Jens Rottmann [Thu, 7 Mar 2013 18:02:15 +0000 (19:02 +0100)]
FrontRunner/Toucan-AF: lower SPI speed to 22 MHz

The Hudson-E1's default SPI speed for normal i.e. non-fast reads is 66 MHz,
but the SST 25VF032B datasheet allows max. 25.  Lower the speed to 22 MHz,
otherwise BIOS flashing fails.

Change-Id: I22e87d833a3ebd316b6e873595a2480831533ab1
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2605
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>