crossgcc: Update IASL to latest version (20140114)

Change-Id: I2450cad4a43907b8ca6d8f4d35932d7f451f71ea
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5116
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
google/rambi: Do not select CHROMEOS in Kconfig

CHROMEOS is the meant to be selected by the user. The correct variable
for a mainboard to select is MAINBOARD_HAS_CHROMEOS. This will then
default to a CHROMEOS build, but when the mainboard selects CHROMEOS,
the user can no longer disable CHROMEOS.

Change-Id: I78fb15a0a9fef733e2de064d6c09cf774b7bce78
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5218
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
libpayload/ahci: Fix a warning by decompartmentalise the AHCI driver.

Decompartmentalise AHCI driver into two parts, ATA and ATAPI. Add a few
superficial comments while here. This also fixes a compiler warning.

Change-Id: Ia1fd545b39868a81cbc311f6ffc786f9f1f61415
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/4783
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
x86: provide stage_exit() like arm

The arm architectures have a stage_exit() function
which takes a void * pointer as an entry point. Provide
the same API for x86. This can make the booting paths
less architecture-specific.

Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5086
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
coreboot: infrastructure for different ramstage loaders

There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.

To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.

Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
console/uart8250*: Remove inclusion of mc146818rtc.h

The RTC functionality provided by the include is specific to x86, but
is not used in these files.

Change-Id: I82d0dfdb6e8b67bc81291a7a5d63ced91e095772
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4586
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
lenovo/x60: Fix EDID byte-swapping.

Change-Id: I75305ff7c5a8ba6142ef460e813acc014d9992bb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5249
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
lenovo/x60: Change to common EDID framework.

Currently lenovo/x60 gfx init provides vbe_mode_info_valid in
incompatible way. Use EDID framework as do other inits.

Change-Id: I887abd5a09064f26f473a2bf9caa2eb33e269c07
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5238
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Jetway NF81-T56N-LF [1/2]: create board by forking AMD Persimmon

Step 1: copy all files unmodified from Persimmon.  This makes it much
easier later to see how the two boards actually and deliberately differ
when porting bugfixes from one to the other.

Change-Id: I23e223049ed1c69e320e6b31efe4266bfeb97207
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/4800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Jetway NF81-T56N-LF [2/2]: actually implement mainboard support.

Step 2: change the Persimmon code to adapt it to the new board's hardware.

The NF81-T56N-LF is a IPC form factor embedded board:
- AMD Fusion G-T56N (1.65 GHz dual core) APU
  - 2x SO-DIMM sockets for DDR3 800-1066 SDRAM (Fixed at 1.5V)
  - VGA and LVDS (via Analogix ANX3110)
- AMD A55E (Hudson-E1) southbridge
  - 6x USB 2.0/1.1 ports
  - 5x SATA3 6Gb/s, 1x mSATA socket
  - 6-Channel HD Audio (via VIA VT1705)
  - PCI and ISA (via ITE IT8888)??
  - NEC uPD78F0532 microcontroller on I2C ("SEMA")??
- 2x RJ45 GbE (via Realtek RTL8111E x2)
- Fintek F71869AD Super I/O
  - PS/2 KB/MS port
  - RS232 header (via Unisonic UTC 75232 RS232 driver/receiver)
  - GPIO header
  - CIR header
- 1x MXIC MX25L1606E (SO8, soldered) 16 Mbit SPI flash (BIOS)

Note: MX25L1606E is 16Mbit, 8bits in a byte, so 2MB. Jetway *lies*
claiming the SPI flash is 16MB. They also use red pen over the chip
so you wont see this deceit.

Change-Id: I03ccc58bc782e800aeef0d19679ce060277b0c04
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/4801
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
usbdebug: Remove EHCI_DEBUG_OFFSET

Read this variable from PCI configuration capabilities list instead.

Change-Id: I0cfe981833873397c32cd3aa2af307f35f01784b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5176
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
baytrail: fix tsc rate

Despite some references to a fixed bclk in some of the
docs the bclk is variable per sku. Therefore, perform
the calculation according to the BSEL_CR_OVERCLOCK_CONTROL
msr which provides the bclk for the cpu cores in Bay Trail.

BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted B3. correctly says: clocks_per_usec: 2133

Change-Id: I55da45d42e7672fdb3b821c8aed7340a6f73dd08
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172771
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4883
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
baytrail: correct MMC pci location

The original documentation was incorrect. Fix the pci
device for the MMC port to reflect reality.

MMC is at 00:17.0 with a device id of 0x0f50.

BUG=None
BRANCH=None
TEST=Built.

Change-Id: Ic18665b7dda5f386e72d1a5255e4e57d5b631eb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172772
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4884
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
rambi: disable internal pullups on ram_id[2:0]

The ram_id[2:0] signals have stuffing options for pull up/down
with values of 10K. However, the default pulldown values for these
pads are 20K. Therefore, one can't read a high value because of
the high voltage threshold is 0.65 * Vref. Therefore the high
signals are marginal at best.

Fix this issue by disabling the internal pull for the pads connected
to ram_id[2:0].

BUG=chrome-os-partner:23350
BRANCH=None
TEST=Built and checked that ram_id[2:0] is properly read now.

Change-Id: Ib414d5798b472574337d1b71b87a4cf92f40c762
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173211
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: http://review.coreboot.org/4885
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
baytrail: Modify GPIO pull-up specification method

Minor style changes to the way GPIO pull-ups are specified in
board-specific GPIO maps. Intent is to allow calls to GPIO_FUNC macro
from such maps.

BUG=chrome-os-partner:22863
TEST=Manual. Build + boot on bayleybay.

Change-Id: I80134b65d22d3ad8a049837dccc0985e321645da
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173748
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4886
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
rambi: add BSP lapic device

There's some baked in assumptions internal to coreboot
that the BSP's cpu device exists in the device tree. Therefore
provide one in the device tree.

BUG=chrome-os-partner:22862
BRANCH=None
TEST=Compiled and booted with other changes.

Change-Id: I22ba10964760ee8efbc5bbd5d4ce65daf31b3839
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173702
Reviewed-on: http://review.coreboot.org/4887
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
baytrail: bring up APs

Bring up the APs using x86 MP infrastructure.

BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi. Noted all cores are brought up.

Change-Id: I9231eff5494444e8eb17ecdc5a0af72a2e5208b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173704
Reviewed-on: http://review.coreboot.org/4889
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
intel/jarrell: Fix missing include

To unconditionally get cmos_read().

Change-Id: I0af0e85c8a1f42113bd32b51c4e29e86b3c28112
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5228
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
x86: provide infrastructure to backup default SMM region

Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.

Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
haswell: backup the default SMM region on resume

Haswell CPUs need to use the default SMM region for
relocating to the desired SMM location. Back up that
memory on resume instead of reserving the default
region. This makes the haswell support more forgiving
to software which expects PC-compatible memory layouts.

Change-Id: I9ae74f1f14fe07ba9a0027260d6e65faa6ea2aed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>