... based on the EDID detailed timing values for
pixel_clock and link_clock.
Two undocumented registers 0x6f040 and 0x6f044 correspond to link_m and link_n
respectively. Other two undocumented registers 0x6f030 and 0x6f034 correspond
to data_m and data_n respectively.
Calculations are based on the intel_link_compute_m_n from linux kernel.
Currently, the value for 0x6f030 does not come up right with our calculations.
Hence, set to hard-coded value.
Change-Id: I40ff411729d0a61759164c3c1098504973f9cf5e
Reviewed-on: https://gerrit.chromium.org/gerrit/62915
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This code is left over from what the VBIOS did; It is redundant.
Change-Id: I321c867c81ec8b4d5e10f8b51b872cecb3082d97
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62290
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4380
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Turn on the pei_data flag that will instruct the reference code
binary to route all USB ports to the XHCI controller on resume and
disable the EHCI controller(s).
Change-Id: I2f2ed853a6d17f90ea524bc516f3e78079222739
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63798
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4404
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The linux kernel will unconditionally route all USB
ports to the XCHI controller at boot. The EHCI controller
can then be disabled, and it should be left disabled
by the reference code when this is done.
However not all OS may do this unconditional route,
so provide an option to the reference code binary to
enable this behavior.
Change-Id: Iedf5af54182bf109cd1119c1999e46300665d41e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63797
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4403
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
SATA is routed to PIRQG which should be interrupt 22
and not interrupt 21. The kernel uses MSI with this
device so this is only seen when booting with pci=nomsi
Change-Id: Ic90ca2c561fc4c53ec1d395c05872222c65ff98a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63796
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4398
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Since these boards do not support C10 we should not bother
advertising that state in the ACPI _CST.
Instead use this map:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C3)
ACPI(C3) = MWAIT(C7S)
Change-Id: I37eb02bf9555c74e957316a1ba9778eb2b6ee128
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62898
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4377
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The management engine is occasionally hanging the system on resume
when it is accessed. Since we actually don't need to do anything
with it on resume it can be disabled early in the resume path and
avoid assigning resources just to remove them later.
suspend/resume on falco and check /sys/firmware/log
to ensure that device 00:16.0 is disabled early and that no
resources are probed or assigned and that the device init path
does not execute.
Change-Id: I35573681e3a1d43d816d24954842cbe9c61f3484
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4376
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The management engine is slow, requiring at least 500ms between
when the Dram Init Done message is sent (right after memory training)
to when the MBP will report that it is successfully cleared and
that the ME can finally be sent the EOP message.
Currently this is adding 100-150ms to the boot time. If we defer
waiting for the MBP Clear indicator until the finalize step we
can gain back that lost time.
boot on falco with SMI debugging enabled to
ensure that the ME is locked down in the finalize step:
Finalizing Coreboot
SMI# #0
SMI_STS: PM1 APM
ME: MBP cleared
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
Change-Id: Icab4c8c8e00eea67bed5e8154d91a1eb48a492d1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62633
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4375
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are specific programming requirements for the usb3 ports
on all LynxPoint chipsets when transitioning to D0 or D3.
LynxPoint-LP has additional workaround steps needed involving
resetting the disconnected ports when transitioning to D0.
The workarounds are implemented in ACPI code so the controller
can transition properly into D3 at runtime.
Change-Id: I3b428562f48c9cb250b97779a3b2753ed4f81509
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62632
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4374
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This reverts commit ff81f50f0e4c068b64c4a5c7f5244196ecd24965.
Deferring this step until the finalize stage will allow us
to defer waiting for the MBP clear indicator and speeding
up the boot.
Change-Id: Ib8edffd06689e72875830cd68b5aedb7ac3b0559
Reviewed-on: https://gerrit.chromium.org/gerrit/62631
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The intel_ddi.c change I thought should be in but I don't see it. It just adds two functions back
that we need.
There are two new files for slippy annotated with comments about how it needs to evolve.
That said, this code has been tested on 3 different panels. Both dev and non-dev usages work.
physbase initialization to static value removed.
Moved spin calls to intel_dp_*
Change-Id: I0480af45c21c7dedcaff7e8be729f0eb554ec78a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61136
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4370
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Peppy SPD table has 4GB configurations followed by 2GB configurations.
Current implementation does remapping to point 2GB configuration to the
same SPD index as the 4GB. This is different than Falco, which simply
duplicates the SPD data for all configurations. To simplify probing in
mosys, copy the Falco implementation of duplicating SPD data.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idb185a437f3cf4f40d2dae1ae59c30235df8f489
Reviewed-on: https://gerrit.chromium.org/gerrit/61847
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Jay Kim <yongjaek@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4369
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
When using RW firmware path the proper recovery reason can
be retrieved from the shared data region. This will result
in the actual reason being logged instead of the default
"recovery button pressed" reason.
1) build and boot on falco
2) crossystem recovery_request=193
3) reboot into recovery mode, check reason with <TAB>
4) reboot back into chromeos
5) check event log entry for previous recovery mode:
25 | 2013-07-15 10:34:23 | Chrome OS Recovery Mode | Test from User Mode
Change-Id: I6f9dfed501f06881e9cf4392724ad28b97521305
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61906
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4368
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The EC temperature sensors were renumbered and now PECI
is at index 0.
1) boot on falco
2) check /sys/class/thermal/thermal_zone0/temp
3) check 'temps' on ec console
Change-Id: Idde1457c42c80850b5b8ac22781060ed9b224d13
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61896
Reviewed-on: http://review.coreboot.org/4367
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This may need further tuning but will start at 1.0%.
boot on falco and check /sys/firmware/log
localhost ~ # grep RTD2132 /sys/firmware/log
RTD2132: Enable 1.0% Spread Spectrum
I2C: 01:35 (Realtek RTD2132 LVDS Bridge)
Change-Id: I96e1c14dbc6a7bfaf1c8deb1806c48bf2fd3e32a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61895
Reviewed-on: http://review.coreboot.org/4366
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This driver allows the mainboard to enable spread spectrum
clocking at 0.5%, 1.0%, and 1.5% with devicetree settings.
Change-Id: I59c61e67aa8e951fd9904ad951deb6d0ba29669e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61894
Reviewed-on: http://review.coreboot.org/4365
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This is needed for SMBUS drivers to write to devices.
It was copied from existing intel southbridge driver.
Change-Id: Id0ce2393b2946a9c741413bca563a1a4dc0a4f5e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61893
Reviewed-on: http://review.coreboot.org/4364
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The drivers in the kernel expect the devices using gpios
to generate interrupts to be edge sensitive. Make it so.
Change-Id: I920ef621682d33ba081f737e97f0239f903db2f7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61678
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4361
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
SYS_TEXT_BASE is not used by any one. To prevent confusion when changing memory
layout, remove it from current configurations.
Change-Id: I15012b864bbb9c12003843b9b24ea64c91f4578b
Reviewed-on: https://gerrit.chromium.org/gerrit/61853
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4371
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Just like bluetooth and wlan it need to be enabled in EC.
Set the appropriate bit in EC if CMOS config says so.
Change-Id: Ia48ca3201f013d3b4c4153f32ff536e06b6a2f6d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4516
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The LynxPoint-LP chipset only has one EHCI controller so we should
not attempt to write into the second one that only exists on LynxPoint-H.
Change-Id: I1eae060c7f0a5873c9684e5abfeea5cb5895ab62
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4405
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Up until now, a dummy terminator was required for CBFS microcode files.
This was a coreboot only requirement in order to terminate the loop which
searches for updates.
Figure out where the microcode file ends, and exit the loop if we pass the
end of the CBFS without finding any updates.
Change-Id: Ib61247e83ae6b67b27fcd61bd40241d4cd7bd246
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4505
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Calculating the CRC of a SPD may be useful by itself, so split that
part of the code in a separate function.
Change-Id: I6c20d3db380551865126fd890e89de6b06359207
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4537
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Most of the code needed for this is already in the tree with X201
patch series but code didn't know where to send the next screen
notification and so was disabled. Define right video device.
Tested by: Sam Noble
Change-Id: I4ff0d220afdca342617ce43c6e5d0164ad8eba27
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4494
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
x_resolution, y_resolution and bytes_per_line were not inited. Without them
coreboot sweared that screen is 1108630x1142817 and payload tried to draw on
such a big screen.
Change-Id: I0d0277a20c7e1976c27af4a57651ab2be0f9c5d7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4535
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Was extensively tested on my X201.
More info on the wiki
Change-Id: I503d77749780422e446b48224ca98a1f22a2c180
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4514
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Currently H8 skips important init if unable to access CMOS config.
Change default to enable all features to have a sane system without
using CMOS config.
Change-Id: I4448ccd21beae8ad23eb22391770c6fe3b83e3b4
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4515
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
According to the commit message for the board Cougar Canyon 2 (48a749a8)
resuming from S3 is currently unsupported.
The FSP does not support S3 at this time. S3 may be added
when it is available in the FSP.
Mirror that in the configuration by not selecting the Kconfig option
`HAVE_ACPI_RESUME`.
Change-Id: I894f103ffa7d8db6342f99fff0867b02bc750752
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4519
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
AT controller needs an ACPI node, otherwise FreeBSD doesn't detect keyboard
and mouse. Currently each SuperIO adds its own description. This one should
be used in the future instead.
Change-Id: Iaad5ed3846c6d9f467a02a286a1e6f60a3607af5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4518
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Microcode update file contains patches for various processor
revisions, it is not an error to have those.
Change-Id: Ifbca26276b66f17092afe249a2cfc229713a9fec
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4520
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
CPU_MICROCODE_IN_CBFS was designed to mean that loading microcode updates
from a CBFS file is supported, however, the name implies that microcode is
present in CBFS. This has recently caused confusion both with contributions
from Google, as well as SAGE. Rename this option to
SUPPORT_CPU_UCODE_IN_CBFS in order to make it clearer that what is meant is
"hey, the code we have for this CPU supports loading microcode updates from
CBFS", and prevent further confusion.
Change-Id: I394555f690b5ab4cac6fbd3ddbcb740ab1138339
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4482
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SystemAgent contains a mini-hd audio controller at PCI 0:3.0
which uses the same verb table init sequence as the southbridge.
In order to avoid two copies of the verb table loading code I
separated out the HDA verb table functions into a file that can
be re-used and then added a minihd driver to the haswell northbridge.
The minihd verb table is the same across devices so it can live
within the minihd driver rather than needing to be specified in
each separate mainboard.
I also fixed up the driver for lynxpoint HDA by following the
reference code.
Without HDMI cable plugged in driver does not find any codec,
and it does not seem to re-probe when HDMI is connected. We may
be missing kernel patches for this.
hda-intel 0000:00:03.0: no codecs found!
With a basic kernel patch to add 0x0a0c device ID to HDA driver
and with HDMI cable connected it is much happier:
snd_hda_intel 0000:00:03.0: irq 60 for MSI/MSI-X
input: HDA Intel MID HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input9
snd_hda_intel 0000:00:1b.0: irq 61 for MSI/MSI-X
input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
Change-Id: Ifa587984be4fc2801704a0368b9cdf8379c2450e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4318
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The drivers are designed to work with an edge triggered interrupt.
Change-Id: I35a121ecfb6409bb9049f4d1e034185bb3bb7557
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61664
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4360
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The 5250 DRAM code is *really* chatty. That's not a great
idea in time critical code, and DRAM init is generally
very sensitive about such things.
Finally, for those things that are errors, print them
at an error level, not a debug level.
Change-Id: Ifa86b019dfd5f8ae6c8a1da2a35b5d0808dc3623
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60100
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4359
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When the board is in S3 and S5 the WLAN_DISABLE_L signal
can leak power into the WLAN power well since the GPIO
controlling WLAN_DISABLE_L is in the suspend well. Therefore,
drive WLAN_DISABLE_L low to avoid the power leak.
Change-Id: I1a0df80dd47fdbd535aca7a9d49253794c480606
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61421
Reviewed-on: http://review.coreboot.org/4358
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The name "LPDDR3PHY_CTRL_PHY_RESET_OFF" is not appropriate because the real
phy-reset is a low-active pin, so "off(0)" will trigger "start to reset".
To prevent confusion, we should rename the constants to "RESET_ENABLE" and
"RESET_DISABLE".
Change-Id: Iccba5ef3a2e992f877dea90741f0308c161758c9
Reviewed-on: https://gerrit.chromium.org/gerrit/61081
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4357
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are needed to enable workarounds/features on specific
CPU types and stepping. The older northbridge function and
defines from sandybridge/ivybridge are removed.
Change-Id: I80370f53590a5caa914ec8cf0095c3177a8b5c89
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61333
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4355
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To configure source clocks on Exynos 5420 for MMC drivers.
Some registers are different from the 5250. FSYS now has two parts
and MMC uses FSYS2. The MMC block uses MPLL as the clock source.
The "high-speed" MMC interface runs as 52MHz, so divider is set
accordingly.
Also, the MMC driver has changed from MSHCI (Mobile Storage Host Controller
Interface) to DWMCI (DesignWare MMC Controller Interface).
Change-Id: I9ba9cf43e2f2dcd9da747888c0c7676bd545177b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60858
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4354
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Make use of google_chromeec_get_board_version to determine board
version, and apply proper RAM_ID table to load correct SPD.
Change-Id: I6a2d54759cf2ce98bf53df0db396c6e09368c714
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61192
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: http://review.coreboot.org/4353
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Update peppy's verb tables for the Realtek ALC283 Audio Codec.
ALC283 Configuration:
Digital Mic - NID 12h: Disabled
Speakers - NID 14h: Enabled
Mono out - NID 17h: Disabled
Mic 1 - NID 18h: Disabled
Mic 2 - NID 19h: Headphone Jack
Line1 - NID 1Ah: Internal Mic
Line2 - NID 1Bh: Disabled
PCBEEP - NID 1Dh: Enabled
SPDIF - NID 1Eh: Disabled
HP-OUT - NID 21h: Headphone Jack
Mic 1 doesn't seem to really be available, but the documentation
refers to NID 18h as MIC1, so it's being disabled as it's not
being used. The onboard microphone has been moved to line 1.
I had my peppy modified to attach the mic to line1 and mic1 now
works with this patch. Mic2 looks harder to rework, so I think
that will have to wait for the DVT boards.
Change-Id: I7d6ce6b428806b6aed1d36e7e25302fa5ae14b21
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58880
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4352
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We will soon need to call google_chromeec_get_board_version to determine
correct DDR SPD. We must do so before DDR is initialized, so allow this
function to be called from romstage.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I882d84e38d11bf66067193a6f408f941f2cf8a81
Reviewed-on: https://gerrit.chromium.org/gerrit/61191
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
USB2 Port A set to 6.4" and Back Panel
USB2 Port B set to 5.2" and Back Panel
USB2 Port C set to 12.3" and Internal
Other devices all set to Internal.
build and boot on falco and check settings.
Based on the config settings all ports end up with
tuning param 1 == 5 and param 2 == 2
U2ECR[0] = 0x00059501
U2ECR[1] = 0x00059501
U2ECR[2] = 0x00059501
U2ECR[3] = 0x00059501
U2ECR[4] = 0x00059501
U2ECR[5] = 0x00059501
U2ECR[6] = 0x00059501
U2ECR[7] = 0x00059e01
Change-Id: I6b9e6df2679036a501355e6b389a486a6f178f99
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61297
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4350
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Systems are hanging in dev_configure() without a log to
indicate which device is being processed. Add some logging
points to save the device path before talking to the device
so we can narrow in on which device is the problem.
Change-Id: I3751c19a1ea68cdccbc33e4f6b2eeddd1bd9f2e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61296
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4349
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This CPU does not support Configurable TDP and so far does
not need to use Controllable TDP.
Change-Id: I15599cd4e6890dd5c9d9f99bc4e95307a8dcc827
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60657
Reviewed-on: http://review.coreboot.org/4347
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The OP assigned by dcache_clean_by_mva must be handled in dcache_op_mva.
Change-Id: Ia7631a08be6afacb13dfff406ac4db20efc98926
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61076
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4343
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The is_resume comment is wrong for this board. It only applies
to the older 5250 cpu. In fact, the is_resume parameter
is not needed for ddr init and will likely be removed soon.
Change-Id: I4e3c92fcaaa75d3c9223d90acccf053f61406307
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60103
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4342
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some new fields were added to the edid data structure, and the edid code was
changed to put estimated values into those fields which were ultimately passed
into depthcharge or other payloads. On snow we do things different and just
declare an edid structure statically which didn't have those members. The rows
and columns of the graphics console were 0, and that confused the framebuffer
driver and made it loop forever.
Change-Id: I6ca3bd948482b347a6a981e83b82b10dca995e5e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61057
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Update RAM_ID table.
- Add DEVSLP0 signal to NGFF SATA port.
Note: After this change, old Micron 2GB boards will no longer boot.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id68a1d6ace2702cca9c37305726cd55a0bde5005
Reviewed-on: https://gerrit.chromium.org/gerrit/60167
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
Reviewed-on: http://review.coreboot.org/4340
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
No ROMCC involved, no need to include .c files in romstage.c.
Change-Id: I8a2aaf84276f2931d0a0557ba29e359fa06e2fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4501
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
walkcbfs() is used only with ROMCC. Besides finding stages during the
bootblock, it's also used when applying microcode updates during the
bootblock phase. The function used to return only a pointer to the data of
the CBFS file, while making the header completely inaccessible. Since the
header contains the length of the CBFS file, the caller did not have a way
to know how long the data was. Then, other conventions had to be used to
determine the EOF, which might present problems if the user replaces the
CBFS file. This is not an issue when jumping to a stage (romstage), but can
present problems when accessing a microcode file which has not been
NULL-terminated.
Refactor walkcbfs_asm to return a pointer to the CBFS file header rather
than the data. Rename walkcbfs() to walkcbfs_head(), and reimplement a new
walkcbfs() based on walkcbfs_head(). Thus current usage of walkcbfs()
remains unaffected.
The code has been verified to run successfully under qemu.
Subsequent patches will change usage of walkcbfs() to walkcbfs_head where
knowing the length of the data is needed.
Change-Id: I21cbf19e130e1480e2749754e5d5130d36036f8e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Instead of having global variables put them on the stack.
Change-Id: I462e3b245612ff2dfb077da1cbcc5ac88f8b8e48
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4288
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It was suggested to eliminate the lock for sprintf. One way to do it is
to make the fake tx_byte into a closure. This patch allows it.
It's a bit tricky since we need to preserve compatibility with romcc.
Change-Id: I877ef0cef54dcbb0589fe858c485f76f3dd27ece
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4287
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Newer mainboards that use haswell -- and, presumably, chipsets to come -- need
some support functions. Add them in the drivers/intel/gma directory.
Currently, this is one file: intel_ddi.c, but more may come.
Compilation of this file is controlled by INTEL_DDI, defined
in the Kconfig as default n and used in the Makefile.inc
Change-Id: I501ee291c0d4589925ed3e478f67106337fcad31
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60612
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4337
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add ACPI Methods to enable and disable power limiting with PL1.
This can be used in ACPI Thermal Zone or in EC ACPI _QXX events.
This commit adds new unused methods and is fully tested with the
subsequent commit that makes use of these methods.
Change-Id: I9d8d23bfe9cf7c756ff8ab0412e5a010826b12db
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60546
Reviewed-on: http://review.coreboot.org/4334
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
Reviewed-on: http://review.coreboot.org/4333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Limit power to 12W at 73C and remove limit at 68C.
To have the CPU consume maximum power it is necessary to stress
both the CPU and the GPU. Bastion (chrome.supergiantgames.com)
and/or webglsamples.googlecode.com can be useful for this.
Testing this properly requires a script to report the running
average power readings. The watch_power.sh script is attached
to this issue in the partner tracker.
1) Run watch_power.sh continuously:
localhost ~ # watch -n 0 bash -e /tmp/watch_power.sh
2) Start Bastion (or other stress apps). The power draw should
be close to 15W if under enough load.
3) Watch until temperature climbs above 73C and is caught by
the thermal zone 10 second poll, this can be sped up by blocking
or removing the fan.
4) The ACPI thermal zone states should change to reflect that
active[2] is now enabled and power consumption should drop to 12W.
5) Stop the stress apps and wait until the CPU cools off again,
enable the fan again if it was removed.
6) The ACPI thermal zone state should switch back to active[3].
Change-Id: Ie6714a8543d4f06edf8513086fc9c968273bdb23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60545
Reviewed-on: http://review.coreboot.org/4335
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4332
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The original intention was to only run UPDATE_FIT when a microcode file was
included in CBFS. This happens when either CPU_MICROCODE_CBFS_GENERATE or
CPU_MICROCODE_CBFS_EXTERNAL is selected, however, the makefile checked that
CPU_MICROCODE_IN_CBFS was selected instead. The end result was that on
hasswell, the UPDATE-FIT step was always run, even when no microcode was
included, generating a build error.
Instead, introduce a new variable which tells if a microcode update is
added in CBFS during the build.
Change-Id: I28638912ed6f77761ef8a584f7636dc907b7a9b7
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4480
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
No need to show the choice of USB port or controller in case of older
hardware where location for usbdebug was hardwired.
Change-Id: Ia186bf2c6ed60be2834cf6fd0a1965c8bf81ed4d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4290
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use a file in CBFS for keyboard layout and ethernet MAC instead
of scanning FMAP.
Change-Id: I7658c7c4e389deb20d7d8f57cce8b568efdc575d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4307
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The Intel GMA driver is in, this CL splices in the Makefile bits.
Change-Id: Icf42a537575b8cc90a679ec1fc15b09294630611
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60346
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4331
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
These functions are not all used yet, but do compile and are partially used
in the FUI testing.
They were extracted from the 3.4 kernel using coccinnelle filters. The .c files
are only compiled in if CONFIG_INTEL_DP is set.
Change-Id: Id95622a75aa02b496c9ea4717cb143394a8332e3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60245
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Removed two unnecessary register sets, and did the power well a bit
more correctly. Also, added a register definition include file so we can
used constants instead of magic numbers.
We also set registers to common initialized values that are
needed for FUI, VBIOS, and kernel. This set of registers
appears to be an absolute bare minimum. Since we're hoping to use
FUI for all chipsets from this one forward, we unconditionally do the
setting here.
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Change-Id: Ife3f661ba010214d92b646b336f2b06645119f17
Reviewed-on: https://gerrit.chromium.org/gerrit/59988
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The new edid functions support converting the edid to an lb_framebuffer.
Use them. Also, since panels seem to set bits per color instead of bits
per pixel, just force the right value in the edid struct.
Add helpful comment because people don't always believe we need to set
the pallette.
While we're at it, fix a problem that caused it to not compile.
Change-Id: I645edc4e442d9b96303d9e17f175458dc7ef28b6
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4327
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- updates from 1.6.0 ref code
- remove the step comments as they are no longer even close
- add constants for LPT revisions
build and boot on Falco
Check that RCBA+2300[1] is set:
> mmio_read32 0xfed1e300
0x00000002
Change-Id: I8b3c5fda3f3170455699a7834239cb991603e7a8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59821
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4326
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There's a need to determine if a specific gpio pin is
is set up to be a native function or not. Implement this.
Change-Id: I91d57a549e0f4fddc0b1849e5f74320fc839642c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59589
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4324
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The BIOS spec for LynxPoint calls out additional
programming steps for the PCIe Root Ports. Implement those
steps from the BIOS spec. These steps are completed before
deeper PCIe probing. The "late" programming was removed as
that was applicable to Cougar/Panther point where this
code was originally copied, though there was some overlap.
Change-Id: I64f25e4451e035d98ca6b66b0335bd280b70b074
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59558
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4323
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
PCIe Root Ports should be disabled based on pin ownership
and the strapping configuration. Implement this logic
for LynxPoint. The chip_ops->enable_dev() path is no
longer used. Instead the PCIe driver handles the enabling
and disabling of devices. This allows for having an empty
or incomplete device tree since those "allocated" devices
do not travel through the chip_ops->enable_dev() path.
The coalescing was tested to be working properly, however
not all configurations were tested.
Change-Id: I1e8bfe5e447b72ff8a4b04b650982d8c1ae0823c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59424
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4322
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Don't force dev mode. Allow users to enter / exit dev mode as normal.
Change-Id: I168eb04a8ac102a8c4a1ca8936f78f62b001e0eb
Reviewed-on: https://gerrit.chromium.org/gerrit/59492
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: http://review.coreboot.org/4321
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On some systems there may be 2GB SKU that is the same as the
4GB SKU but just one channel of memory. In that case we need
to ensure that both copies of the same SPD source end up
populated by ensuring that repeated entries are included by
using $+ instead of $^.
Alternatively we could do the check inside romstage, but it
is already set to behave this way if the SPD gets populated
correctly.
I changed spd_index to 3 in falco romstage to force it to
pretend it was a 2GB config of the same memory, then booted
to ensure it was indeed limited to 2GB.
memcfg channel[0] config (00780008):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 2048 MB width x16 single rank, selected
DIMMB 0 MB width x16 single rank
memcfg channel[1] config (00600000):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 0 MB width x8 single rank, selected
DIMMB 0 MB width x8 single rank
Change-Id: Ibfe5051ccda2fe69e8caff3f3c264116e3411c65
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59483
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
Reviewed-on: http://review.coreboot.org/4319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Propagated from
http://review.coreboot.org/3347http://review.coreboot.org/3374
The cause of this issue is:
USB devices use bit 11(0x0b) of GP0_STS represents S3 wake up event,
but this bit is not clear after wake up. So OS thinks there is a
wake up signal and wake up immediately.
Both amd/olivehill and asrock/imb-a180 have been validated.
Change-Id: I7c26cb07bcd2e62bb792809b67314e5155c6adf6
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4261
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The AML code of PTS and WAK for southbridge are in
UINT8 AlibSsdtKB[], Proc/GNB/Modules/GnbInitKB/AlibSsdtKB.h.
It was integrated into SSDT even it was called by nobody.
The source ASL was provided by AGESA for reference, but it
has been scrubbed when it was ported to Coreboot.
Without the calls, Olive Hill can not wake up if it boots Windows.
Both amd/olivehill and asrock/imb-a180 have been validated.
Change-Id: Ia7bba29904dbd6f33fdb08bf88bb499005ef561b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4260
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The bug is hard to find. We were adding the feature of fan control. We
met some strange things which could not be explained. Like, sometimes
adding printk let the error disappear. Then we traced the code by hardware
debug tool (HDT). It turned out the data in stack was overwritten.
The values of AccessWidthxx are
{ AccessWidth8 = 1,
AccessWidth16,
AccessWidth32,}
For the case of AccessWidth8, we only need to access the index/data
once. But ReadECmsg and WriteECmsg did the loop twice, 1 more time
than they are supposed to do. The data in stack next to "Value" would
be overwritten.
For all the cases, the code should be
OpFlag = OpFlag & 0x7f;
switch (OpFlag) {
case 1: /* AccessWidth8 */
OpFlag = 0;break;
case 2: /* AccessWidth16 */
OpFlag = 1;break;
case 3: /* AccessWidth32 */
OpFlag = 3;break;
case 4: /* AccessWidth64 */
OpFlag = 7;break;
default:
error;
}
Actually, the caller only takes AccessWidth8 as the parameter. We can ignore other
cases for now.
That is an AGESA bug. AMD's AGESA team own this code. They have given the
response that they are going to update this in next release. I presume let them
decide the proper way to fix that. Before that, I change the code as little
as possible to make it run without crash.
Change-Id: I566f74c242ce93f4569eedf69ca07d2fb7fb368d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4297
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Commit * bdafcfa Add the Intel FSP 206ax CPU core support
Introduced this option. This option was meant to have a board generate
a CBFS file containing microcode. However, microcode generation used to be
enabled by default when CPU_MICROCODE_IN_CBFS was selected.
The introduction of BOARD_MICROCODE_CBFS_GENERATE killed that automatic
default, which is not what we want. This option is misguided in the sense
that it tends to introduce a non-default which had been intentionally a
default. We now have to select two Kconfig options in order to generate
microcode in CBFS, meaning one option is redundant.
Change-Id: I3034833df1a9afa7d6d9d537484cb4ac89d30183
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4478
Tested-by: build bot (Jenkins)
mainboard_smi_gpi has recently been updated to take a u32 argument from a
u16, but the patch introducing the fsp_bd82x6x support has been verified
on a master before this change, thus resulting in a 'cast from incompatible
type' error. Update the pointer to the correct size argument.
Change-Id: I9d62ee43f7c8ed774898f54d29a87cf463b76e91
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4479
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Cougar Canyon 2 is a Ivybridge/PantherPoint reference board.
This implementation uses the Intel FSP (Vist the Intel FSP
website for details on FSP architecture and support).
The FSP does not support s3 at this time. S3 may be added
when it is available in the FSP. All other features and IO
ports are functional. Booted on Ubuntu 12.04 and 13.04,
Fedora 18 with SeaBIOS payload. Memtest86, FWTS, and
other tests pass.
Board support page will be updated on acceptance.
Change-Id: I26c0b82d7ac295498376ad4c3517a9d6660d1c01
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4018
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the FSP northbridge and southbridge includes.
Change-Id: I5c7f395dc033caa8d0bf0313382769595d77f2a5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4019
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for the bd82x6x using the Intel FSP.
The FSP is different enough to warrant its own source files
for now. The mrc/system agent chromebook solution does much more
southbridge initialization and configuration than the FSP version.
It may be combined in the future.
Change-Id: Ie493945f3d321d854728d231979a0c172d2b36de
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for 206ax using the Intel FSP.
The FSP is different enough to warrant its own source files
for now. It has different CAR code, micorcode, and FSP inclusion.
It may be possible to combine this code with the mrc based
solution used by the chromebooks in the future.
Change-Id: I5105631af34e9c3a804ace908c4205f073abb9b4
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4016
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add support for Sandybridge and Ivybridge using the Intel FSP.
The FSP is different enough to warrant its own source files.
This source handle the majority of FSP interaction.
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4015
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's done in bootblock_simple.c just after returning from
the mainboard specific bootblock function.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I96cab5e406132a9f7dc30d48ff99f524773a1a14
Reviewed-on: https://gerrit.chromium.org/gerrit/58473
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4257
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Ibexpeak shares few files with bd82x6x. In order for it to work correctly
their config structures from chip.h must match, so include bd82x6x/chip.h
in ibexpeak/chip.h
Change-Id: Ib56b311b8af04f4e4803d1834724680f604901cd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4277
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This was used by Ron 13ys ago and was never used again
ever since.
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
LynxPoint-LP has a lot of GPEs and the "default" set has been
moved to register 4 starting at bit offset 96. This means
that PME_B0 bit in GPE0_EN/GPE0_STS is now bit 109 in LPT-LP
but still bit 13 in LPT-H.
suspend on falco and wake from usb
4 | 2013-06-19 10:49:17 | ACPI Enter | S3
5 | 2013-06-19 10:49:22 | ACPI Wake | S3
6 | 2013-06-19 10:49:22 | Wake Source | Internal PME | 0
Change-Id: I443cd4d17796888debed70c0bda27ae09accd09b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4253
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
In order to make the proper decision on loading the
option rom or not the recovery mode setting needs to be
known. Normally this is detected by asking the EC,
but if recovery is requested with crossystem then the EC
does not know about it. Instead we need to check the
output flags from VbInit().
Change-Id: I09358e6fd979b4af6b37a13115ac34db3d98b09d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57474
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4223
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Since we are using VBNV to determine if developer mode is
active we do not need the messy OPROM hook magic any longer.
Change-Id: I1b9effef3ef2aa84e916060d8e61ee42515a2b7c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57473
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4222
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The OIPG package needs to have >1 member to make the chromeos_acpi
kernel driver do the right automagic sysfs topology creation.
Additionally an "unimplemented" GPIO should be reported as 0xFF
because 0 is a valid GPIO number.
verify crossystem on slippy
$ sudo crossystem | grep -e recoverysw_cur -e wpsw_cur
recoverysw_cur = (error)
wpsw_cur = 1
Change-Id: I06dff09152bde30a3ffe58b1defe9d299155472c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57471
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4221
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This config option was not enabled which was preventing
the user from enabling developer mode from recovery mode.
With this enabled we can disable the "dev mode by default"
behavior and let people enable it by entering recovery mode.
This will make the firmware behave like a typical chromeos
device.
Peppy is left in "default dev mode" until after bringup.
1) boot slippy in normal mode by default
2) enter recovery mode with servo button
3) Ctrl+D on USB keyboard to enter developer mode
4) boot slippy in developer mode
Change-Id: I414c0d10dd0489e3c89798f75a2872a43297c8d8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57350
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4220
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Those building Chromebook firmware from coreboot git might be more
interested in building without ChromeOS extras.
Change-Id: I2f176d059fd45bf4eb02cc0f3f1dcc353095d0ce
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3977
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Instead of depending on exact mobo configure general characteristic whether
dock is configured in romstage or ramstage.
X60 and T60 have superio in dock so it needs to be inited to get serial, so
it should be inited in romstage.
On X201 there is nothing useful that early in boot but it's needed to init more
to get dock working, in particular EC init needs to be done first.
Change-Id: If5072e3dec883a94cd2d5643a92f7f6c3c9feee9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4294
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead define brightness up/down function and gfx device and use
preprocessor magic to glue it together.
Change-Id: I03074ae07b33c1546d229efc3e80606ddbee6300
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4282
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Do not directly check the return value of get_option, but instead compare
the returned value against a CB_CMOS_ error code, or against CB_SUCCESS.
Change-Id: I2fa7761d13ebb5e9b4606076991a43f18ae370ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4266
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Add a new USB location field
- Add a new "ddr_refresh_2x" field, enabled on Falco only
- Fix copy+paste bug in baskingridge
Checked that tREFI is halved during memory setup in the memory
training log:
tREFImin = 6240 << DEFAULT
C(0).tREFI = 0xc30 << MODIFIED (=3120)
C(0).tREFI = 0xc30 << MODIFIED (=3120)
Also ensure that the SD card is detected properly again.
Change-Id: Ie3a82c08df06ada9af56282b5255caefa56487f2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57349
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4219
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Compiler may do loads of optimisations around stack switch and so it's allowed
to break stack switch as it sees fit. Do it in assembly instead.
Not tested.
Change-Id: I277a62a9052e8fe9b04e7c65d149e087282ac2a2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4286
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The function reads the Build ID and the supported function specification
version from the running EC firmware, and stores a text representation
in the provided output buffer.
Change-Id: I3b647d7f315c9b4922fa9a9c5167a80f6d82e753
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3617
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These are based on the datasheet and I included the timing
values I used from the docs.
Change-Id: Ib75b2c5e50ac09d1e4cf9dd22229bb0f0a8965a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4234
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In order to make the proper decision on loading the
option rom or not the developer mode setting needs to be
known. Under early firmware selection it is possible to know
the state of developer mode by a flag in out flags. Use this
flag when early firmware selection is being employed to determine
if developer mode is enabled or not.
Change-Id: I9c226d368e92ddf8f14ce4dcde00da144de2a5f3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57380
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4218
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The Linux thinkpad_acpi.c driver looks for this string while
reading information about the system it is running on.
This commit does not make the module load but it is one of
several things that the module looks for on a ThinkPad.
Change-Id: Ia48bbd85ba4d528063695345b0f968d264573341
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3779
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently, all Peppy boards w/ '000' SPD GPIOs have 2GB DRAM. Disable
the second DRAM channel based upon the GPIOs.
Need to change / confirm this for upcoming builds.
Change-Id: I7085ddecb80626cc0bed99ba7b174c6b80350696
Reviewed-on: https://gerrit.chromium.org/gerrit/58620
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4238
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
(Taken from I63ca00d6c94854f2b395eb736ce20792da5f8de2).
Change-Id: I9c7d1d1f1aaf7de33d0cec5f6daf648576ba8900
Reviewed-on: https://gerrit.chromium.org/gerrit/57289
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4212
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There was always exactly one elog descriptor declared and initialized, but its
contents were being accessed through a pointer that was passed back and forth
between functions instead of being accessed directly. This made the code more
verbose than it needed to be and harder to follow. To address this the
descriptor type was eliminated, its contents were turned into individual
global variables, and various functions were adjusted to no longer take the
descriptor as an argument.
Similarly, the code was more verbose and complicated than it needed to be
because of several wrapper functions which wrapped a single line of code which
called an underlying function with particular arguments and were only used
once. This makes it harder to tell what the code is doing because the call to
the real function you may already be familiar with is obscured behind a
new function you've never seen before. It also adds one more text to the file
as a whole while providing at best a marginal benefit. Those functions were
removed and their callers now call their contents directly.
Built and booted on Link. Ran mosys eventlog list. Cleared the event log
and ran mosys eventlog list again. Added 2000 events and ran mosys eventlog
list. Cleared the log again and ran mosys eventlog list.
Change-Id: I4f5f6b9f4f508548077b7f5a92f4322db99e01ca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49310
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4245
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The elog driver's design was a bit more elaborate than it really needed to be
since it no longer had to keep track of multiple copies of the log in flash
and also in memory. This change streamlines it by removing unnecessary
compartmentalization of some bits of code, and some variables which tracked
the last entry added which were never used.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the event log and ran mosys eventlog list again. Cleared the log by echoing 1
into /sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
Change-Id: I7d4cdebf2f5b1f6bb1fc70e65eca18f71b124b18
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49309
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4244
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
elog_validate_and_fill was called in exactly one place, in
elog_init_descriptor. It didn't actually do what its name implied since the
data in the event log was already "filled" by elog_init_descriptor. Likewise
elog_init_descriptor was delegating an important part of its own job, scanning
through the list of events, to elog_validate_and_fill.
Since one function was basically just a displaced part of the other which
couldn't really stand on its own, this change merges them together.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events with
the SMI handler and ran mosys eventlog list again.
Change-Id: Ic899eeb18146d0f127d0dded207d37d63cbc716f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49308
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4243
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function was just a wrapper around elog_init_descriptor, and all it did
was pass the current backing store location and size back in so it would be
reused. Those values, which never change, are now set in
elog_setup_descriptors, eliminating those parameters to init and eliminating
the need for _reinit_.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again.
Change-Id: I133768aa798dfc10f32e14db95235a88666890c3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49307
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4242
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The event log driver keeps two copies of the event log in memory, one to
take the place of the historically memory mapped image of flash which is now
read and written manually, and one originally intended to be an in memory
cache of flash. Since both are now just copies in memory, there's no value in
having them both and keeping them in sync.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again. Cleared the log by echoing a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list again.
Change-Id: Ibed62a10c78884849726aa15ec795ab2914afc35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49306
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4241
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The way elog_shrink currently works is that it completely clears the data in
the flash/flash descriptor and then recreates it using the part of the log
it's going to keep as stored in the memory descriptor. That scheme depends on
there being to independent copies of the log.
This change reworks elog_shrink so that it moves the data it wants to keep
within a single descriptor and then propogates it to the other and to flash
intact. This way, when one of the descriptors goes away, all we have to do is
remove the code that would update it.
Built and booted into ChromeOS on Link. Ran mosys eventlog list. Added
2000 events to the log and ran mosys eventlog list again. Echoed a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
BRANCH=None
Change-Id: I50d77a4f00ea3c6b3e0ec8996dab1a3b31580205
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49305
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4240
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The header is at the start of the log. There's no reason to either keep a
seperate pointer to it, or to keep a copy of it in some other bit of memory.
Built and booted on Link and used 'mosys eventlog list' to list the
contents of the log. Ran
for x in $(seq 1 2000); do
cat elog.event.kernel_clean > /sys/firmware/gsmi/append_to_eventlog;
done
And ran mosys eventlog list again to verify that the log had been shrunk
correctly.
Change-Id: I2afcd52c0ce5bbb662ac56f2895cdbea28d5c2ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49304
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the pcie logic was located in pch.c as well
as pcie.c. Move all pcie logic to the same pcie.c
file. This is a straight cut-and-paste (no logic changes)
except for a rename from pch_pcie_enable() ->
pch_pcie_enable_dev().
Change-Id: I338c53039b95f255ab9ced313c51193a9d34b404
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59277
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4251
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The function to disable devices was formerly named
pch_hide_devfn(). This routine was doing more than hiding
devices. It was disabling them, i.e. turning them off.
Therefore, rename it to pch_disable_devfn(). Also, allow
external callers to this function.
Change-Id: Id5bb319d4e67892c02a39dff49e45b2811a2f016
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59276
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4250
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The iobp functions are useful to may of the southbridge
devices as certain values need to be updated to properly
initialize the devices. Therefore expose read, write, and
updated iobp functions.
Change-Id: Id7fdd8d0d9f022f92d6285ecd8f85a52024ec2bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4249
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
A quirk of the Kconfig used in coreboot is that config options
cannot be overriden by local config changes unless they have
a description string.
1) Add CONFIG_MAINBOARD_VENDOR="Custom" to local config
2) Build and flash coreboot
3) cat /sys/class/dmi/id/sys_vendor and look for "Custom"
Change-Id: I1b5f2124cd4a22c056c025143ae5bcaafa6b03f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59088
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4248
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The wake device input pins are active low and the
GPIOs need to be set as inverted when they are marked
as an input so they are not spuriously logged.
Also sync pin states from Falco initial commit.
Reference change: I15d38dcc9b2fb4b2b0eb27da358fa3c343e22323
Change-Id: I66e136d389d53a367436d816fa84dacdc8e86bad
Reviewed-on: https://gerrit.chromium.org/gerrit/58334
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/4247
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Set nid 0x12 instead of nid 0x05. The DMIC is on NIC 0x12.
Change-Id: Ifc883b65a50aeec6a6d3ad02fe8418f124e6241d
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58711
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Jay Kim <yongjaek@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
Reviewed-on: http://review.coreboot.org/4246
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
SPD GPIOs were being read prior to initialization in romstage_common. To
fix, pass the copy_spd function to romstage_common, to be called at the
appropriate time (after PCH init, before DRAM init).
Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58608
Reviewed-on: http://review.coreboot.org/4237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are useful values in NVS that are set at boot
and runtime and they should not be cleared on resume.
suspend/resume twice on slippy and ensure
that the USB ports are still powered on the second suspend.
Change-Id: I4bce60b02b6637f6683120ae9c4a5c64563aacf7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56941
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4210
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Make temporary buffer allocation equal with the allocation in CBMEM and
let copy_console_buffer() handle possible truncation.
When not using dynamic CBMEM the CBMEM area is initialized late in the
ramstage and should be able to hold almost as many characters as the
CBMEM can hold. We have seen 40000 was not always enough with logging
level set to spew, new default size is 0x10000.
Change-Id: If4b143fdf807e28b6766b8b99db5216b767948d5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4295
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
When using dynamic CBMEM the CBMEM area is initialized before
entering ram stage, and so we need a way smaller temporary buffer
for the CBMEM console during early bits of ram stage. In practice
around 256 bytes are needed, but keep the buffer at 1k so we make
sure we don't run out.
TEST=Boot tested on pit
BRANCH=none
BUG=none
Change-Id: I462810b7bafbcc57f8e5f9b1d1f38cfdf85fa630
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
[km: cherry-pick 7fd1bbc0 from chromium git]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4293
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Make sure memcpy target and a possible message telling log was truncated
stay within the allocated region for CBMEM console.
This fixes observed CBMEM corruption on platforms that do not use CBMEM
console during romstage. Those platforms will need an additional fix to
reset cursor position to zero on s3 resume.
Change-Id: I76501ca3afc716545ca76ebca1119995126a43f8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4292
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
If Vortex86EX PS/2 keyboard controller system flag bit times out,
reload controller firmware code and try again.
Abort and die after 11 tries as this means the CPU is defect. Also
inform the user by printing a message.
Change-Id: I24aec4b20d85c721c01e72686f3eb1259f9334b8
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3988
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Previously, I've set this config in mobo config, yet according to
Kyösti Mälkki this parameter is southbridge-specific and not
mobo-specific.
Change-Id: I92428aed5a69d88a371f5d7267bc54ba7530766c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4276
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The wake device input pins are active low and the
GPIOs need to be set as inverted when they are marked
as an input so they are not spuriously logged.
suspend/resume on slippy with trackpad wake:
8 | 2013-05-29 07:43:14 | ACPI Enter | S3
9 | 2013-05-29 07:43:18 | ACPI Wake | S3
10 | 2013-05-29 07:43:18 | Wake Source | GPIO | 12
and with power button wake:
11 | 2013-05-29 07:43:35 | ACPI Enter | S3
12 | 2013-05-29 07:43:40 | EC Event | Power Button
13 | 2013-05-29 07:43:40 | ACPI Wake | S3
14 | 2013-05-29 07:43:40 | Wake Source | Power Button | 0
Change-Id: I15d38dcc9b2fb4b2b0eb27da358fa3c343e22323
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56940
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4209
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Make the declaration and use of it conditional on the ELOG_GSMI Kconfig variable.
Change-Id: I2ef291d2f3e7d35545014e03ba8e0045da6050e5
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3987
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
Google Chrome EC MKBP driver ready, id 'slippy_no_version'
Clearing the recovery request.
EC hash:7fea29992ef72e3e64d8ffe522aa1dfa68dcb44a2da96a4c19530ea1a0bd22c4
EC-RW hash address, size are 0xffa1cfe8, 32.
Hash = 727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
Expected hash:727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
EC-RW firmware address, size are 0xffad000c, 57180.
VbEcSoftwareSync() - expected len = 57180
Computed hash of expected image:727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
VbEcSoftwareSync() updating EC-RW...
VbEcSoftwareSync() jumping to EC-RW
VbEcSoftwareSync() in RW; done
Change-Id: I63ca00d6c94854f2b395eb736ce20792da5f8de2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56821
Reviewed-on: http://review.coreboot.org/4208
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Now that there is a clearly defined boot state machine
we can add some useful post codes to indicate the current
point in the state machine by having it log a post code
before the execution of each state.
This removes the currently defined POST codes that were
used by hardwaremain in favor of a new contiguous range
that are defined for each boot state.
The reason for this is that the existing codes are mostly
used to indicate when something is done, which is confusing
for actual debug because POST code debugging relies on knowing
what is about to happen (to know what may be at fault) rather
than what has just finished.
One additonal change is added during device init step as this
step often does the bulk of the work, and frequently logs POST
codes itself. Therefore in order to keep better track of what
device is being initialized POST_BS_DEV_INIT is logged before
each device is initialized.
interrupted boot with reset button and
gathered the eventlog. Mosys has been extended to
decode the well-known POST codes:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58106
Reviewed-on: http://review.coreboot.org/4231
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
Reviewed-on: http://review.coreboot.org/4230
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
Reviewed-on: http://review.coreboot.org/4229
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The CMOS post code storage mechanism does back-to-back
CMOS reads and writes that may be interleaved during
CPU bringup, leading to corruption of the log or of other
parts of CMOS.
Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4227
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ida98f81b1ac1f6b3ba16c0b98e5c64756606fd58
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48318
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4126
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Add a comment, tweak spacing a bit, addr variable
doesn't need to be global any more.
Change-Id: Id8d8a7babce671243351074f7ac52a5c8c264de5
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4274
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Get rid of not needed dependency to gliu0table. This change is
needed to move get_top_of_ram() to raminit.c - as needed for
EARLY_CBMEM_INIT.
Boot tested on a Bachmann OT200.
Change-Id: I0bfe40c366a3537775d5c1ff8e0b1f5ac94320b7
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3380
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This function will encode the device path into 3
bytes of a dword which can be saved for debug.
It will be used by subsequent commit to store the
current device into CMOS for debugging BIOS hangs.
Change-Id: I3a5155ea53c8d280806e610a0f8998dbabe15f3c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58103
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4228
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Set verbs to reflect the layout used for ALC283 in Falco,
which ends up being the same as Slippy.
Change-Id: I3dce4effefaa91ee5bdcbe2a8a3750ebc41376ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58196
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4232
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Do not return hardcoded numerical values to communicate succes/failure, but
instead use an enumeration.
Change-Id: I742b08796adf136dce5984b702533f91640846dd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The idea is that instead of:
if (do_something()) do_something_else();
It is more readable to write:
if (do_something() != CB_SUCCESS) handle_error();
Change-Id: I4fa5a6f2d2960cd747fda6602bdfff6aef08f8e2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4264
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Set verbs to reflect the layout used for the ALC283 in slippy.
install on slippy and check that headphone switch works
as does external mic.
Change-Id: I2d6bcda9cf8bbf49cbb6d2dbbe7f1a5adf315d8a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4224
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Both EHCI and XHCI controllers have additional setup steps
that are not part of the PEI reference code so they need to
be done later.
Both controllers also have specific clock gating setup
requirements that are now implemented.
Additionally they both have specific requirements when entering
sleep states. XHCI needs something in S3/S4/S5 and EHCI only
has steps for S4/S5 entry.
Change-Id: Ic62cbc8b6255455e56b72dd5d52e27a311999330
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4217
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When an INIT# is delivered to the CPU the CPU starts
executing from the reset vector. However, the internal state
is maintained. Therefore, check for such a condition and
reset the system.
Issues 'apreset warm' on the EC console. INIT# is sent and
CPU notices it's not a clean reset and forces one. No hangs.
Change-Id: I71229e0e5015ba8c60f5989c533268604ecc1ecc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57111
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Peppy RAM ID table is as follows:
000 41K256M16HA
001 H5TC4G63AFR
010 EDJ4216EFBG
Elpida SPD taken from Ib1e430cd390b4dbc013fc0802f1a59c1a0412577 by
dlaurie.
Change-Id: Iac156a2d25435514f28e2e73bef617d0fe2d90a1
Reviewed-on: https://gerrit.chromium.org/gerrit/56687
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Taken directly from slippy with only constant + string changes.
(Peppy port of I4172460d3b075bfd5bb22013a6225cf0e8f95b9c by dlaurie)
The following changes are required in a subsequent commit:
- Add Elpida SPD data.
- Update GPIO map.
- Remove iSSD power sequencing.
- Update USB port map.
Change-Id: I01dfb841f0e9186cf8a0a23f72e7be986a83be42
Reviewed-on: https://gerrit.chromium.org/gerrit/56513
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4200
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
RAM_ID indices have been changed and settled on a 2GB config
that will be the same DRAM chips but only used in one channel.
Change-Id: I444e655883ae045622ab3dfb964da4d7f86e1c0d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56810
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4198
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are placeholder values until we can configure for
the exact panel.
Change-Id: If40367c0e5f80d46d085c89b0edae60f1ccacdaf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56808
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4197
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The haswell i915 kernel driver apparently expects the VBIOS
to set a few specific registers. This sequence is enough to
make the driver happy without executing the VBIOS.
This also makes graphics work after suspend/resume.
Change-Id: I34937d55ffff8a9445442e6e6ca1bfc49869da63
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56806
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4195
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the onboard I2C devices for Falco trackpad/lightsensor
and generate SMBIOS Type41 tables for them.
Add ACPI device for the trackpad to expose the interrupt map
to the OS so it can be used.
Configure interrupt GPIOs as PIRQ type and wake GPIOs as
just standard input type. The wake GPIO is reconfigured as
ACPI SCI in the specific device _DSW method. This prevents
the wake GPIO from generating a flood of SCI at runtime.
LTE_WAKE_L_Q and WLAN_WAKE_L_Q are left as ACPI SCI as these
are not repurposed interrupt pins so they are not generated
at runtime.
SIM_DET and ALS_INT_L are set as input since we don't have an
interrupt handler for them.
Change-Id: Ibe9687b2f7f41ead18353c3f650219fe6e94ae2f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56632
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4191
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the onboard I2C devices for Slippy trackpad/lightsensor
and generate SMBIOS Type41 tables for them.
Add ACPI device for the trackpad to expose the interrupt map
to the OS so it can be used.
Configure interrupt GPIOs as PIRQ type and wake GPIOs as
just standard input type. The wake GPIO is reconfigured as
ACPI SCI in the specific device _DSW method. This prevents
the wake GPIO from generating a flood of SCI at runtime.
LTE_WAKE_L_Q and WLAN_WAKE_L_Q are left as ACPI SCI as these
are not repurposed interrupt pins so they are not generated
at runtime.
SIM_DET and ALS_INT_L are set as input since we don't have an
interrupt handler for them.
tested on slippy with trackpad with additional
kernel changes to chromeos_laptop.c to initialize devices.
1) Ensure trackpad interrupt is functional and that there
is not a flood of ACPI SCI when trackpad does interrupt:
9: 1 0 0 0 IO-APIC-fasteoi acpi
37: 421 0 0 0 IO-APIC-fasteoi cyapa
2) Ensure that devices are exposed as wake capable:
Device S-state Status Sysfs node
TPAD S3 *enabled pnp:00:00
TSCR S3 *disabled pnp:00:01
3) Ensure that trackpad can wake from S3 by default, but
that it does not cause an immediate wake when entering suspend.
4) Ensure that trackpad can be disabled as a wake source with
echo TPAD > /proc/acpi/wakeup
Change-Id: Id562d20b54eeefec56040b8f70ef238911312628
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4190
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is an LPT-LP specific method that will enable a specific
GPIO as an ACPI SCI wake source.
It can be used by a device _DSW method to enable a pin that is
otherwise not configured to generate SCI at runtime.
It will set:
- GPIO owner to ACPI
- GPIO route to SCI
- GPIO config to GPIO, Input, Inverted
Also clean up and remove ACPI field definitions that are unused
and/or incorrect.
Change-Id: I14acc2de50e6200f61c2898a7bd1252400e0f0be
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4189
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was provided by the vendor but I added the part number at
byte 128-143 so it can be identified when extracted by mosys.
Change-Id: Ib1e430cd390b4dbc013fc0802f1a59c1a0412577
Reviewed-on: https://gerrit.chromium.org/gerrit/56634
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4192
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In addition to not clearing the pending interrupts, we also
don't want to reset the RTC control register when booting
with an S3 resume.
On most new systems, when the RTC well is losing power, we
will also lose state that is required to perform a resume,
so we end up in a normal boot anyways. Hence don't do any
RTC initialization in the S3 resume path.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I73b486082faa741e9dccd15f2b8e3a8399c98f80
Reviewed-on: https://gerrit.chromium.org/gerrit/56826
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some code was previously removed regarding elf notes. However,
that code left a dangling comma under !CONFIG_MULTIBOOT
configs for inline assembly constraints. Instead, place the comma
within the #ifdef stanza.
Change-Id: I805453ef57d34fbfb904b4d145d8874921d8d660
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56844
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-on: http://review.coreboot.org/4207
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These GPIO accesses were copied by accident and don't
make sense for the baskingridge board.
Change-Id: I03bfc2cf97b6056a746a6c1a27308823ecaa9637
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4204
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
LynxPoint-LP has an additional 16 entries in the IOAPIC that
can be assigned to specific GPIOs when they are configured
as PIRQ.
The maximum redirection entries field in the IOAPIC needs to
be set to 0x27 when this is enabled.
Additionally specific GPIOs need to be routed to PIRQ so they
interrupt via the IOAPIC instead of the GPIO IRQ 14/15.
Change-Id: Ie587e1d203422ff6fb7fc5056d20a5ae66720991
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56620
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4203
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The LynxPoint southbridge ACPI code needs the SSDT2 table to function
properly. Otherwise the ACPI evaluator in the kernel spews errors.
Change-Id: I73918545a07e43f4a281ff34d8537340d601b102
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56601
Reviewed-on: http://review.coreboot.org/4188
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mainboards were defining their own SMBIOS type41
write function. Instead pull this into the generic
SMBIOS code and change the existing mainboards to
make use of it.
Change-Id: I3c8a95ca51fe2a3118dc8d1154011ccfed5fbcbc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4187
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A parrot device with a bad flash part has been seen to hang
in the elog_shrink code becuase the flash was not successfully
erased and it gets stuck in a loop trying to shrink the log
and then add an event.
Change-Id: I8bb13dbadd293f9d892f322e213c9255c8e9acb3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56405
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4186
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Update and use the new pei_data data structure. Now that the
reference code is fixed it's possible to properly disable/enable
the USB2 and USB3 ports correctly.
Change-Id: I075c646e7574be354420b6e59507e8917a97d0f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56594
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4185
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Only the first two DIMM SPDs are specified so far
- GPIO map is updated
- iSSD power sequencing removed
- USB port map updated
Change-Id: I4172460d3b075bfd5bb22013a6225cf0e8f95b9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4184
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ssdt2 generation code was calling acpigen_patch_len().
However, none of the entries had AML object lengths that
needed patching. That resulted in the following message:
ASSERTION FAILED: file 'src/arch/x86/boot/acpigen.c', line 52
Additionally, this caused an errant write to a memory address
whose value was in the variable ltop. This was the 0 address.
Change-Id: I44abf5a4e4225220575aee6b5c9bb6b0be093a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56299
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ACPI code was defining two EHCI controllers and ignoring
the XHCI controller. This changes the second EHCI controller
to be XHCI instead and changes the wake resource to indicate
S3 and not S4.
cat /proc/acpi/wakeup
Device S-state Status Sysfs node
HDEF S4 *disabled pci:0000:00:1b.0
EHCI S3 *enabled pci:0000:00:1d.0
XHCI S3 *enabled pci:0000:00:14.0
Change-Id: If28775e6ef8608c22c85ca91d91d1f598ec7755d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4181
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable GPIO SMI for GPIO34 and set it as inverted so it
is only generated when it is raised by the EC.
1) ec console command: lidopen
2) wait until booted to developer screen
3) ec console command: lidclose
4) ensure system turns off
Change-Id: I7d50f171f3f4539c7c264103d1ffc7c5d0f1c7ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56052
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4177
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The vendor ids were never updated to reflect LynxPoint's device
ids. Therefore, none of the initialization was being ran. Fix
this.
Change-Id: Ic6ec00c9fb1cbcb6087fd89b0acff3d83294ac6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55821
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4173
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to report whether coreboot enabled a SerialIO device
in ACPI mode we had been relying on reading NVS in the _STA
method for the SerialIO device.
The ACPI _STA method has restrictions on what it can access
and is unable to access OperationRegions outside its scope
which means it should not be trying to read NVS.
This change adds a new SSDT to the ACPI tables and fills it
with constants that indicate whether or not a device is enabled
in ACPI mode.
The ACPI code is changed to read these variables from the
SSDT and use that instead of trying to query a variable in NVS.
Attempt to use lpt-clk driver to probe the
device clocks for SerialIO devices and see that the kernel
does not complain about accessing the GNVS region.
Change-Id: I8538bee4390daed4ecca679496ab0cb313f174ce
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Disable EC software sync for now
- Report correct EC active firmware mode
- Force enable developer mode by default
- Set up PCH generic decode regions in romstage
- Pass the oprom_is_loaded flag into vboot handoff data
Change-Id: Ib7ab35e6897c19455cbeecba88160ae830ea7984
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4169
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These boards were returning 0 to indicate success when
the realmode handler expects it to return 1 to indicate
that it handled the interrupt.
Change-Id: I2baeaf8c2774fa7668a8b2f2d9ad698302eefb21
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50881
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4168
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are both pulled up to 3.3V in the schematic.
Change-Id: I12e055a39ff6100300c3d285899b8d6239e3773d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4164
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order for the FIT entries to be populated in the table the
update-fit command needs to be done on the coreboot image. That
way the microcode entries are added to the table properly.
Change-Id: I44595aee1ca710f4f04d482d8900cf95fbc1797f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50317
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4159
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to probe the gpio-lynxpoint kernel driver the
LP GPIO controller needs to be exposed as a specific
ACPI device.
This also allows the resources to be exposed to the OS via
this device instead of the catch-all LPC device.
Ensure the driver loads at boot:
gpiochip_find_base: found new base at 162
gpiochip_add: registered GPIOs 162 to 255 on device: INT33C7:00
Also ensure the driver is visible in sysfs:
$ cat /sys/devices/platform/INT33C7:00/gpio/gpiochip162/label
INT33C7:00
Change-Id: I9f79c008f88da9b67ed1cdfdb9d3a581ce8f05ff
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50215
Reviewed-on: http://review.coreboot.org/4158
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4156
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that we have RW ramstage we don't need to have the
management engine lock down step done in a final SMM.
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
PCI: 00:16.0: Disabling device
Change-Id: I9db4e72e38be58cc875c1622a966d8fcacc83280
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49757
Reviewed-on: http://review.coreboot.org/4153
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There were two undefined MBP types that are now defined.
These include NFC status and some interesting timing data.
ME: Wake Event to ME Reset: 6 ms
ME: ME Reset to Platform Reset: 7 ms
ME: Platform Reset to CPU Reset: 51 ms
Change-Id: I67bf1f303f3c32497041e64c40eb9ccb6a63d88a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49756
Reviewed-on: http://review.coreboot.org/4152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of having an OS re-parse cbmem book-keeping records
for the cbmem allocator just to get the console buffer export
the pointer to the memory console directly in a field named 'CBMC'.
This field lives in the GNVS table.
Change-Id: Ief0c4da7b18df66feb9c816c9f4abdf5a72bd3a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49764
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4149
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If elog_clear is called before other elog functions, for instance if it's
called through an SMI immediately after the system boots, then the elog data
structures won't have been set up and the system will go off the deep end.
This change adds a call to elog_init to elog_clear to make sure things things
are always initialized before we start using them.
Before this change, this command would cause
the system to lock up if run immediately after boot:
echo 1 > /sys/firmware/gsmi/clear_eventlog
After this change, that results in the log being cleared correctly.
Change-Id: I45027f0dbfa40ca8c581954a93b14b4fedce91ed
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49303
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4144
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Slight tweaks found when looking at latest ref code when
investigating package C-state issues.
A few bits in the clock gating register don't match the
documentation and are also cleaned up.
Change-Id: I36ced7280c160b114c70b2eeafc8b24813ff2f6a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49330
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4142
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The mainboard_interrupt_handlers() argument for the function
pointer was using void * as the type. This does not allow the compiler
to catch type differences for the arguments. Thus, some code has been
committed which violates the new interrupt callbacks not taking any
arguments. Make sure the compiler provides a type checking benefit.
Change-Id: Ie20699a368e70c33a9a9912e0fcd63f1e6bb4f18
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48970
Reviewed-on: http://review.coreboot.org/4141
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some handlers still had 2 variants, others were
incorrectly guarded by CONFIG_ variables. This
patch straightens them out.
This does not touch the siemens/sitemp_g1p1 which
provides an interestingly complex solution for the
int15 handler.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I5d74fdf7c2ab1faa96ebc2b5ca5c69398449b069
Reviewed-on: https://gerrit.chromium.org/gerrit/48979
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4140
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC saves its last "shutdown reason" for the system in EC RAM
that we can read back and log on boot.
The decode for the "reason" field will be added to mosys.
Change-Id: I834d39122e45262ef8e7ba59201accbee5857aac
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48323
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4127
Tested-by: build bot (Jenkins)
The format of this function changed but was not updated in
all mainboards. This fixes all Sandybridge/Ivybridge boards.
The int15 handler no longer takes a regs structure as an
argument and instead uses global variables. The yabel interface
is now similar enough that we can drop the duplicate handler.
Change-Id: Icdaae4d6d50884f6d7bce7a167d48cb1d4807010
Reviewed-on: https://gerrit.chromium.org/gerrit/48969
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4135
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Recent commit proposal by Ron Minnich proposes to move to native gfx init for
qemu. Unfortunately we didn't have native init for default qemu video (cirrus)
Here is one extracted from GRUB one which I wrote couple of years ago.
Change-Id: Icb89cf918ef5d276bcc703c48c568e7b9c1be756
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Part of X201 port.
Change-Id: If17d707004aba9f08459dbd8f3a146fa3c076aa9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4052
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Per our discussions with Gerd, qemu will now always do native graphics
on coreboot. The VGA BIOS capability is not needed and will no longer
be supported. Attempts to build without native graphics will result in
an error.
This code builds for both x86 emulation targets. I'm hitting an issue
testing that is unrelated to coreboot; if someone can test, that
would be helpful. Be sure to start qemu with -vga std.
We also add a test for the PCI BAR being zero and return silently if it
is.
Change-Id: I66188f61e1bac7ad93c989cc10f3e0b55140e148
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4258
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Needed to make dock work on X201.
Change-Id: Id0b32266cacf04bb48530bedf50818c268f947ec
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4081
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
SandyBridge raminit uses this CMOS option. If it is not declared, the build
fails when USE_OPTION_TABLE is selected.
Change-Id: I1ba1f994d4ea3824dc66e8f35d0b5b24b88d4dd6
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4269
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
the part !CAR && PRE_RAM is obviously meant as dummies. Unfortunately
cbmemc_tx_byte has wrong number of arguments and hence causes compilation
failure.
Found out when compiling for vexpress-a9.
Change-Id: Ic84d142bac5c455c2371fbc9439c898de04a974e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4267
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
With the XHCI controller enabled we no longer hang the
system when dropping into a package C-state so remove
the code that was disabling it.
Change-Id: Icd60488fd2506dac04fb6ec96a77bec265b10d8c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50355
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4163
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The chromeos_acpi driver sysfs naming is not what
crossystem expects if there is just one entry in the package
because it does not add a ".#" suffix in that case.
Specify all the expected GPIOs on wtm2 as undefined, which
should be 0xFF and not 0x00 becuase 0 is a valid GPIO.
Change-Id: I9b17e9bab94219695e65b17914c84acf02a0983b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50337
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4162
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The current microcode blobs contain both ULT and non-ULT
revisions. Only include one or the other based off of the
CONFIG_INTEL_LYNXPOINT_LP Kconfig option.
Change-Id: I3e4e41d4cd727b1a974361fb469267e6f6022d5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50318
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4160
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
For all the current haswell boards enable the monotonic timer.
The ULT boards use the 24MHz MSR while the non-ULT boards use the
local apic.
Change-Id: I8b19f526a5a49e8467f296c566a2c4263bc5a863
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49763
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4148
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This reads PCH power levels via PCODE mailbox and writes the
values into the PMSYNC registers as indicated in the BWG.
Change-Id: Iddcdef9b7deb6365f874f629599d1f7376c9a190
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4143
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On haswell ULT systems there is a 24MHz clock that continuously runs
when deep package c-states are entered. The 100MHz BCLK is shut down
in the lower c-states. When the package wakes back up a conversion
formula needs to be applied. The 24MHz calibration is done using the
internal PCODE unit.
Change-Id: I6be7702fb1de1429273724536f5af9125b98da64
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48292
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4136
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The c-states are configured according to the BWG, however the
package c-states are disabled as they currently cause platform
instability. The exposed ACPI c-state to processor c-state mapping
are as follows for ULT boards:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C7S long latency)
ACPI(C3) = MWAIT(C10)
The non-ULT boards have an expoed c-state mapping:
ACPI(C1) = MWAIT(C1E)
ACPI(C2) = MWAIT(C3)
ACPI(C3) = MWAIT(C7S)
Included in this patch is removing the updating of current limit
registers as some of the MSRs are different and the proper values
are currently unknown. Lastly, some of the MSRs were renamed to
match the BWG.
Booted 3.8 kernel and used powertop to note package, core, and acpi
c-state residency.
Change-Id: Ia428d4a4979ba3cba44eb9faa96f74b7d3f22dfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48291
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4133
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This will be used in a later commit to do some specific
power sequencing.
Change-Id: Id7f033bb80aed915c2498ea910cb3ac7290da37f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4137
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This adds some macros for the common GPIO defines and drops
the gpio number definition from each entry. The end result
is much easier to read. The wtm2 mainboard gpio list is modified
to use this.
Also fix a bug in the LP version of get_gpio() that was always
returning zero due to a miscompare.
Change-Id: I143e5aee412af1eda84e35f8026f31cf13df508e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48946
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4138
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
With the LynxPoint chipset there are more than 16
possible GPIOs that can trigger an SMI so we need
a mainboard handler that can support this.
There are only a handful of users of this function
so just change them all to use the new prototype.
Change-Id: I3d96da0397d6584f713fcf6003054b25c1c92939
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49530
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4145
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
These are placeholder values until we can configure for
the exact panel.
Change-Id: Ibe88cc3588947366eb1728e5b3e1ab8c8be6dfe8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56807
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4196
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Minor tweaks to variable names in the slippy mainboard
that make it easier to base a new board from without
as much renaming.
Also properly set up the thermal variables for the
thermal zone that is defined in ACPI instead of using
the generic setup from WTM2.
Change-Id: I752c1a50bfdc06b6ddad95bd1331c6870b9f9df2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56328
Reviewed-on: http://review.coreboot.org/4183
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This will log and clear EC events so they do not take effect
when the SMI handler is enabled.
Change-Id: I5ef563f7cedc8977410cc3f69e2655fc4e14c9eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56055
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4178
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The SerialIO devices have specific requirements for PCI
interrupt mode to use PIRQ{E,F,G,H} that are not being met.
D21:F0 uses PIRQE, which must not be shared with other PCH
D21:F1-F6 share PIRQF, which must not be shared with other PCH
D23:F0 uses PIRQH, which must not be shared with other PCH
- Fix D20IR -> D20IP typo
- Remove D25/EHCI2 as it does not exist
- Reorder other interrupts to clear PIRQE/PIRQF/PIRQH
Check device interrupts in the kernel
0: IO-APIC-edge timer
1: IO-APIC-edge i8042
8: IO-APIC-edge rtc0
9: IO-APIC-fasteoi acpi
16: IO-APIC-fasteoi ath9k
18: IO-APIC-fasteoi i801_smbus
19: IO-APIC-fasteoi ehci_hcd:usb1
21: IO-APIC-fasteoi i2c-designware-pci--1, i2c-designware-pci--1
40: PCI-MSI-edge PCIe PME
41: PCI-MSI-edge i915
42: PCI-MSI-edge ahci
43: PCI-MSI-edge xhci_hcd
44: PCI-MSI-edge snd_hda_intel
Change-Id: Id4c08d11d2860f270c6387138acdc7d3d83a85b5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56028
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4176
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The dev screen was not displaying properly. With the
PWM values programmed the screen displays correctly.
Change-Id: I82b56a92e4168022082a2e519026977ee2ae0c9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51472
Reviewed-on: http://review.coreboot.org/4172
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The device at function 0 also needs to be enabled
or the kernel will ignore all other functions.
00:15.0 DMA controller: Intel Corporation Lynx Point-LP Low Power Sub-System DMA (rev 03)
00:15.1 Serial bus controller [0c80]: Intel Corporation Lynx Point-LP I2C Controller #0 (rev 03)
00:15.2 Serial bus controller [0c80]: Intel Corporation Lynx Point-LP I2C Controller #1 (rev 03)
Change-Id: I0e1bc7bb719756496c46664d66dc1b1cf2f4d1ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51370
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4171
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Without an LM10506-A the power sequencing for this
part needs to be done manually using GPIOs.
Change-Id: I842152e5f7c30c8dbe37df0c344935a659eb2887
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49648
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4150
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes an earlier patch that caused the VGA option ROM to be loaded by
coreboot even in normal mode when it isn't needed.
Change-Id: Ie0a331a10fff212a2394e7234a0dbb37570607b7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48173
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4125
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The patch was made by Peter Stuge, I just split it
and added a commit message.
Change-Id: Ieaaaa2611f7bb8968f01b16daefe7e2afe870f72
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/4001
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The patch was made by Peter Stuge, I just split it
and added a commit message.
Change-Id: I4e88c26b70ea8cb249d7613c749b3edc5e3b5e7f
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/4000
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Without that fix the GTT points at 0x00000000.
The patch was made by Peter Stuge, I just split it
and added a commit message.
Change-Id: Ia378b600ba2faf00d42635c6503b94ff0cb1bc8c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/4002
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Move into src/cpu/dmp/dmp_post_code.h
Change-Id: If9f4d842f352eb41618e71f49a226d3cc4ad0b46
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3989
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This permits any software running after the ramstage to tell coreboot that the
boot was successfull.
Change-Id: I6b19160dcf1ea1948360db71d02e344a3bcb44ef
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3992
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The recommendation from Intel is to report each core as a
separate logical domain in the _PSD table.
This goes against the recommendation in the ACPI specification
because all of these cores are on the same package and share a
VR so they will do voltage transitions together.
The reasoning is that with a larger number of logical processors
the P-state often ramps too quickly resulting in higher power
consumption. By exposing each core as a separate domain the OS
can manage them individually allowing the socket to select the
optimum frequency.
$ cat /sys/firmware/acpi/tables/SSDT > /tmp/SSDT
$ iasl -d /tmp/SSDT
Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000000,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000001,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU2, 0x02, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000002,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU3, 0x03, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000003,
0x000000FE,
0x00000001
}
})
}
Change-Id: I5ef41b6ead4d88e9ba117003293dbc629c376803
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4130
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Compile was failing with the following error:
In file included from src/vendorcode/google/chromeos/vboot_handoff.h:22:0,
from src/vendorcode/google/chromeos/chromeos.c:22:
vboot_reference/firmware/include/vboot_api.h:388:18: error: unknown type name 'size_t'
src/vendorcode/google/chromeos/chromeos.c: In function 'vboot_get_payload':
src/vendorcode/google/chromeos/chromeos.c:50:23: error: 'NULL' undeclared (first use in this function)
Change-Id: I13f9e41ef6a4151dc65a49eacfa0574083f72978
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48289
Reviewed-on: http://review.coreboot.org/4131
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When testing Ron's patch on qemu I found out that fill_lb_framebuffer
overwrites size and tag fields. We need either to fix/check all
fill_lb_framebuffer implementations or write tag/size after fill_lb_framebuffer.
I prefer later as it's more robust.
Change-Id: I98f5bac14f65fb4d990cb21426d402b27f2e8a48
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4263
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2065x is with nehalem and not sandybridge.
I don't care much eitherway but it clears some confusion.
Change-Id: Ib2b8e570b830a12ed8d0d313ee4eb56755796d4b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4046
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Unlike on X60/T60 dock has to be inited at the same time as EC.
Change-Id: If6eb3140c871859ce99027a50908f72bcc560243
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4082
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2065x boards don't use MRC. And the space in question isn't used either.
Read number of variable range MTRRs from MSR rather than hardcoding it.
2ff is still zeroed out as unless you zero-out undocumented bits as well
boot fails.
Tested on Lenovo X201.
Change-Id: Ic574193094e7d27c2d6a4d7d3e387d989578532e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4080
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The mdelay is not necessarry on 2065x.
Tested on X201 that it works without delay.
Change-Id: Ida9e85be7c214f3ba4c9476b5d8a0351e7980e5e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4083
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
On AMD Trinity and Kabini boards errors similar to the following are
shown.
ASSERTION FAILED: file 'src/mainboard/asrock/imb-a180/agesawrapper.c',line 431
DmiTable:100123f7, AcpiPstatein: 10010129,AcpiSrat:0,AcpiSlit:0, Mce:10010de9,Cmc:10010eab,Alib:1002111c, AcpiIvrs:0 in
agesawrapper_amdinitlate agesawrapper_amdinitlate failed: 5
The reason is that on f16kb boards, the CDIT and DMI table are not
created. On f15tn boards, only the DMI table is not created.
Until the root cause is found, disable the table generation to remove
the errors.
Thanks to Wei Hu for debugging and reporting this issue on the list [1].
[1] http://www.coreboot.org/pipermail/coreboot/2013-November/076607.html
CDIT table is not created
Change-Id: I837e3c322bb5331a9b950a72397796a60642c3f3
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/4092
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Furquan Shaikh