Age | Commit message (Collapse) | Author |
|
When the const was removed from write function arguments, a related bug in the
5250 code was fixed so that it would still compile. Unfortunately, that same
change needed to be made to the 5420.
Change-Id: If15057c92422de91dc8e35dbd8b5c978bfae122a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64154
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/4417
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The code generally intended to make the pointer const instead of the thing it
pointed at, but it had const backwards. Sometimes both the pointer and the
data could be const, but sometimes there were writes where only the pointer
should be.
Change-Id: Ifcd5495769b86b47d7b583cce63ed5c2158bec4e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63775
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4397
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
Now that the rtd2132 device has the full settings the
panel timings need to be implemented. Sadly, the Tx timings
in the rtd2132 aren't 1:1 with the panel's Tx timings. Below
is the table equivalent:
RTD2132 | Falco Panel
--------+------------
T1 | T2
--------+------------
T2 | T8+T10+T12
--------+------------
T3 | T14
--------+------------
T4 | T15
--------+------------
T5 | T9+T11+T13
--------+------------
T6 | T3
--------+------------
T7 | T4
--------+------------
Change-Id: I10a3ad475d6b9485a707eb49e31afd197fc8d24d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65858
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4472
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It has been disseminated that the RTD2132 chip
needs to be fully programmed for settings to take affect.
Most of the settings are note documented very well and
present themselves as magic values. Also, the wait time
for starting the sequence needs to be bumped from 2ms to 60ms.
Lastly, expose all the known settings through devicetree.
Change-Id: I9eeea9c4a13ec20b8ce1c5297e43c4dd793d90e5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65857
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
When we go through the resume path, there shouldn't ever be a need to
initialize the PS/2 keyboard. The OS is going to reinitialize it
anyway, and it just slows the resume.
Verified Code flow in normal boot/S3 resume with print statements.
Verified Keyboard was correctly disabled and flushed by booting
to recovery mode screen while pressing keys on the integrated
keyboard.
Change-Id: I48bdca2fa2cc0c965401d10fef75cadb09d2e1e9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63648
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
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/4396
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
- prints hex and ascii
- detects duplicate all zero lines
Change-Id: I557fed34f0f50ae256a019cf893004a0d6cbff7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62655
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4392
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The PWM is controlled externally from the APU.
Change-Id: Ia5130d7616991a78dfde44043a60a32cee4f145c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61513
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/4363
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
What gets written into the parade is highly mainboard-dependent.
So the parade_writes array needs to be there.
Change-Id: Ia382d9bf1929e67b7c14d7a09f5461b71866a16b
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61486
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/4362
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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.
This is a clone of a Falco change:
I1a0df80dd47fdbd535aca7a9d49253794c480606.
Change-Id: I625dfbb228d1f293b880a52dfe552842d55a17d1
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63220
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4383
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I9a628cec4da127a3f072d9611259dad99dfa9d29
Reviewed-on: https://gerrit.chromium.org/gerrit/63125
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/4382
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
... 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>
|
|
CPUID 306C3 Haswell MOB C-0 microcode to 12h
CPUID 40651 Haswell ULT C-0 microcode to 15h
localhost ~ # grep microcode /proc/cpuinfo
microcode : 0x15
microcode : 0x15
Change-Id: Ibdfe2b8ef0969b1ccc6dd1642a9fc352b5d11f27
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63045
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4378
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>
|
|
Updated from 161 ref code
Change-Id: I3e07935fec1df21f14d97d165792fe54bf9e474c
Reviewed-on: https://gerrit.chromium.org/gerrit/62128
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4372
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>
|
|
BUG=chrome-os-partner:20448
BRANCH=none
TEST=emerge-bolt chromeos-coreboot-bolt
Change-Id: I634a755ac7659e7a977b51bcc061f69eb8263810
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59843
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4330
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>
|
|
New/more magic values from latest ref code.
Change-Id: Ia2655333b4daca86c2f2a76f5edcd55cdaf3f851
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61334
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4356
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>
|
|
localhost ~ # grep ^microcode /proc/cpuinfo
microcode : 0x14
microcode : 0x14
Change-Id: I839f29cff61abf798a619b30ad945e25c79f548f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60658
Reviewed-on: http://review.coreboot.org/4348
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
To save power, disable audio codec in S3 + S5.
Also, refactor Lynxpoint GPIO code slightly to allow usage in SMM
binary.
Change-Id: I55c4248c89a258b5e4cecf8579eb58f1c15430c0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60950
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4339
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>
|
|
Configure the VR controller. This enables the PSIx levels
as well as C-state ramping. PSIx thresholds are:
- PSI3: 1A.
- PSI2: 5A.
- PSI1: 15A.
Before:
0x601 0x0000000000000100
0x603 0x0036000000262626
0x636 0x000000000000006f
After:
0x601 0x4010140f00000100
0x603 0x0036000000262626
0x636 0x000000000000006f
Change-Id: I6958845ac4164ebd0f1bb2d6d9be55ba63ed9344
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60931
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://review.coreboot.org/4338
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
Some files have incorrect/odd permissions,
correct them: remove unnecessary +x flags.
Change-Id: I784e6e599dfee88239f85bb58323aae9e40fb21c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4490
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
Delete files that (were overlooked and) are probably needed to
build with Visual Studio.
Remove doxygen helper files as well.
Change-Id: I6b6cece178917ad9da1081eb6b1bb9be33066a77
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4489
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.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>
|
|
Change-Id: Ib8dc069c9e503747c349e96a466feb42279afd08
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4305
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@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>
|
|
Implement the LynxPoint BIOS Spec for clock gating.
Change-Id: Iaa84cb447bd29b0d13cdda481a1661ea40499de1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59590
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4325
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/3347
http://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>
|
|
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Icae8042add5f4dd5c707369ffc4587c613d69d29
Reviewed-on: https://gerrit.chromium.org/gerrit/59324
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4315
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Variable use is specific to ChromeOS.
Change-Id: I5b61a038e6b08e3b2408c4d990749d45fdf2148d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4306
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I1a59405499deceed7df01a03834be72830e6578f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4291
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|