This patch was tested with the following card:
IDE interface: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller [1095:0680] (rev 02)
Change-Id: I988b73684b54942d8ee6e44a9319dcc54086fca7
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/12171
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to build stand alone verstage the chromeos.c
file needs to be part of the verstage target.
BRANCH=none
BUG=chrome-os-partner:44827
TEST=Build and run on kunimitsu
Change-Id: I9c547ae177dc95030c8c545a302a2349bf1c9cf8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 07b6465f0b3e18d30647959b8e1db44d8647cf90
Original-Change-Id: I49bf7f1bd2edb32ffe9cc22f6fce1348434fd234
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/301243
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12152
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
The 1392MHz value used to throttle the RK3288 earlier was somewhat
arbitrary. This patch brings the throttling in sync with the operating
points specified in the Linux device tree for RK3288.
BUG=chrome-os-partner:42054
BRANCH=none
TEST=Saw print statement in image.serial.bin indicating that APLL
was set to the desired frequency.
Change-Id: Ibe570267bbfe23f010ad5e1ea651356291b9c63c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a146f23b13cb0f6da93ada65648cf33ecfaaa7d6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I6bcdb5fd6ffa3f9a22e79c519bdb7980492e2318
Original-Reviewed-on: https://chromium-review.googlesource.com/302633
Reviewed-on: http://review.coreboot.org/12137
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This applies CL:300617 to Rialto to down throttle further in
recovery mode.
BUG=chrome-os-partner:42054
BRANCH=none
TEST=Saw print statment in recovery mode with image.serial.bin,
device only got mildly warm after several minutes (not hot).
Change-Id: I08b6024d31c83c6bbd8c8d9d9a07adc9835e81fd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 74eb9143fbe13df5f386185eab9e5ba9df27cadf
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I9e57d826750cb523c115332fa13a6143bcff7449
Original-Reviewed-on: https://chromium-review.googlesource.com/302631
Reviewed-on: http://review.coreboot.org/12135
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Id2230ecd800b138b6ccbbac318e71c9edf076c75
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12116
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ib078b21ddf0493ad6795c6ab79125b3917ff7049
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12115
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I45b3412263507d92f443743d2ee63c9a8ef94795
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12114
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The possibility of adding a bootsplash image to ROM should be independent
from VGA_ROM_RUN and VESA menuconfig options.
For example, the stored image could be saved in CBFS not for coreboot
but for later use in SeaBIOS.
Change-Id: I3a0ed53489c40d4d44bd4ebc358ae6667e6c797f
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/12129
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
LPC decodes were not enabled, leading to a failure of POST 80 cards
and similar debugging devices. Enable the relevant LPC decodes
to allow debugging.
Additionally, the SMBUS controllers were not properly set up.
Enable both the primary and auxiliary controllers.
Finally, K10 and higher CPUs were hanging during boot due to
a misconfigued IOAPIC. Properly configure the IOAPIC.
Change-Id: I9ffb6542ce445ac971fb81f4f554e7f1313e6a98
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12177
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Certain devices, such as the Intel 82575GB, contain multiple nested
PCIe bridges (for example the PES12N3A). Coreboot does not set
the primary bus number of the lower bridges, causing upstream
forwarding failure. This in turn causes coreboot to fail to find
the lowest devices (in this case the NICs), and as a result the
required resources are not allocated and the NICs do not function.
Change-Id: I4fd3aa21a04dbe89ac6a5995e7707af914d432b1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12186
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Peter Stuge <peter@stuge.se>
Update mainboards using the w83795 sensor device with sane default
values. Note that in some cases the defaults may vary from the
defaults provided by the old driver, for example the default fan
speeds and control modes have changed as I do not have any information
on the correct sensor to fan mappings for these boards.
Change-Id: Id2ad6222d7a0f29483b022fa097d7d098c6b4122
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12124
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Add full support for fan control, fan monitoring, and voltage
monitoring. Fan speeds and functions are configurable via
each mainboard's devicetree.cb file.
NOTE: This patch effectively rewrites large portions of
the original driver. You may need to re-verify correct
operation on your hardware if you were using the old
driver code.
Change-Id: I3e246af0e398d65ee43ea708060885c67fd7d202
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11936
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Certain devices (such as the LSI SAS 2008 controller) do not
respond to PCI probes immediately after link training. If it
is known that such a device is likely to be installed allow the
mainboard to insert an appropriate delay.
Change-Id: Ibcd9426628cacd6f88e6e3fcbc2b3eb7e3a92081
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11991
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
If an SMBUS device in devicetree.cb is placed under a parent device
that does not have an SMBUS controller, coreboot will enter an
infinite loop and hang without printing any failure messages.
Modify the loop to exit under these conditions, allowing the failure
message to be printed.
Change-Id: I4c615f3c5b3908178b8223cb6620c393bbfb4e7f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12131
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins)
The hudson chipset has 4 USB controllers, the fourth is USB1.1-only and
(presumably) not used very often, add support for hiding it:
00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03) USB1 (3.0, XHCI)
00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 03)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) USB2 (2.0, OHCI+EHCI)
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11)
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) USB3 (2.0, OHCI+EHCI)
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11)
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) USB4 (1.1, OHCI only)
Change-Id: I804e7852fd0a6f870dd118b429473cb06ebac9a4
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: http://review.coreboot.org/7355
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On my Foxconn nT-A3500 on cold boot the board doesn't survive the soft
reboot in the UsbRxMode path and the vendor bios doesn't touch this
Cg2Pll voltage setting either.
The fixup code for UsbRxMode in src/vendorcode/amd/cimx/sb800/SBPort.c
doesn't seem to "CG PLL multiplier for USB Rx 1.1 mode", but rather
lowers the Cg2Pll voltage from the hw default of 1.222V to 1.1V
by setting Cg2Pll_IVR_TRIM in CGPllConfig5 to 1000.
See also USB_PLL_Voltage which is only used in the UsbRxMode code path.
However if this is already the efuse/eprom default for the SB800 then
UsbRxMode is a no-op, so whether or not it gets executed depends on the
very exact hw revision of the southbridge chip and could change between
two instances of the same board.
UsbRxMode used to be unitialized and was first set to default to 1
in http://review.coreboot.org/6474 (change I32237ff9,
southbridge/amd/cimx/sb800: Uninitialized variables in config func):
> > Why initialize those to 1? (just curious)
> See src/vendorcode/amd/cimx/sb800/SBTYPE.h
> git grep 'SbSpiSpeedSupport\|UsbRxMode'
> src/vendorcode/amd/cimx/sb800/SBTYPE.h
I could not find a corresponding errata in the SB800 errata list,
however errata 15 (USB Resets Asynchronously With Port CF9h Hard Reset)
might play into this being unsafe to do since the code uses CF9h to
reset.
So its possible that while previously undefined it still ended up
defaulting to 0 and the codepath exercised on my board is simply
buggy or there is a difference between a true "SB800" and the
"A50 Hudson M1" presumably used on my board.
Change-Id: I33f45925e222b86c0a97ece48f1ba97f6f878499
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: http://review.coreboot.org/10549
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Replace the AMD SMBus section with the equivalent SB800 smbus.asl
include or remove already commented-out sections.
Verified by running the cpp preprocessor over the DSDTs and diffing the
results against this patch.
The only change is in src/mainboard/siemens/sitemp_g1p1/dsdt.asl, where
someone added RADD and SADD to the OpRegion, but those are unused, so
removing them is fine.
Change-Id: I074c8a1ed1c9a944d4988752bd0fc42c199c766c
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: http://review.coreboot.org/10618
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Auron only has three GPIOs for RAMID, so there is no need for
sixteen SPD file entries. Only include 8 SPD entries.
Change-Id: Icf83719a2a5b9271b29f48cde5c66c4c8ccd07f4
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/12073
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
On Broadwell, this reduces the number of 'remarks' in the IASL build
from 222 to 3.
Fixes these remarks:
Object is not referenced (Name is within method [_CRS])
The ACPI compiler is trying to be helpful in letting us know
that we're not using various fields in the MCRS ResourceTemplate
when we define it inside of the _CRS method. Since we're not
intending to use those objects in the method, it shouldn't be an
issue, but the warning is annoying and can mask real issues.
Moving the creation of the MCRS object to outside of the CRS
method and referencing it from there solves this problem.
This change was made for fsp_baytrail in commit 2eaa0d49
fsp_baytrail: Fix ACPI 'Object is not referenced' warnings
Change-Id: I67a1faf963d1868f4133c7747a43a511cd28a44b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11268
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ASL code is already present in
`southbridge/intel/common/acpi/platform.asl` and
`cpu/intel/common/acpi/cpu.asl`.
So include these files instead of duplicating the code.
Something similar was don in commit commit 24813c14 (i945: Consolidate
acpi/platform.asl).
Change-Id: Ifb434db1b8eb01acf48f26366c5237ae49a8730a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ASL code is already present in
`southbridge/intel/common/acpi/platform.asl` and
`cpu/intel/common/acpi/cpu.asl`.
So include these files instead of duplicating the code.
Something similar was don in commit commit 24813c14 (i945: Consolidate
acpi/platform.asl).
Change-Id: Ide50b34184b80c86b996f86dd589c3cf3bf75587
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11883
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ASL code is already present in
`southbridge/intel/common/acpi/platform.asl` and
`cpu/intel/common/acpi/cpu.asl`.
So include these files instead of duplicating the code.
Something similar was don in commit commit 24813c14 (i945: Consolidate
acpi/platform.asl).
Change-Id: I1e69cf0fd73e70ed6656b9ed6f55aba4c56a6edd
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11882
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit 24813c14 (i945: Consolidate acpi/platform.asl) creates the file
in the directory `src/southbridge/intel/i82801gx/acpi`. Devices with the
southbridge `intel/i82801ix`, like the laptop Lenovo X200, use the exact
same ASL code though. So share this in the directory
`src/southbridge/intel/common/acpi`.
Change-Id: I33b7993bcdbef7233ed85a683b2858ac72c1d642
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit 24813c14 (i945: Consolidate acpi/platform.asl) creates the file
in the directory `src/cpu/intel/model_6dx/acpi`, although the devices
can also use different Intel CPU models like, for example,
`intel/model_6ex` on the Lenovo T60.
Therefore move the file to the directory `src/cpu/intel/common/acpi` so
that other devices, like Intel GM45 based devices, can also include it.
Change-Id: I90126b66a4d70468923622a8e3aebadeafcbf96f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Before this fix the value of PcdEnableSdio was printed as the MIPI/ISP
configuration option.
TEST=Built and booted on Minnowboard Max
Change-Id: Ia9b02d520f4e615f90b45935456b9d97c5d00f11
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10126
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
connections checked by desoldering the FCH and looking at the PCB
this lowers the power consumption by about 150-200mW measured on primary side
based on change #5397
Change-Id: I986c4cc73a247994f2a47fdfd03f585069ca9385
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/11866
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
don't use non-volatile pointers for MMIO access
Change-Id: I9f38012a806e43f2535265f1d25537c59b53904e
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/12081
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The reintroduction of cougar_canyon2 crossed beams with the
moving the GMA display brightness data in ACPI into individual
mainboards.
Make things build again by having the board use the same default values
that it used to use automatically. They may be wrong, but no worse than
what was there before.
Change-Id: Id788034c38b42e1c35d9cd17e9bbb2ce49e3e91c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12132
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
To help hypervisors to assign PCI devices individually to virtualization
guests, page align dynamically allocated MMIO resources.
Tested with kontron/ktqm77 which has dynamically configured onboard
devices on the root bus and secondary buses. Booted Linux and checked
the configuration with `lspci -v`. Got the configuration through Muen's
tools which are very picky about overlapping and alignment. Booted a
Muen based system that uses many onboard devices. GMA, xHCI and one NIC
(on a secondary bus) were verified to function properly.
Change-Id: I2b7115070e1ccad64565feff025289732c3b5e66
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12111
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Those are actually board specific. Keep the old value as defaults,
though. The defaults are included by all affected boards.
Change-Id: Ib865c7b4274f2ea3181a89fc52701b740f9bab7d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11705
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Values based on correlation of brand strings, brand numbers and the TDP
listings on AMD's web site (Wikipedia for Athlon 64 FX-7x TDPs).
Change-Id: I7e6d12d0b6cc4fefc3f84076234c62c40e08304c
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10926
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Please don't remove chipsets and mainboards without discussion and input
from the owners. Someone was asking about cougar canyon 2 just a couple
of weeks ago - there's obviously still interest.
This reverts commit fb50124d22.
Change-Id: Icd7dcea21fa4a7808b25bb8727020701aeebffc9
Signed-off-by: Martin Roth <martinroth@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/12128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It works there, we want it, disable that restriction.
Change-Id: Idc023775f0750c980c989bff10486550e4ad1374
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/12094
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This reverts commit e660651824.
After some discussion on IRC we decided to revert it as libpayload can
only read the copy that was removed (and other users like nvramtool can
only read the other copy). So we need both copies at this time.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6cf6b2a1523d771bb52f3d5720b1b16ed4b348db
Reviewed-on: http://review.coreboot.org/11696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We need to special-case filling out the vboot structures when
we use CBFS instead of vboot's custom indexed format, otherwise
(due to the way the CBFS header looks), it will try to write several
million entries.
Change-Id: Ie1289d4a19060bac48089ff70e5cfc04a2de373f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11914
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some registers only allow word-sized or half-word-sized operations and will
cause a data fault when accessed with byte-sized operations.
However, the compiler may or may not break such an operation into smaller
(byte-sized) chunks. Thus, we need to reliably perform word-sized operations for
32 bit read/write and half-word-sized operations for 16 bit read/write.
This is particularly the case on the rk3288 SRAM registers, where the watchdog
tombstone is stored. Moving to GCC 5.2.0 introduced a change of strategy in the
compiler, where a 32 bit read would be broken into byte-sized chunks, which
caused a data fault when accessing the watchdog tombstone register.
The definitions for byte-sized memory operations are also adapted to stay
consistent with the rest.
Change-Id: I1fb3fc139e0a813acf9d70f14386a9603c9f9ede
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11698
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
With the introduction of these options in commit b26156e
(bd82x6x/xhci: Set mask of ports switchable between USB2 and USB3.)
the default regressed to disable these capabilities. Maybe other boards
regressed too. I didn't check.
Change-Id: I220896e656d00145618e61d55b74904517c7d855
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11287
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These are needed for the hardware-sequencing function of the PCH SPI
interface. Values are specific to the flash chip used on a board.
Change-Id: Id06766b4bac2686406bc09b8afa02f311f40dee7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11798
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Part of the following patch was lost in the merge from chromium.
This patch fixes up the spd_index for the copy from the SPD file.
In spd.c "spd_index *= SPD_LEN" will change the original spd_index
from gpio and let the following if(spd_index>3) to misjudge and
disable channel 1 incorrectly. So we calculate the index for spd file
memcpy when calling memcpy().
BUG=chrome-os-partner:32879
TEST=Can get total memory 4G on yuna 4G SKU
BRANCH=Auron
Original-Change-Id: Iebc49e20e4ca15ef6db8c4defe43cc22382a28bf
Original-Signed-off-by: Tim Chen <Tim-Chen@quantatw.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234420
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Original-Commit-Queue: Shawn N <shawnn@chromium.org>
Original-Tested-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 3b1fce58b7b4b15e947b40fd011174d4e8e294bc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I03f9d63623e083c99d349d938fd802d828858f70
Reviewed-on: http://review.coreboot.org/11911
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Georg Wicherski <gw@oxff.net>
Tested-by: build bot (Jenkins)
Do not hardcode the CPU downstream non-posted request limit; the
value of this register is CPU family specific and is set appropriately
in the corresponding CPU driver code.
Change-Id: I432b942f114243cba23c9a8d916cf6d07bc4740b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11935
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Commit dbeedbef (arch/x86/bootblock: Link in object files selected with
bootblock-y) breaks building of x86 boards with
`CONFIG_EARLY_CBMEM_INIT` *not* selected but CBMEM time stamp collection
enabled.
Aaron Durbin explained as below [1] and provided this patch to fix it.
> That change actually processes bootblock-objs where before it never did
> such a thing. I'm sure this isn’t the only issue lurking. bootblock on
> x86 implied romcc and thus all the bootblock-y += rules that other
> architectures use worked, but now all the implied assumptions are no
> longer true on x86.
>
> timestamp stuff on x86 !CONFIG_EARLY_CBMEM_INIT is the issue you're
> seeing. In order to compile timestamp.c for bootblock under these
> conditions will mean there needs to be some more Makefile guarding.
[1] http://review.coreboot.org/11864
Change-Id: I3441b9fcdbbc8bbe82b9f2075e60668a846ecf09
Fix-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11875
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The broadwell soc code was upstreamed based off an old coreboot branch
and apparently never tested with USBDEBUG.
This changeset fixes USBDEBUG on the not yet upstreamed Auron-Paine
board, as verified with a FT232H setup. The fix is simply removing
outdated code that since branching off had been deduplicated in upstream
coreboot, anyway.
Change-Id: I53c924aa2a5357ed8313d0c9eaa2f9f9e132345e
Signed-off-by: Georg Wicherski <gwicherski@gmail.com>
Reviewed-on: http://review.coreboot.org/11874
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Serial number is derived from the MAC address of first NIC.
Change-Id: I91e5555b462cca87d48fb56c83aedd1eb02eba62
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/11901
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Do this to wipe error message and hexdump of SPD from console log.
Change-Id: I45ffcb1c80aecf43b79d93faedcd62c8f0023cb7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/11900
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Value of tRFCmin was incorrectly using 2 Gigabit chip data.
There was no observed instability or bug reports because of this.
Change-Id: Ifa03b883afa5a304dd20caf3d4d0383c6cfebdb8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/11899
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I3a42ba9494b5174920e36e3110b8d62d721fe742
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11886
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This chip is still being used and should not have been deleted. It's
a current intel chip, and doesn't even require an ME binary.
This reverts commit 959478a763.
Change-Id: I78594871f87af6e882a245077b59727e15f8021a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11860
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The existing microcode update system used custom, manually generated microcode
blob files. This made updates very difficult. Update parser to use stock
microcode update files as provided by AMD.
Change-Id: I772b264ad167f2a5d629dab5d64d9b0ccab3a053
Signed-off-by: Audrey Pearson <apearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11829
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Updating to a new IASL introduces a lot of warnings that are
not serious issues but can be fixed with some reworks.
- Method local variables that are set but never used now warn,
when needing to read back a register the ordering is now changed
to set the value in Local0 first so the compiler does not complain.
- Methods that create an object must be serialized
- A ResourceTemplate declared inside a _CRS with a named variable
does not seem to be able to compile without a warning. To fix
this move the ResourceTemplate outside the _CRS method.
- The DPTF CPU code was still using the old legacy \_PR.CPUx
instead of the new \_PR.CPxx definitions.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=build glados with iasl-20150717 and see no warnings
Original-Change-Id: I4a66c7eb6495aac4ae1aa42100c846725c1a04d2
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302168
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia3af802ca2faab4f1c59e73f2ce31a65c7e862e0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11812
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In order to support verstage the cache-as-ram split
is taken advantage of such that verstage has the
cache-as-ram setup and rosmtage has the cache-as-ram
tear down path. The verstage proper just initializes
the console and attempts to run romstage which triggers
the vboot verification of the firmware. In order to
pass the current FSP to use during romstage a global
variable in cache-as-ram is populated before returning
to the assembly code which tears down cache-as-ram.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with verstage support as well as
VBOOT_DYNAMIC_WORK_BUFFER with direct link in romstage.
Change-Id: I8de74a41387ac914b03c9da67fd80f8b91e9e7ca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11824
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When a separate verstage is employed the verstage file
was just being added through the cbfs-files mechanism.
However, that doesn't allow one to specify other flags
that aren't supported that an architecture may require.
The x86 architecture is one of those entities in that
it needs its verstage to be XIP. To that end provide
a mechanism for adding verstage with options.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using his mechansim on x86.
Change-Id: Iaba053a55a4d84d8455026e7d6fa548744edaa28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11819
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This partially reverts commit 33b535f1. After this commit, samsung/lumpy had its
internal USB EHCI controller broken, with no assigned IRQ.
PIRQA-PIRQH may be wired as edge-triggered interrupts, making them exclusive
for the GPIO to use. They cannot be used for PCI devices at the same time.
Change-Id: Ic90343401ac20ca8673baf927cd7703c3481aeab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/9993
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
If timestamps need to be enabled for t132-boards, build would break
because TIMESTAMP region does not exist. With this change, t132 boards
can enable "COLLECT_TIMESTAMPS" without any build error.
Change-Id: I283a5ec49b5af95bd524f590e352367b7cbfd83d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/11893
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Changes to CR1 and CR2 were effectively overwriting the backlight
configuration from the devicetree with static values.
Instead read the maximum brightness value from BCLM (backlight
modulation frequency) and calculate the target level (Arg0 is the
target level as percentage).
Turned out that _BQC has to return a value from the list returned by
_BCL. So XBQC got a little heavier to search for the correct value.
Change-Id: I35419993c8250c95fc69ba4db30db9dba9e6f8ff
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11704
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The two cases only differ in the register locations.
As the values in BRIG were all the same, consolidate them. They also
got normalized to percentages as the ACPI spec wants that (0x61 was 100%
before).
Change-Id: I9216a953bb89458ed102c39194ea370cbf463d5e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11703
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Consolidate some common (and mostly broken) code. Will try to fix things
in separate commits.
Maybe, igd.asl taken from gm45 (the non-PCH case) could also be used for
i945 and sch. But this needs further investigation.
Change-Id: Id3663bf588458e1e71920b96a3149f96947921e9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11702
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
The right files just need to be added to the verstage
build. Do that so a stand alone verstage builds and
links.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I2d0c98760494e2f4657ee35b6f155690939d2d18
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11827
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to build stand alone verstage the chromeos.c
file needs to be part of the verstage target.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: Id2b05548e4e10cd12002286913f2228b84802e63
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11828
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The current method was only taking the cbfs path. Because
of this fsp.bin was never being utilized from the RW slots.
Using prog_locate() now provides both the cbfs and vboot
locate methods for free.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I2b3e088326d5a965ad90806a7950b9f401ed57de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11831
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Leave the SPI controller enabled upon boot block exit.
BRANCH=none
BUG=chrome-os-partner:44827
TEST=Build and run on kunimitsu
Change-Id: I5b10d7cc8d5d350282206abe6a945bab66f97ada
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: http://review.coreboot.org/11825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Move base address into iomap.h. Use PCI symbols instead of SPI specific
symbols. Fix comments.
BRANCH=none
BUG=chrome-os-partner:44827
TEST=Build and run on kunimitsu
Change-Id: Id5d21603150b52fd1b71dd448105938bd6aff1a9
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: http://review.coreboot.org/11826
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to support x86 verstage proper the work buffer
needs to live in cache-as-ram. However, after cache-as-ram
is torn down one still needs the verification results to
know which slot was selected. Though the platforms with
a dedicated SRAM can just use the work buffer in SRAM, the
x86 cache-as-ram platforms need a place to stash the
results. For that situation cbmem is employed. This works
because when cbmem is initialized cache-as-ram is still
enabled. The VBOOT_DYNAMIC_WORK_BUFFER case assumes
verified boot doesn't start until after cbmem is up. That
doesn't change, but it's a goal to get rid of that option
entirely once all other x86 platforms are moved over to
pre-romstage vboot.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with pre-romstage verification
as well as VBOOT_DYNAMIC_WORK_BUFFER case.
Change-Id: I7eacd0edb2b6ca52b59b74075d17c00b50676d4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11821
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On x86 the early stages are currently execute-in-place which
means they live in the memory-mapped spi flash. However, when
loading romstage from verstage the romstage is
execute-in-place so it's unnecessary to write over a read-only
media -- not to mention writing to read-only memory is wrong
to begin with.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. Noted reduction of 20ms when
loading romstage.
Change-Id: I7cd399302a3925a05fbce82600b4c50ea66a0fcb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11823
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bump up the romstage size to allow more breathing room.
Change-Id: I4df7031d286c13797dccdf2f49d023bbf462fbb8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11830
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The conditions in cbmem console for supporting verstage
were implicitly utilizing CONFIG_BOOTBLOCK_CONSOLE to handle
the cbmem console enablement. Fix it so verstage is a first
class citizen for deciding actions pertaining to cbmem console.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using verstage. cbmem console
shows verstage output.
Change-Id: Iba79efd1c1d4056f1a105a5e10ffc95f3e69b597
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11820
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For the purpose of isolating the work buffer logic
the surface area of the API was slimmed down. The
vb2_working_data structure is no longer exposed,
and the function signatures are updated accordingly.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: If64184a79e9571ee8ef9822cfce1eda20fceee00
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11818
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For vboot1 there was an rmodule that was loaded and ran to
do the firmware verification. That's no longer used so remove
the last vestiges of VBOOT_STUB.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I6b41544874bef4d84d0f548640114285cad3474e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to introduce a verstage which performs vboot
verification the cache-as-ram environment needs to be
generalized and split into pieces that can be utilized
in romstage and/or verstage. Therefore, the romstage
pieces were removed from the cache-as-ram specific pieces
that are generic:
- Add fsp/car.h to house the declarations for functions in
the cache-as-ram environment
- Only have cache_as_ram_params which are isolated form the
cache-as-ram environment aside from FSP_INFO_HEADER.
- Hardware requirements for console initialization is done
in the cache-as-ram specific files.
- Provide after_raminit.S which can be included from a
romstage separated from cache-as-ram as well as one that
is tightly coupled to the cache-as-ram environment.
- Update the fallout from the API changes in
soc/intel/{braswell,common,skylake}.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I2fb93dfebd7d9213365a8b0e811854fde80c973a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302481
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Id93089b7c699dd6d83fed8831a7e275410f05afe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11816
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The report_platform_info() and set_max_freq() are not being
used similarly on skylake and braswell. With the addition
of other SoCs I suspect a similar pattern will emerge. Instead
of having weak functions to ensure things link with the hardcoded
policy push these calls into their respective SoC homes.
For parity, both skylake and braswell were updated to be consistent
with the same calls prior to this patch.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. Built braswell.
Original-Change-Id: I3371d09aff0629503254296955fef28d35754a38
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/303334
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I2de33632ed127cac52d7075cbad95cd6387a1b46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11815
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Latest FSPv83 made some change related to UPD/VPD
need this patch to align those
BUG=None
TEST=Build and Boot Cyan System
BRANCH=strago-7287.B
CQ-DEPEND=CL:*226897
Original-Change-Id: I6395f3a1f4eecaef14fc4720b00252f9e6143fa3
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/291394
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Hannah Williams <hannah.williams@intel.com>
Original-Commit-Queue: Hannah Williams <hannah.williams@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303137
Original-Commit-Ready: John Zhao <john.zhao@intel.com>
Original-Tested-by: John Zhao <john.zhao@intel.com>
Change-Id: I9920eea84b802699454850bfde489668201ffeb6
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11813
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On Skylake, mailbox interface is used to configure VRs, dropping direct msr
writing. With current fsp, svid/vr programming seems to be functional - no
errors are given in the svid transactions in boot, and hw engineer verified
the VRs on Kunimitsu. Additional tunnings might be needed later with power
testing.
24mhz calibration is no longer needed on Skylake due to bclk archtecture
change.
BRANCH=none
BUG=chrome-os-partner:45387
TEST=Built and boot on kunimitsu/glados, reboot, S3/resume verified.
Signed-off-by: robbie zhang <robbie.zhang@intel.com>
Original-Change-Id: If99b5758fcdba8604139c761a07403d4a5d2eb4c
Original-Reviewed-on: https://chromium-review.googlesource.com/301470
Original-Commit-Ready: Robbie Zhang <robbie.zhang@intel.com>
Original-Tested-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Tested-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I98acf78aac9c705614fb200f8c3313a89296fbf2
Signed-off-by: robbie zhang <robbie.zhang@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11811
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Instead of just passing bits, tsc_low, tsc_high, and an
opaque pointer to chipset context those fields are bundled
into a cache_as_ram_params struct. Additionally, a new
struct fsp_car_context is created to hold the FSP
information. These could be combined as the existing
romstage code assumes what the chipset_context values are, but
I'm leaving the concept of "common" alone for the time being.
While working in that area the ABI between assembly and C code
has changed to just pass a single pointer to cache_as_ram_params
struct. Lastly, validate the bootloader cache-as-ram region
with the Kconfig options.
BUG=chrome-os-partner:44676
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: Ib2a0e38477ef7c15cff1836836cfb55e5dc8a58e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/300190
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Change-Id: Ic5a0daa4e2fe5eda0c4d2a45d86baf14ff7b2c6c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11809
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It builds only on veyron_* which already select it, no need to ask user.
Change-Id: Ie508b9eade16e0f39073b23dc0da6b6d1e0a4c73
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10380
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
board_id() returns an integer which is platform-specific. 0 for one port
is different from 0 for another port. So there is no default board_id()
and hence enabling it on boards other than urara would cause build failure.
Not enabling it on urara or just setting id to "(none)" as is default results
in board_id() = 0 which means urara and an error message on console.
Change-Id: I94618f36a75e7505984bbec345a31fe0fa9cc867
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10379
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Fixes linking error. Specifies that we're in text mode.
Change-Id: I7ad258961039c19e1491e2b3832b003671d8a5c7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11848
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
MBa doesn't have a usable usbdebug port.
Change-Id: Ia8459daa5c9b9405c289954b28ecf1423b1f076c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11849
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Tested on T60 with intel graphics.
Change-Id: Id74d0a1315749052e7313135242e6b64862aa5e1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5345
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Only one value would work with corresponding gma code currently (which one
depends on board). Going forward, it's possible to compute which number can
be used, so there is no need to keep this info around.
Change-Id: Iadc77ef94b02f892860e3ae8d70a0a792758565d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11862
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
MBA has eDP and not LVDS, so it's not supported by our native init.
Change-Id: I489b7a98163b648f0e8000202117593c6b1aaf31
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11842
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
MBA has a soldered RAM without SPD, so you need to use stored SPD.
Change-Id: I0205e6c65ccbfe7764c12c815e60801a3c3623a5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11841
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Just ran autoport on the data from MacBookAir4,2
Change-Id: Iba2a56a6846d81d29e6b090a9a31253ce240914d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11840
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Make sure edge write test results are sane.
Check rn.all to make sure rn.start and rn.end are valid.
Most likely the following test is going to fail on the same
rank anyway.
Change-Id: Ifa601406e6c74ceb8d70063be5ce1bf6bc512c18
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11247
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Don't disable PEG bits while turning on IGD.
Fixes PCI device enumeration of PEG devices.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Sidenote: This should be taken from a CMOS option instead.
Change-Id: I2d6522504e4404f2d57f9c319351d08317aefdcb
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11058
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Activate PEG clock-gating only if all PEG devices are disabled.
Fixes system hang when trying to access PEG registers.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Change-Id: I7d62fbb83c16741965639cea1a0e4978d4e3d6da
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11059
Tested-by: build bot (Jenkins)
Since we now have more freedom in the bootblock linking step it no
longer makes sense to use a monolithic bootblock.S. Code segments must
still be included as the order in bootblock.S determines code flow.
However, non-code flow related assembly stubs don't need to be directly
included in bootblock.S
Change-Id: I08e86e92d82bd2138194ed42652f268b0764aa54
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11792
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code flow doesn't fall through to walkcbfs, as it does in the rest
of bootblock.S. Instead, walkcbfs is called (albeit via a jmp). The
linker cannot know this when walkcbfs.S is included directly.
When we use a CAR bootblock, we lose several hundred bytes because
walkcbfs is not garbage-collected, yet it isn't used. This problem
is solved by assembling walkcbfs.S separately, and linking it.
Change-Id: Ib3a976db09b9ff270b7677cb4f9db80b0b025e22
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11785
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As part of preparing for systems with non-memory-mapped media, we want
to be able to call into C code. This change allows us to link C code
directly into the bootblock. The steps of going from bootblock main()
to CAR setup to C code will be implemented in subsequent patches.
Note that a few files selected with bootblock-y will now be compiled
for the bootblock as well, but since we enabled garbage collection,
they will not be included in the final binary.
Change-Id: I5ca6dcaf176f5469c6a3bb925859399123493bc6
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11783
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The only difference between the ifeq/else/endif guarded rules is the
linker flags specific to x86. Add those flags to LDFLAGS_bootblock,
and only use one rule for bootblock.debug.
Change-Id: I986a93e0418f05fb273512d7efe0573052493332
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11782
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The macro is defined in `util/cbmem/cbmem.c` too, so do the same here,
so that searching for that macro name shows all the usages.
Change-Id: I52e9fa414fbbe2012bc6d00312db528efba3e564
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11803
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Commit 47818b4d60
(fsp/cache_as_ram.inc and boards: Fix incorrect usage of POST_IO)
breaks the logic which decides whether FSP
could be found or not in cache_as_ram.inc.
Fix the error by inverting the logic of the test.
TEST=Bootet mc_tcu3 board
Change-Id: I993d3422ac406d204a53e4dc890210fb9a52469d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11806
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The x86 bootblock linking is a mess. The bootblock is treated in
a very special manner, and never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11781
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now, the multi-CBFS code path merely looked up files in the "boot
ro" image (ie. the default), disregarding the specified fmap region to
use for CBFS.
The code still relies on the master header being around, which on the
upside allows it to skip an offset at the beginning of the region (eg.
for ARM bootblocks).
This will change later (both the reliance on the master header and the
presence of the bootblock like this).
Change-Id: Ib2fc03eac8add59fc90b4e601f6dfa488257b326
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11805
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
POST_IO is a user-visible config bool. fsp_1_0/cache_as_ram.inc made a
mess of it, by forcing a build-time error when CONFIG_POST_IO was not
being set. fsp 1.0 boards ended 'select'ing this in their Kconfig.
Refactor fsp/cache_as_ram.inc handling of POST codes, and remove the
"select POST_IO" from boards that have it. Instead of implementing an
ad-hoc changing post code display and a delay based on port 0xed, just
encode the FSP failure code in the POST code. Since FSP failure codes
are > 16, we can encode the failure code in the lower nibble, and theirfailing function in the upper nibble.
Change-Id: Iaa3e6533e8406b16ec0689abd704984d79293952
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8485
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
There is no other guard to prevent this from being picked up when
building for other architectures.
Change-Id: I2039a289a4dd9970d5dd0f90d43d5d5c2a6d0a0b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11795
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The EM100Pro allows the debug console to be sent over the SPI bus.
This is not yet working in romstage due to the use of static variables
in the SPI driver code. It is also not working on chipsets that have
SPI write buffers of less than 10 characters due to the 9 byte
command/header length specified by the EM100 protocol.
While this currently works only with the EM100, it seems like it would
be useful on any logic analyzer with SPI debug - just filter on command
bytes of 0x11.
Change-Id: Icd42ccd96cab0a10a4e70f4b02ecf9de8169564b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Building an image for the Lenovo X201 with native graphics
initialization selected fails due to the changes introduced by commit
a3b898aa (edid: Clean-up the edid struct).
Same as in 11738 / 11585 / 11491
Change-Id: I4233a4ce2f5423c7ebdad68e8059cd34ac61cfaa
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/11787
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Users of DRIVERS_UART_8250MEM_32 would have to also select
DRIVERS_UART_8250MEM to avoid missing Kconfig dependencies. Instead,
do what the OXPCIE driver dies and select the appropriate options.
Change-Id: I40d93df024fcb3a9ad6dc51d6a5966e7b1b6c07f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11786
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Certain chipsets provide their own main symbol for verstage.
Therefore, it's necessary to know this so that those chipsets
can leverage the common verstage flow.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built nyan using this option.
Change-Id: If80784aa47b27f0ad286babcf0f42ce198b929e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Though the tegra124 SoC makes their faster cpus come up
in verstage it can still use the common flow. Therefore,
use the common verstage API for performing thenecessary
steps to initialize the caches on the faster cores.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built nyan.
Change-Id: I93023ec92a9de111db688742b057b5c64143f0b3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11776
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The file was not referenced or used. Kill it.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I30285d523ef3ca4dd3ce38b53aeb42862d929c90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11775
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are compiler settings and interactions with other
header files that should be handled. First use __typeof__
instead of typeof because 'std' modes don't accept typeof.
The __typeof__ variant works equally well on clang. The
other change is to guard the helper macros so as not to
trigger redefinition errors.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built cbfstool including commonlib/helpers.h
Change-Id: I58890477cb17df14a9fa8b7af752a7c70769cf36
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11773
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to support FSP 1.1 relocation within cbfstool
the relocation code needs to be moved into commonlib.
To that end, move it. The FSP 1.1 relocation code binds
to edk2 UEFI 2.4 types unconditionally which is separate
from the FSP's version binding.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: Ib2627d02af99092875ff885f7cb048f70ea73856
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11772
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that the commonlib/endian.h routines have landed utilize
those in the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: If431d64fd2843bea864d971ca1ea06b07c0d6435
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11771
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Remove dummy data from hwinfo.hex as it is not needed
anymore in the system.
Change-Id: I4f328a4ef61741039eb2c030e23fea33f539c2bb
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11763
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Since microcode was moved to 3rdparty/blobs, we need to select
USE_BLOBS in Kconfig to get the submodule 3rdparty/blobs automaticaly.
Change-Id: I25e574fd90b830448cacccd16d01a5a2dbc8517d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11764
Tested-by: build bot (Jenkins)
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
I missed these Makefile.inc changes. As verstage.c was removed
remove the references within the Makefile.incs.
Change-Id: I5d38c0a87d057622a3706bf3bde1142944c3b17c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11759
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since fsp_baytrail was refactored to use microcode.bin
in 3rdparty/blobs, we do not need MICROCODE_INCLUDE_PATH any more.
Change-Id: I4382b0c174877186bd37fbff21f3269136d15e10
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11762
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Building an image for the Lenovo X200 with native graphics
initialization selected fails due to the changes introduced
by commit a3b898aa (edid: Clean-up the edid struct).
Change-Id: Ifd36571c9c00761b4a2a6deb3c9c4a52d9d13e25
Signed-off-by: Audrey Pearson <apearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11738
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
vboot_handoff_flag was duplicating the logic to grab the handoff info, that is
already made available with vboot_get_handoff_info.
This uses vboot_get_handoff_info in vboot_handoff_flag instead.
Change-Id: I28f1decce98f988f90c446a3a0dbe7409d714527
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11498
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Inspired by the Sage source code (itself from coreboot).
Change-Id: I4864923166efb200882d895c572d1ee060c71951
Signed-off-by: Maxime de Roucy <maxime.deroucy@gmail.com>
Reviewed-on: http://review.coreboot.org/11730
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The thermal sensor interface exposed in function 3 of the northbridge is
a more convenient and faster way to access the processor-internal
thermal sensor than using the SMBus/SB-TSI interface from the FCH, see
the Family14 BKDG: "Tctl is a processor temperature control value used
for processor thermal management. Tctl is accessible through SB-TSI and
D18F3xA4[CurTmp]. Tctl is a temperature on its own scale aligned to the
processors cooling requirements"
Also on at least some of these boards the existing thermal zone is
broken and always returns 40C (the default value if the SMBus read
failed) because the SMBus muxing register (SmBus0Sel) is not set up
correctly.
Case in point: The fallback "smbus read failed" temperature is 40 C and
the the logs taken from the board status repository for the Asrock
E350M1 board all show: "ACPI: Thermal Zone [TZ00] (40 C)"
e.g.
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asrock/e350m1/4.0-5054-gf584218/2013-12-20T20:56:20Z/kernel_log.txt#l390
and
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asrock/e350m1/4.0-7030-g6d7de4f/2014-10-16T15:34:19Z/kernel_console.txt#l404
and
http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asrock/e350m1/4.0-9989-gf2dfef0/2015-06-13T00:22:49Z/kernel_log.txt#l425
Example lm-sensors output with this patch on the pcengines APU1, on
Linux 4.1.0-rc8+ (wiht both CONFIG_ACPI_THERMAL and
CONFIG_SENSORS_K10TEMP enabled):
acpitz-virtual-0
Adapter: Virtual device
temp1: +54.0 C (crit = +100.0 C)
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +54.0 C (high = +70.0 C)
(crit = +100.0 C, hyst = +97.0 C)
Change-Id: Id9c5b783ba424246816677099ec6651814e59f21
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: http://review.coreboot.org/10940
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add some missing devices to device tree and header.
Remove the obsolete devices.
Change-Id: Ieeca06c68fe8c8eef6be4fab43193b898aebf013
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11378
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The vboot verification in a stage proper is unified
replacing duplicate code in the tegra SoC code. The
original verstage.c file is renamed to reflect its
real purpose. The support for a single verstage flow
is added to the vboot2 directory proper.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I14593e1fc69a1654fa27b512eb4b612395b94ce5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11744
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Using a copiler to compile something that's already a binary is pretty
stupid. Now that Stefan converted most microcode in blobs to a plain
binary, use the binary version.
Change-Id: Iecf1f0cdf7bbeb7a61f46a0cd984ba341af787ce
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11607
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to do a verification of romstage on x86 one needs to
run verstage which verifies romstage (and the memory init code).
However, x86 doesn't have SRAM like every other modern SoC so
managing the cache-as-ram region is especially critical.
First move all of the "shared" objects to the beginning of
the .car.data section. This change then ensures that each stage
using car.ld to link has the same consistent view of the addresses
of these fixed-sized objects in cache-as-ram. The CAR_GLOBALs can
be unique per stage. However, these variables are expected to have
a value of zero at the start of each stage. In order to allow a
stage to provide those semantics outside of the initial cache-as-arm
setup routine add _car_global_start and _car_global_end symbols.
Those symbols can be used to clear the CAR_GLOBALs for that stage.
Note that the timestamp region can't be moved out similarly to the
pre-ram cbmem console because the object storage of the timestamp
cache is used *after* cache-as-ram is torn down to indicate if the
cache should be used or not. Therefore, that timestamp needs to
migrated to ram. A logic change in src/lib/timestamp.c could
alleviate this requirement, but that task wasn't tackled in this
patch.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I15e9f6b0c632ee5a2369da0709535d6cb0d94f61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11740
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to support verstage on x86 one needs to link verstage
like romstage since it needs all the cache-as-ram goodies. Therefore,
provide a macro that one can invoke that provides the necessary
recipes for linking that particular stage in such an environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I12f4872df09fff6715829de68fc374e230350c2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11739
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This moves a few vboot-prefixed functions that were defined in chromeos.c to
vboot_common.c, since those are only relevant to vboot and depend on the vboot
handoff data. This allows more separation between CONFIG_CHROMEOS and what
CONFIG_CHROMEOS selects, so that each separate option (such as
CONFIG_VBOOT_VERIFY_FIRMWARE) can be enabled separately.
Thus, the actual definitions of these functions will only be declared when
CONFIG_VBOOT_VERIFY_FIRMWARE is set, so the check before calling
vboot_skip_display_init in bootmode was also adapted.
Change-Id: I52f8a408645566dac0a2100e819c8ed5d3d88ea5
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11497
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Avoid specifying the size of the microcode in microcode_size.h.
Instead, the size will be determined during build time and
microcode_size.h will be generated. This way, the size does
not need to be adjusted by hand.
Change-Id: I868f02b0cc03af12464a6a87c59761c200eb2502
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11709
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the common ME and descriptor code.
BUG=chrome-os-partner:43462
BRANCH=None
TEST=Built glados
Change-Id: I7196f587b92fd26129b30e2cd73f4caf5f4ebef8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11735
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of selecting the Kconfig option and adding the subdir
entry within each chipset auto include the common/firmware
directory as it's guarded by HAVE_INTEL_FIRMWARE.
BUG=chrome-os-partner:43462
BRANCH=None
TEST=Built glados.
Change-Id: I166db67c41b16c4d9f0116abce00940514539fa5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11734
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The output of command below,
# i386-elf-nm build/cbfs/fallback/romstage_null.offenders | \
grep -q "" ; echo $?
has different result on MacOS, OS X Mavericks, which outputs 0.
On linux, it outputs 1.
I assume it is misleading to search an empty string in a empty
string. Change it to testing if the string is empty.
Change-Id: Ie4b8fe1fb26df092e2985937251a49feadc61eb0
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This fixes building with CONFIG_COVERAGE=y
Change-Id: I5128ae0ef0d4f71e3ede7bcb3ee7ed7e265d1bb7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11729
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Set XN bit of block upper attribute to device memory in mmu. CPU may
speculatively prefetch instructions from device memory, but the IO
subsystem of some implementation may not support this operation. Set
this attribute to device memory mmu entries can prevent CPU from
prefetching device memory.
BRANCH=none
BUG=none
TEST=build and booted to kernel on oak-rev3 with dcm enabled.
Change-Id: I52ac7d7c84220624aaf6a48d64b9110d7afeb293
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7b01a4157cb046a5e75ea7625060a602e7a63c3c
Original-Change-Id: Id535e990a23b6c89123b5a4e64d7ed21eebed607
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/302301
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There appears to be an issue that is causing this particular bit of
ACPI code to be incorrectly interpreted by the kernel and the IASL
disassembler.
Ensuring the PCRB() method is defined in the DSDT before any uses of
it appears to fix the problem, but that relies on specific ordering
of the ASL files included by pch.asl and may break again in the future
if the includes were re-ordered. (they are alphabetic now)
So in this case to work around the issue unroll the function call so
the admittedly messy calculation is reduced to a constant when compiled.
Note this issue was observed with both iasl-20130117 and
iasl-20150717.
ACPICA bug: https://bugs.acpica.org/show_bug.cgi?id=1201
BUG=chrome-os-partner:45760
BRANCH=none
TEST=verify disassembled AML is correct
Change-Id: I7b6a3b792f79755db0ea7b9f2ef6ee7f5000e018
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ecacc340d6e1068ea649f0859657bb3208695730
Original-Change-Id: I232523f5b6ce290da6e7d99405a53b9437b10e0d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302167
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11721
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
BUG=chrome-os-partner:41280
BRANCH=none
TEST=Audio jack insert/eject detection and headset buttons work
on glados with the nau8825 driver in chromeos-3.18 and the
staging kernel skl2.
Change-Id: I813a985b4a39249a2cdbe45117acbdb7710bfa29
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a5b3dafd407fea2376dff5c3dcde50dff4704fb
Original-Change-Id: Ic24a0c444761d0f3a35c268078e70d9aacca4c80
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293610
Original-Reviewed-by: Anatol Pomazau <anatol@google.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11720
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Remove the CTDP support code that is in ACPI. It has been ported
from haswell and while the MCHBAR register interface does seem to
still exist the calculations for determining PL2 is no longer
straightforward.
Additionally nothing is using this interface and the expectation
is that DPTF will be used for throttling with PL[1234] and having
ACPI interfere with the configuration would not be good.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I81e356ddf564a5253458b82bc3327bfb573ab16d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 884ee9a764bad0b3b4bcaeb5a3f46c5f090a116c
Original-Change-Id: I284ab52a305cee25c88df5228b01ff1e9544efe3
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302166
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11719
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Recent version of iasl are flagging more things as warnings.
Remove unused Local0 uses and make _CRS method serialized to
fix these warnings.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build glados with iasl-20150717
Change-Id: I1d4535205426dd9a6346f53ff159221cf5cd899a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8b43f8f24bb7cb33ad0411c24616da66663c2e3e
Original-Change-Id: I71eafd91d30d5f50e6211368f0bbc517c8085892
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302163
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11716
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Since the TPM _CRS method creates named objects it needs
to be serialized to prevent a warning in recent iasl.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build glados with iasl-20150717
Change-Id: I59a52552ab24b7d9c9928331aa8c8d19f54fd1b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a5c474c94980661573a99eb94d5f661f2d0114b
Original-Change-Id: Ie9d164ea8781304dd0bf1833d182d7c601b8e18d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302162
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11715
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
In order to wake from S0ix the kernel needs to know that the
keyboard interrupt is wake capable. Using IRQNoFlags does not
allow the wake capability to be reported.
For normal S3 this does not matter as the EC is the one handling
the keyboard wake event. For S0ix the EC does not need to be
involved in this particular wake event.
BUG=chrome-os-partner:43079
BRANCH=none
TEST=echo freeze > /sys/power/state and wake from keyboard
Change-Id: I7175d2ea98f8a671765897de295df7b933151fc4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 645f1cd96c35f42aa7c40ff473b15feb619b0373
Original-Change-Id: Ia89c30c51be9db7b814b81261463d938885325fd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/301441
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11712
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
While the romstage code flow is not consistent across all
mainboards/chipsets there is only one way of running ramstage
from romstage -- run_ramstage(). Move the
timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage().
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. TS_END_ROMSTAGE still present in
timestamp table.
Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11700
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This removes the dependency on chromeos and vboot for the sw write protect state
function: vboot_get_sw_write_protect, renamed to get_sw_write_protect_state to
both reflect this change and become consistent with the definition of
get_write_protect_state that is already in use.
Change-Id: I47ce31530a03f6749e0f370e5d868466318b3bb6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11496
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When building for ChromeOS, it is expected that Coreboot will only occupy the
first MiB of the SPI flash, according to the veyron fmap description.
Otherwise, it makes sense to use the full ROM size.
Change-Id: I168386a5011222866654a496d8d054faff7a9406
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11117
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Unlike the other stages, the payload requires virtual memory to be set up
and also a privelege level change.
Change-Id: Ibbe2a55f7719d917f121a53a17c6d90e6b2ab3d1
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/11699
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Currently coreboot expects the loader to clear the bss section
for all stages. i.e. stages don't clear their own bss. On ARM
SoCs the BootROM would be responsible for this. To do that
one needs to include the bss section data (all zeros) in the
bootblock.bin file. This was previously being attempted by
keeping the .bss info in the .data section because objcopy
happened zero out non-file allocated data section data.
Instead go back to linking bootblock with the bss section
but mark the bss section as loadable allocatable data. That
way it will be included in the binary properly when objcopy
-O binary is emplyed. Also do the same for the data section
in the case of no non-zero object values are in the data
section.
Without this change the trick of including .bss in .data
was not working when there wasn't a non-zero value object
in the data section.
BUG=None
BRANCH=None
TEST=Built emulation/qemu-armv7 and noted bootblock.bin contains
the cleared bss.
Change-Id: I94bd404c2c4a8b9332393e6224e98940a9cad4a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This commit adds read/write functions for both big and
little endian interpretations. Additionally there are
variants that allow an offset to be provided into the
source buffer.
BUG=None
TEST=Wrote test harness for functions. Also booted ARM QEMU
through end of payload.
Change-Id: If44c4d489f0dab86a73b73580c039e364c7e517d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11677
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the common ACPI _SWS code and provide a function to fill out
the wake source data.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-samus coreboot
Change-Id: I3d2ceca8585314122b78317acb7f848efb6e9a14
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d8afaee8e27222639c5e249d53be28cddcb78f72
Original-Change-Id: Ie551ecf3397c304216046cc2046c071f7b766e5f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298168
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11647
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Switch braswell to use the common code for filling out the NVS
data used by ACPI _SWS methods. This code was out of date on
braswell so also update it to provide the \_GPE.SWS method.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-cyan coreboot
Change-Id: I41c2a141c15f78dc0d9482954c157f81bd0759fa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c4d1ee76f337addf687ca5a9ae2da5e898c2de0
Original-Change-Id: I44424784d5d3afb06d0d58c651a9339c7b77418c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298230
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11649
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Enable and use the common code for filling out the NVS data used
by the _SWS methods. Add a function to provide the wake source
data. With Deep S3 enabled skylake does not retain the contents
of the PM1_EN register so instead just select the wake related
events in PM1_STS.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=tested on glados by checking for valid _SWS string in
/sys/firmware/log after suspend/resume. Wake sources that were
tested are RTC, power button, keypress, trackpad, and wifi.
Change-Id: I93a4f740f2e2ef1c34e948db1d8e273332296921
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cb4d4705b87ef7169f1979009c34a58de93c4ef0
Original-Change-Id: Ib6b4df09ea3090894f09290d00dcdc5aebc3eabb
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298169
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11648
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is a follow-up patch to
https://chromium-review.googlesource.com/#/c/286877, after fsp support
is landed in v1.5.
BUG=chrome-os-partner:42975
BRANCH=none
TEST=execute "mosys memory spd print all" on glados and kunimitsu
Change-Id: I949e287372b190affac36a0efde8a30402eecdc8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 71a2e1838ff8bbaa358c167dad905b63d23c43fa
Original-Change-Id: I64103af4f8456a053a955845a067062122f47af3
Original-Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/298967
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11657
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Assign GPE DW0 to GPP_B block
- Enable GPP_B16 as ACPI_SCI for wake
- Define PCIe WLAN device in ACPI with GPE0_DW0_16 for _PRW
Note that current designs cannot wake from Deep S3 via wifi.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I1fe15a5a9b3d868a0e4f1bfb102b69f024c3aa48
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: de9dfee840246866a8dcca2e1c42c0292e820529
Original-Change-Id: I926d74b6bcf6d64c3db61ed23d7c17b51a98b052
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298232
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11651
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Assign GPE DW0 to GPP_B block
- Enable GPP_B16 as ACPI_SCI for wake
- Define PCIe WLAN device in ACPI with GPE0_DW0_16 for _PRW
Note that current designs cannot wake from Deep S3 via wifi.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=tested on glados:
1-disable deep s3 in devicetree.cb
2-enable magic packet with "iw phy phy0 wowlan enable magic-packet"
3-powerd_dbus_suspend to go to S3
4-wake system with magic packet
Change-Id: I989768615e9da8ecf6354852d2db7aae8069aa82
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 894354c5bfd499b911b7f89310c48b503dbaadc2
Original-Change-Id: I9a7a317fc2eccc70fdb4862843de1a654fbc2eee
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298231
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11650
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The values are taken from latest BWG as well fsp src.
BRANCH=none
BUG=chrome-os-partner:45208
TEST=Built and boot on kunimitsu
Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Change-Id: Ia6bd336a71b0313801b59990c78822fa0d789e36
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c955ab43245153d76932daa527f1b5ebea859164
Original-Change-Id: I3f7307951753c2bbe6319f627a82a93359c4e61b
Original-Reviewed-on: https://chromium-review.googlesource.com/299480
Original-Commit-Ready: Wenkai Du <wenkai.du@intel.com>
Original-Tested-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11659
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order for easier consumption in userland tools split the
FSP 1.1 relocation logic into a single file w/ an aptly named
function name.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I49998b8621611c638375bc90884e80d0cd3bdf78
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bc898e1c528df60683575d553d6194a1e8200afa
Original-Change-Id: I736c0059d43f6d0be4fdb6e6f47cdb5c189a7ae8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298833
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11665
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
UEFI defines everything as little endian. Additionally the
EDK II header files assume they are used on machines
which are running UEFI -- thus little endian. This patch
attempts to fix up all the possible endian violations
when running on a big endian machine. This is for
in preparation of using the FSP 1.1 code in userland
for relocating FSP images.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I39f4de84688e48978a4650303b8af8345f44fd03
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3c7eab9b7c10765355feffa3c3cac403275f9479
Original-Change-Id: I33a7661281307cf31ae33899d1a4eb6a2fbd01a1
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298832
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to integrate fsp 1.1 relocation with cbfstool one
needs to be able to supply the address to relocate the FSP
image. Therefore, allow this by returning offset for return
values. Note that exposed API has not changed.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. Confirmed relocation values matched.
Change-Id: I650a08ffb9caf7e0438a988cae9bec56dd31753c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 53870b0df809418e9a09e7d380ad2399a09fb4fb
Original-Change-Id: Ic2ec63681ed4e652e2624b40e132f95d1e5a0887
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298831
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/11663
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Patch b2a62622b (linking: move romstage and bootblock to use program.ld)
unified the linker scripts between different stages. Unfortunately it
omitted several special cases from the old bootblock.ld script that are
required for non-x86 environments.
This patch expands program.ld to once again merge the .BSS into the
program image for bootblocks (ensuring correct initialization by the
external loader). It also revives the .id section (which adds a
human-readable blurb of information to the top of an image) and fixes a
problem with unintended automated section alignment.
BRANCH=None
BUG=None
TEST=Jerry and Oak boot again.
Change-Id: I54271b8b59a9c773d858d676cde0218cb7f20e74
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6fddbc00963e363039634fa31a9b66254b6cf18f
Original-Change-Id: I4d748056f1ab29a8e730f861879982bdf4c33eab
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/299413
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11660
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In LP0 resume, a couple of SDMMCx pad settings need to be set to 0 to
reduce power leakage.
BUG=None
BRANCH=None
TEST=Tested on Smaug; able to suspend/resume >100 times
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9f35a90a8af2180443db2c4be75d4566d0990de5
Original-Change-Id: Ifc946b0cea437ef0807cea0c11609d8e09387e8e
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/298195
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Tested-by: Joseph Lo <josephl@nvidia.com>
Original-(cherry picked from commit be3ac49a6bc4c9088d3799555d69c87c8ce1693c)
Original-Reviewed-on: https://chromium-review.googlesource.com/298154
Original-Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: If5d5cebc89b8220480b3c72293a410e782eb437e
Reviewed-on: http://review.coreboot.org/11656
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
FSP should not lock CMOS unconditionally. coreboot sends Silicon
UPD parameter "RtcLock" to FSP to take action on CMOS
region locking/un-locking. This patch has CB generic code for
creating the Silicon UPD paramater.
BUG=chrome-os-partner:44484
BRANCH=none
TEST=Build and booted in kunimitsu, tested using below command-
When DIsabled RtcLock from devicetree in coreboot, booted to kernel
and run following commands -
>> crossystem fw_result=success
>> crossystem | grep fw_result
It should reflect the value that is set. Here, success.
If ENabled RtcLock from Coreboot devicetree, The same commands will
fail to update the fw_result status from crossystem utility.
CQ-DEPEND=CL:*229144
Change-Id: I7f63332097cdaf6eedefbc84bec69ce4e9cc59d7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c7b8293a2c55117d7ca2001ac9ec0de24d35b80b
Original-Change-Id: If708e2c782644dcf7f03785d1bfa235ef5385d80
Original-Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/297980
Original-Commit-Ready: Subrata Banik <subrata.banik@intel.com>
Original-Tested-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11655
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, erase operation only works if the region is sector-aligned.
These asserts ensure we can erase the region when it's all used up.
Erase operation can be updated to handle unaligned erases by read,
update, write-back cycle. However, these asserts will still remain useful
in case the adjacent region contains critical data and mis-updating it
can cause a critical failure.
Additionaly we should write a FAFT test but it's more reliable to catch
it here since FAFT can fail in many ways.
BUG=none
BRANCH=master
TEST=tested on samus using misaligned nvram region
Change-Id: I3add4671ed354d9763e21bf96616c8aeca0cb777
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fc001a4d3446cf96b76367dde492c3453aa948c6
Original-Change-Id: Ib4df8f620bf7531b345364fa4c3e274aba09f677
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297801
Reviewed-on: http://review.coreboot.org/11654
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The EC doesn't support these commands so sending them is
not working. We have had a default policy of wake on USB
for a long time now and this runtime config isn't really
needed any longer.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I547d92b4e852664567792060bf1f7b60976bb9a6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4a929eb9ec422e145006505ea4d5fbd1ef3950be
Original-Change-Id: I01e80de65e6e1cdcabb24edb43bc671f5a8aa437
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298234
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11653
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The EC doesn't support these commands so sending them is
not working. We have had a default policy of wake on USB
for a long time now and this runtime config isn't really
needed any longer.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: Ib789ae3a7ba56a11dfb5918cb40bfa2f044d1dc3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ed7391942afed94bfc7ad04880d4c2b865e5655
Original-Change-Id: I6fe10952f32673a447001b832ac6c6b04b22aef0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298233
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11652
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add common code for filling out the NVS fields that are used by
the ACPI _SWS methods. The SOC must provide a function to fill
out the wake source data since the specific data inputs vary by
platform.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I4f3511adcc89a9be5d97a7442055c227a38c5f42
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cee5fa176c16ca44712bce8f3c8045daa5f07339
Original-Change-Id: I16f446ef67777acb57223a84d38062be9f43fcb9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298167
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11646
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If we use a linux payload/any payload that wants to manage virtual
memory, and the payload is a supervisor (thus requiring virtual
addressing before being started), we need to make sure that the page
table is mapped into the virtual address space. Move the start address
of the tables so the payload can manage virtual memory.
Change-Id: I1d99e46f38a38a163fb1c7c517b1abca80cde0dc
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11621
Tested-by: build bot (Jenkins)
Existing memlayout code placed sections in overlapping areas, and would
overwrite the payload if it was large enough. Update memlayout.ld in
src/mainboard/emulation/spike-riscv to represent the spike emulator, and
add sbi interface which now has room into src/arch/riscv/bootblock.S.
Add utility code to qemu-riscv, but emulator itself has yet to be
updated to new ISA and as such should not be used.
Update Makefile to include all the files necessary for sbi interface.
Clean up unused include in src/arch/riscv/include/atomic.h and
whitespace in src/mainboard/emulation/spike-riscv/memlayout.ld
Fixed whitespace issues in spike_util.c
Change-Id: Id97fe75e45ac1361005bec6d421756ee3f98a508
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11370
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Kunimitsu has an ambient light sensor connected to the EC which
is presented to the OS as a standard ACPI0008 device.
BUG=chrome-os-partner:43493
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I7998c19e5514eda781cc20888cdb0732f81389ae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a67e5ddfccea0776841fabe04be55c1854bf31f2
Original-Change-Id: I381dc9c5777370df2ea4c41c9e153b3277082718
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298252
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Glados has an ambient light sensor connected to the EC which
is presented to the OS as a standard ACPI0008 device.
BUG=chrome-os-partner:43493
BRANCH=none
TEST=test ALS functionality on glados P2 board
Change-Id: I4a4913a1b407720d85f6e630b674e550bf5e36df
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aee2b2446ca45039f1b4866feb83754861dba054
Original-Change-Id: I61f3f31ba077f63b36aa0cd9707e128e65c9ea7d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298251
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11644
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch will reset Deep S3 flag, hence S3 will work.
BUG=chrome-os-partner:40635
BRANCH=None
TEST=Build and Boot Kunimitsu and verify S3 is working.
Change-Id: Iad87b7a8f7bf560861a270a8c19153cfc3850bc4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fbfaa29041be49e4c39d19cb94f01ad10d12c7d5
Original-Change-Id: I5ae1738c5de1bee1ad9a45ebde074a6a378492af
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/297903
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11643
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This switches the final 4 Intel platforms that use ME firmware from
using code specific to the platform to the common IFD Kconfig and
Makefile.
braswell, broadwell, bd82x6x (cougar point & panther point) and ibexpeak
Change-Id: Id3bec6dbe2e1a8a90f51d9378150dbb44258b596
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10876
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Now that cbfstool supports XIP for romstage utilize it.
This removes the double link steps with the cbfstool
locate and add-stage sandwich.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I1ec555f523a94dd4b15fe8186cbe530520c622c0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11670
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is required the BLOB change Icb7a4f07
"AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)"
This is tested on Bettong Alfa(DDR3) and Beta(DDR4). Both of the
boards can boot to Windows 8.1. PCIe slots, USB and NIC work.
Change-Id: Ibe141c16f8f9eac2adc5d5f45a1f354fb2a7f33c
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11148
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
This is required the BLOB change I67817dc59
AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1).
This is tested on Olive Hill Plus. The board can boot to Windows 7.
PCIe slot, USB and NIC work.
Change-Id: I605df26b61bdffabd74846206ad0b7bf677ebed1
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11225
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Trap handling code was bugged in that it loaded in the wrong stack
pointer, overwriting the space the processor uses to talk to its host
for doing device requests. Fix this issue, as well as add support for
handling misaligned loads the same way we handle misaligned stores.
Change-Id: I68ba3a114b7167b3212bb0bed181a7595f0b97d8
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11620
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Recently qemu stopped doing a basic lapic setup and expects the
firmware to handle this properly (like on real hardware). So
let's do that so coreboot works properly on qemu 2.4+.
Here is the qemu commit message for the change:
<quote>
commit b8eb5512fd8a115f164edbbe897cdf8884920ccb
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Mon Apr 13 02:32:08 2015 +0300
target-i386: disable LINT0 after reset
Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long gone
and therefore this hack is no longer needed. Since it violates the
specifications, it is removed.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Message-Id: <1428881529-29459-2-git-send-email-namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
</quote>
Change-Id: I022f3742475d3f3477fc838b1e2bce69287b6b8e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/11611
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This change was sitting in my git index, and I
failed to push it in the original patch.
Change-Id: If6f49c3c2b7908f93a99c23a80536ad5937959c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11622
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current endian API support in coreboot doesn't follow
any known API that can be shared in userland as well as coreboot
proper. To that end provide big and little endian helper functions
that can be used in code that can be shared within coreboot proper
and userland tools.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi
Change-Id: I737facab0c849cb4b95756eefbf3ffd69e558b32
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11618
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
FSP has some unique attributes which makes integration
cumbersome:
1. FSP header files do not include the types they need. Like
EDKII development it's expected types are provided by the
build system. Therefore, one needs to include the proper
files to avoid compilation issues.
2. An implementation of FSP for a chipset may use different
versions of the UEFI PI spec implementation. EDKII is a
proxy for all of UEFI specifications. In order to provide
flexibility one needs to binding a set of types and
structures from an UEFI PI implementation.
3. Each chipset FSP 1.1 implementation has a FspUpdVpd.h
file which defines it's own types. Commonality between
FSP chipset implementations are only named typedef
structs. The fields within are not consistent. And
because of FSP's insistence on typedefs it makes it
near impossible to forward declare structs.
The above 3 means one needs to include the correct UEFI
type bindings when working with FSP. The current
implementation had the SoC picking include paths in the
edk2 directory and using a bare <uefi_types.h> include.
Also, with the prior fsp_util.h implementation the SoC's
FSP FspUpdVpd.h header file was required since for providing
all the types at once (Generic FSP 1.1 and SoC types).
The binding has been changed in the following manner:
1. CONFIG_UEFI_2_4_BINDING option added which FSP 1.1
selects. No other bindings are currently available,
but this provides the policy.
2. Based on CONFIG_UEFI_2_4_BINDING the proper include
paths are added to the CPPFLAGS_common.
3. SoC Makefile.inc does not bind UEFI types nor does
it adjust CPPFLAGS_common in any way.
4. Provide a include/fsp directory under fsp1_1 and
expose src/drivers/intel/fsp1_1/include in the
include path. This split can allow a version 2,
for example, FSP to provide its own include files.
Yes, that means there needs to be consistency in
APIs, however that's not this patch.
5. Provide a way for code to differentiate the FSP spec
types (fsp/api.h) from the chipset FSP types
(fsp/soc_binding.h). This allows for code re-use that
doesn't need the chipset types to be defined such as
the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Change-Id: I894165942cfe36936e186af5221efa810be8bb29
Reviewed-on: http://review.coreboot.org/11606
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
RISCV requires the bios/bootloader to set up an interface by which it
can get information about memory, talk to host devices, etc. Put
implementation for spike in
src/mainboard/emulation/spike-riscv/spike_util.c, and
src/arch/riscv/trap_handler.c
Change-Id: Ie1d5f361595e48fa6cc1fac25485ad623ecdc717
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11368
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Execution in supervisor level code in RISCV requires early setup of
virtual memory. Add initialization calls in
src/arch/riscv/virtual_memory.c to implement the required page table
setup, and helper functions to use when jumping to the payload correctly
in riscv.
Change-Id: I46e080e0ee8dc13277d567dcd4bf0f61a4507b76
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11369
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... the configuration is handled further below in the file by virtue of
select DRIVERS_UART_8250MEM
Change-Id: Ie5481d23cd3ac3561958fd100bd05c0e4b03ce00
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Move some remaining ACPI init code to the SOC instead of being
done in each mainboard:
- acpi_create_gnvs is now a local function
- add a weak acpi_mainboard_gnvs() that can be used for mainboards
to override or set additional NVS
- add acpi_fill_madt() function for skylake
- remove acpi_create_serialio_ssdt() function as it is unused
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I52225e8d38ed846c29d44872e3f4d6ebaf4a7e52
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c717bb418a0cb6002582572632e42b44b473f718
Original-Change-Id: I0910ac8ef25de265ae1fde16b68f6cbacedb4462
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297800
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11581
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the acpi_tables.c functions so these functions can move to
SOC init code. The file itself is included by x86/arch code and
must exist for the build to succeed.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: Ia9657f4a39c30ed7a0fd7ca4815bb2614f049911
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93ae87f2429af5cb9d497f8b5ef8b8dffe370df4
Original-Change-Id: Ifc2f64dc1693e7bd3f5a43144d84ff033b2cfe8b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297759
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11580
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the acpi_tables.c functions so these functions can move to
SOC init code. The file itself is included by x86/arch code and
must exist for the build to succeed.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I18e6a0be5eac053598b613b30b622c4963417919
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: af04eb112adf58578c8d2c9d3d182d4c2024abb2
Original-Change-Id: Ibe026d493c25d771357ea39e4b956629fbb799ac
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297758
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11579
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove thermal.h as it is not used by this board.
Remove functions from acpi_tables.c so they can move to SOC.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-sklrvp coreboot (does not compile due to GPIO changes)
Change-Id: I934fcc451a722f853034c0970074ee3259cc704f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7e3b5c0ed8295091d3d5761b8456f3c13c6bd8bc
Original-Change-Id: If855f598e895e38c58657af17130158b2f73de81
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297757
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11578
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Read and print the board ID if it is enabled in the mainboard.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I9d50089242b3a2f461dff2b1039adc8f0347179e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f245854b30c40eda38453c1b0ae5d3b8b18c010f
Original-Change-Id: Ifbd7c2666820ea146dc44fbc42bfe201cb227ff6
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297756
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11577
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Clean up the intel/kunimitsu mainboard code to match the code
and cleanups in glados. Many of these are trivial changes that
do not impact things in a meaningful way but will make it easier
to diff the code and keep the mainboards in sync.
- use relative path for mainboard includes to make porting easier
- fix trivial style issues to match glados so diffs are clean
- pull GPIO configuration into gpio.h and use from there
- remove thermal.h as it is not used on this board
- make info message BIOS_INFO instead of BIOS_ERR
- add support for SPD manufacturer and part number in SMBIOS
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I64a053bcec0e0ff25a57f65659f391ab64d9a11a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e47f0fd3e00a665f07098c7ea0018d51b105d1be
Original-Change-Id: Ib787f3ccc63115de48c4d608ca2bd81b58d24b6c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297752
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11576
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Select the EC PD and software sync kconfig options so they are
supported by the mainboard and call the EC early init function
to reboot into RO in recovery mode.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I48316df99b796c568c2481c72588b41f7147bec0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c7507470f82848062bc98da809d3c5fe1ca31998
Original-Change-Id: I822aac9c24718f226819e5d3fcc82a4024b7c5a7
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297751
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11575
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Select the BOARD_ID_AUTO kconfig option to have the coreboot
tables populated with the board ID and print it early in
romstage as well. Also clean up the code for it.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I90bd85ef14543717287cbeaaab77e6c54b94df97
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1fed7de4a0650a497a240b091fd2eb99d59e1433
Original-Change-Id: I82e9d17ab618b1aae1fd874d9247b7d52b42334d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297750
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11574
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for reading board id and populating it in the
coreboot tables so it is exposed to payloads.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=boot on glados and look for reported board ID
Change-Id: Iba93a913b67e3b3230aded289c2e25585dec1195
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 472cb7bc84136a1a8b284d661868e64eca4ec004
Original-Change-Id: I478dc0b2f96310b7adbd84701e70598a57306628
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297746
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11570
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Add ACPI code for DPTF support with placeholder thresholds
- Do not have custom PDL for mainboard
- Do not have enable charger control for DPTF as there is
already a complicated charge profile in the EC. We may still
want to enable this but it would need to be tuned to work
well with the EC profile.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I8cd2e0ea9c322ea92c101995e8e706f063428a45
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 55d3614441d6701a6d6f0f9d1ade94364ef2594a
Original-Change-Id: Ie4587572742d3bcdba7c008fc195213ac50c9d9e
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297745
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11569
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- romstage.c is using gpio_configure_pads so it should really
include soc/gpio.h instead of relying on it to come from "gpio.h"
- consistent formatting of array initializers in pei_data.c
- remove pei_data->ec_present flag as this is unused in skylake
- fix printk level in spd/spd.c to be BIOS_INFO instead of BIOS_ERR
- clean up acpi_slp_type usage in ec.c, remove unnecessary post
codes, and cleaner console output message.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I0f76a560dc2c4197e66999752c52573ff0278430
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 67c29f900b7709b73bd0d1e0da26f96cca32828b
Original-Change-Id: Ia2a320acf879fa85e9f6b06265cfe38e50e51e46
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297744
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11568
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The constants defined in thermal.h are never used since there
is no defined thermal zone. Remove it to result in less code
to worry about in board ports.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: Idb716b47875b20e2110741ae9c154cc52307fbcf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01be180b14b5381a8d339dab6c28428c7ac40c10
Original-Change-Id: Ibb710abc301b18d5632f4e01765ea0374b2fe787
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297743
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11567
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To make it easier to port glados to a new board name change
the include headers to use relative path name instead of
including the mainboard name.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I6d184adab5b6b2df970ddd3998d3413f1330c12e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 11dd6b73f298cf4867f4a089478132d5e543ea90
Original-Change-Id: Ia8de127fb176784acbbee975e8b950f8c9824c5c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297742
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11566
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This will help development activity. Default GPIO print settings is
disable, need to set gpio_debug = 1 to get GPIO MMIO dump.
BUG=None
BRANCH=None
TEST=build coreboot and boot on Kunimitsu.
Change-Id: I70c0a7bee1593cbc8e9fe1599f45bb50e3fc0f42
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 19102612ea40184307ecb0ce8b165b5b989f6911
Original-Change-Id: I4ea6349866c108382de9787bb9ed09fc78d9c770
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/296280
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11552
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a parameter to find_fsp which is the image base address. Adjust the
fake stack in cache_as_ram.inc to pass in the read-only FSP image base
address. In fsp_notify, pass in the read-only FSP image base address
when the FSP header pointer is NULL. In find_fsp, validate the FSP
binary image starting from the specified image base address.
BRANCH=none
BUG=None
TEST=Build and run on Skylake
Change-Id: Iac43c8aac8491390479af551765b514ca919928a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 592dae53f3b32694190cc5cb0fa6ca94df68aa95
Original-Change-Id: I7d6a415458a81f3b6bcdcfc9a90eceb2ac22144e
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/295593
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11545
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Select the EC PD support in kconfig and call the EC early init
code that will reboot into RO for recovery mode.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=boot on glados in recovery mode
Change-Id: Ifa1e2afd91a247c3830d8e705d9d34fb02239fe4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 135ef6e0e2c4864be1c25a9761e04cfe17aec51e
Original-Change-Id: Iac8c092453bfbd94210462be0b377fb77410941d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297749
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11573
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the new kconfig entry to select the EC PD chip and have it
be rebooted before the EC automatically insetad of being done
manually by the board.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-samus coreboot
Change-Id: I9e7baffec500a83af1fcf9b1e43d418489172918
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 53b086725d9d595e8eff7e1e35b9ba8db17ca199
Original-Change-Id: I9c9a7dd2ba2b78d681b448839f2c5d15ba9dfe60
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297748
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11572
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a kconfig entry to indicate that a board has a PD chip and
try to put it in RO mode before the EC during early init.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I170271de9b929fcb73d6b0e09171385a6d23f153
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 17e2d13261f4e35a8148039e324e22ec1da64b3c
Original-Change-Id: I44eed5401beb1dc286e316cf0cc958da791580a5
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297747
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11571
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- glados has more thermal sensors that could be used so add
another entry in the DTPF thermal sensor ACPI code.
- fix indentation block in cpu.asl.
- declare \_SB.MPDL as external (it is already CondRefOf)
so it does not need to be present in mainboard config if
the mainboard does not want to override the default.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I1afe7013a24ee1215f5e968e25594f746bbdd17c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8d357437d06349039a94869b088c3c50b32933c0
Original-Change-Id: Ie87d52e735bf930a003e525cf1918789920922a5
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297335
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11558
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Clean up the formatting in various ASL files and remove
unused and/or incorrect field definitions.
Add back the methods to set the USB power in S3 field
in NVS as it is called by the chromium kernel at boot and
is currently complaining that the method is not found.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I9726fb337bf53fa7dce72c5f30524b58abb4cab6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3a47eeba2792c3abed07be175034c709dbf60879
Original-Change-Id: I8e8388c9b834fd060990f8e069929ba829e29ab6
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295952
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11539
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Previously there were 2 paths in linking ramstage. One was used for
RELOCATABLE_RAMSTAGE while the other was fixed location. Now that
rmodtool can handle multiple secitons for a single proram segment
there's no need for linking ramstage using lib/rmodule.ld. That
also means true rmodules don't have symbols required for ramstage
purposes so fix memlayout.h. Lastly add default rules for creating
rmod files from the known file names and locations.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Inspected ramstage.debug as well as rmodules
created during the build.
Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11524
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
To reduce file clutter merge romstage.ld and ramstage.ld
into a single memlayout.ld. The naming is consistent with
other architectures and chipsets for their linker script
names. The cache-as-ram linking rules are put into a separate
file such that other rules can be applied for future verstage
support.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and dmp/vortex86ex.
Change-Id: I1e8982a6a28027566ddd42a71b7e24e2397e68d2
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of having separate <stage>.ld files in src/lib
one file can be used: program.ld. There's now only one
touch point for stage layout.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I4c3e3671d696caa2c7601065a85fab803e86f971
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking ramstage. The last piece to align x86 is
to use arch/header.ld and the macros within memlayout.h
to automaticaly generate the necessary linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I012c9b88c178b43bf6a6dde0bab821e066728139
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11508
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Though coreboot started as x86 only, the current approach to x86
linking is out of the norm with respect to other architectures.
To start alleviating that the way ramstage is linked is partially
unified. A new file, program.ld, was added to provide a common way
to link stages by deferring to per-stage architectural overrides.
The previous ramstage.ld is no longer required.
Note that this change doesn't handle RELOCATABLE_RAMSTAGE
because that is handled by rmodule.ld. Future convergence
can be achieved, but for the time being that's being left out.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards.
Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The current way the XIP address of romstage is calculated is by
doing a 'cbfstool locate' using a bin file of romstage linked
at address 0. That address is then used for re-linking romstage at
the address spit out by cbfstool. Currently, the linker actually
sets minimum alignment on the text sections as 32 bytes, but it
doesn't actually honor that value. Instead, provide a minimum
alignment for romstage so as not to fight the linker.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built asus/kfsn4-dre. Confirmed ROMSTAGE_BASE == gdtptr.
Change-Id: Id6ec65d257df9ede78c720b0d7d4b56acfbb3f15
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are cases where rules.h can be pulled in, but the
usage is not associated with a particular stage. For
example, the cpu/ti/am335x build creates an opmap header.
That is a case where there is no stage associated with
the process. Therefore, provide a case of no ENV_>STAGE>
being set.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: Ia9688886d445c961f4a448fc7bfcb28f691609db
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11513
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The most common payloads do not need this set, so optimize for the
common case.
Change-Id: I2e5b68d74e9b91b41bbbcffc17d31d5c1bb38fd4
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8599
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The LAPIC_MONOTONIC_TIMER symbol doesn't do anything in the code
unless UDELAY_LAPIC is selected. Since this chip uses UDELAY_TSC,
LAPIC_MONOTONIC_TIMER generates a Kconfig warning and should be
removed.
Change-Id: I5caa60ca7ab9a24d25c184c85184f9492b453706
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11342
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Now that the only source of ELF sections for romstage are
from directly included .inc files or ROMCC generated inc
files the subsection globs can be removed. i.e. Remove
.rom.data.* and .rom.text.* listings. Lastly, put the
.rom.data section directly after the .rom.text. They
are by definition read-only and they are generated from
the same place.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Spot checked !ROMCC and ROMCC boards. Confirmed
only .rom.text .rom.data sections exist.
Change-Id: Id17cf95c943103de006c5f3f21a625838ab49929
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11505
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system was previously determining the flow
of the romstage code by the order of files added to
the crt0s make variable. Those files were then
concatenated together, and the resulting file was added
to the build dependencies for romstage proper.
Now romstage.S is added that can be built using
the default object file rules. The generated
romstage.inc is pulled in by way of an #include in the
newly added romstage.S.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards. compared
readelf -e output.
Change-Id: Ib1168f9541eaf96651c52d03dc0f60e2489a77bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11504
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, the x86 romstage build process was unconditionally
creating a romstage.inc and adding it to crt0s. This step is
inherently not necessary in the !ROMCC case becaue the romstage.inc
was created by the compiler outputting assembler. That means
MAINBOARDDIR/romstage.c is truly a C environment that requires
some sort of assembler stub to call into (cache_as_ram.inc from
the chipset dirs). Therefore, remove this processing. The result
is that MAINBOARDDIR/romstage.c can use the normal build steps
in creating an object and linking. The layout of romstage.elf
will change but that's only from a symbol perspective.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built multitude of boards. Compared readelf -e output.
Change-Id: I9b8079caaaa55e3ae20d3db4c9b8be04cdc41ab7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11503
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system was previously determining the flow
and linking scripts bootblock code by the order of files
added to the bootblock_inc bootblock-y variables.Those
files were then concatenated together and built by a myriad of
make rules.
Now bootblock.S and bootblock.ld is added so that bootblock
can be built and linked using the default build rules.
CHIPSET_BOOTBLOCK_INCLUDE is introduced in order to allow the
chipset code to place include files in the path of the bootblock
program -- a replacement for the chipset_bootblock_inc
make variable.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards.
Change-Id: Ida4571cbe6eed65e77ade98b8d9ad056353c53f9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11495
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no reason defining another class compiler which
overrides the first one. The microcode files are just
built into a binary and added to cbfs. There's no reason to
change compilers.
Change-Id: Icb47d509832e7433092a814bad020f8d66f2a299
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11596
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
This changes the API to rkclk_configure_cpu() such that we can pass
in the desired APLL frequency in each veyron board's bootblock.c.
Devices with a constrainted form facter (rialto and possibly mickey)
will use this to run firmware at a slower speed to mitigate risk
of thermal issues (due to the RK808, not the RK3288).
BUG=chrome-os-partner:42054
BRANCH=none
TEST=amstan says rialto is noticably cooler (and slower)
Change-Id: I28b332e1d484bd009599944cd9f5cf633ea468dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d10af5e18b4131a00f202272e405bd22eab4caeb
Original-Change-Id: I960cb6ff512c058e72032aa2cbadedde97510631
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297190
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11582
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CFIO 139 and CFIO 140 are consuming ~5 during stanndby. The reason
for this leakage is internally it is configured to 1K PU. So there
is leakage of ~2mW in standby. Total impact ~2.5 mw in Srandby.
Configure these CFIOs as tristate for ~5mW power saving at platform
level.
BRANCH=none
TEST=PnP Team to verify that the CFIO's are tri-stated.
Change-Id: I6d78d2ccc08167b2cd6fc3405cfcb5c69a77d4b8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f11eb98cb36c504dfebe6f0fa53e9af120d21f24
Original-Change-Id: Ib309ad0c6abffa4515fdf2a2f2d9174fad7f8e8d
Original-Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Original-Signed-off-by: Ravishankar Sarawadi <ravishankar.sarawadi@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292863
Original-Commit-Ready: Rajmohan Mani <rajmohan.mani@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11556
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Having no supplied printk level makes this info message
printed at all levels and so it shows up when booting with
DEFAULT_CONSOLE_LOGLEVEL=3.
BUG=chrome-os-partner:40635
BRANCH=none
TEST="USE=quiet-cb emerge-glados coreboot"
Change-Id: I6c52aafbe47fdf297e2caeb05b4d79a40a9a4b9d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e6cffc6d5a9fcda60a04f8a31f2b2ffe4b620c77
Original-Change-Id: Ie6715d15f950d184805149619bebe328d528e55a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297336
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11559
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch removes a lot of code duplication between the virtually
identical Veyron Chromebook variants by merging the code into a single
directory and handling the different names solely within Kconfig. This
also allows us to easily add all the other Chromebook variants that have
only been kept in Google's firmware branch to avoid cluttering coreboot
too much, making it possible to build these boards with upstream
coreboot out of the box.
The only effective change this will have on the affected boards is
removing quirks for early board revisions (since revision numbers differ
between variants). Since all those quirks concerned early pre-MP
revisions, I doubt this will bother anyone (and the old code is still
available through the Google firmware branch if anyone needs it). It
will also expand a recent fix in Jerry that increased an LCD power-on
delay to make it compatible with another kind of panel to all boards,
which is probably not a bad idea anyway.
Leaving all non-Chromebook boards as they are for now since they often
contain more extensive differences.
BRANCH=None
BUG=None
TEST=Booted Jerry.
Change-Id: I4bd590429b9539a91f837459a804888904cd6f2d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10049a59a34ef45ca1458c1549f708b5f83e2ef9
Original-Change-Id: I6a8c813e58fe60d83a0b783141ffed520e197b3c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296053
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11555
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Set DISB inside romstage right after successful mrc init such that
any reset events afterwards can take fast boot path and in turn
achieve better boot performance
BRANCH=NONE
BUG=chrome-os-partner:43637
TEST=Built for kunimitsu and tested DISB is set correctly and fast
boot path is taken.
Change-Id: I230ff76287f90c5d3655a77bbaca666af37c4aae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7bdc6900012c99187bb90904df18c2b3f9e52c61
Original-Change-Id: Ie08b4a4f29a7c5cb47e508bc59a5e95f8e36fa00
Original-Signed-off-by: Dhaval Sharma <dhaval.v.sharma@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/295509
Original-Commit-Ready: dhaval v sharma <dhaval.v.sharma@intel.com>
Original-Tested-by: dhaval v sharma <dhaval.v.sharma@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11550
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove devicetree.cb settings that do not apply to skylake so
they can be removed from chip.h and clean up the pci device
comments and add missing devices.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-sklrvp coreboot
Change-Id: I232bd62853685bdcda771e3cbaba2d8ee7437b81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a22e1fa56c68b06192acbeeb5c76862d84b8f509
Original-Change-Id: I61f0581069d87ab974b0fffa6478b44a71bdd69b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297337
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11560
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The devicetree.cb compiler can't handle C style /**/ comments,
they need to be shell-style #. Due to a last minute formatting
change in my commit to enable USB ports this broke the kunimitsu
build.
BUG=chrome-os-partner:44662
BRANCH=none
TEST=emerge-kunimitsu coreboot
Change-Id: I7a77f0f51345f779fcae43338cdc078bc91bb51c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6454b377f865ec3d4e426fce3259f4df5d513ef5
Original-Change-Id: I19bde397018890db37257b55d0481e0c9f3a41f2
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296302
Original-Tested-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11554
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The devicetree.cb compiler can't handle C style /**/ comments,
they need to be shell-style #. Due to a last minute formatting
change in my commit to enable USB ports this broke the glados
build.
BUG=chrome-os-partner:44662
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I46ee4e5a94d61eefbd2c9a1ba3cafcb6a9e7d71b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8fa92f77b3ef13ede1029292d886351ab5ed87d2
Original-Change-Id: Ibff02a4fd6132def81006a2c6502d34bd4b72823
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296301
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11553
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable only the USB ports that are connected on-board or to an
external port, all others will be disabled.
BUG=chrome-os-partner:44662
BRANCH=none
TEST=emerge-kunimitsu coreboot, change verified in schematic but not tested
Change-Id: I909a6fab553bba829349dd08fa9cc3f26e5adeb2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1b0ce28d093e3b12273d7e0f56b47fb5b13d712f
Original-Change-Id: I0c4b7de6e559595efa97d756e43f8398feccdffd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296036
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11549
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable only the USB ports that are connected on-board or to an
external port, all others will be disabled.
BUG=chrome-os-partner:44662
BRANCH=none
TEST=build and boot on glados, ensure expected USB ports still work
Change-Id: I8c999e3b17478effc39cf078f8420f63413d091b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b86268c70f86991f8c2cdd6763f8efe2ce7f9163
Original-Change-Id: I2fce2c401d07639892c4a0c01527173d3f0b2557
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296035
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11548
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The USB port enable/disable settings were never getting applied to
the UPD configuration and so were not getting used by FSP.
BUG=chrome-os-partner:44662
BRANCH=none
TEST=build and boot on glados
Change-Id: I13d4eb901215308de4b59083339832d29ce0049f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4fd83caa8087cc349fa933eafac98c2563f501a4
Original-Change-Id: Ia5fa051782eeb837756a14aecb4aa626d25b2bdb
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/296034
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11547
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove dead code not called by any part of coreboot.
BRANCH=none
BUG=None
TEST=Build and run on skylake
Change-Id: I3d457a196d12d03340bceb444d1d6c95afef13df
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 58ea135813afeef773f37023fda58f36d544beef
Original-Change-Id: Id8f4591f20d41f875348c6583618bbcaaf9d9a3a
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/294953
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11544
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's no need to add any typedefs nor guard code with
ENV_ROMSTAGE. The linker will garbage collect unused functions.
Additionally there were a few errors in the code including
the operation mask wasn't wide enough to clear out old operations
as well as component size decoding was incorrect.
The big difference in the code flow is that the operation
setup is now in one place. The stopwatch API is also used in
order to not open code time calculations.
BUG=chrome-os-partner:42115
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted. Suspended and resumed. event log is populated
for all.
Change-Id: I0ddd42f0744cf8f88da832d7d715663238209a71
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9893fe309104c05edfb158afda6bb029801c0489
Original-Change-Id: I6468f5b9b4a73885b69ebd916861dd2e8e3746b6
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295980
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11543
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
I missed this in code review. This should be under the soc
directory.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built glados.
Change-Id: Ia018c20f97f267b8f7592b2459d10eafe5ec7159
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c081ed6de46605b7d0a72962ac2a041c470b12c
Original-Change-Id: Ic3938fe5d71bd24a395304cfabe40eff48bc4a40
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295239
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11542
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The spi_init() routine needs to be called in all boot paths to allow
writes to the SPI part. The reason is that the write enable is done
in spi_init(). Moreover, this is also required for a writing a firmware
update after a resume.
BUG=chrome-os-partner:42115
BRANCH=None
TEST=Built and booted glados. Suspended and resumed. Eventlogs show
up in resume path.
Change-Id: I187baa940bb45ef90ab82e67c02f13d8855d364e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8813ab227395cfcba46ad4109730a1eb5897e538
Original-Change-Id: Ida726fc29e6d49cd9af02c4e57125e09f2599c36
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295238
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11541
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The timer_monotonic_get() function wasn't being compiled for
romstage. To simplify the implementation don't keep track of
partial microsecond ticks and just return the MSR value divided
by 24 (24MHz clock).
BUG=chrome-os-partner:42115
BRANCH=None
TEST=Build and booted glados. Used monotonic timers in romstage
in subsequent patches.
Change-Id: I8294c74abe09947fb4438bf5c1d0fc5265491694
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6d60ef204fc92c26748ab57d4ff37830cd8dc664
Original-Change-Id: Ibdb6b9e20b9f2d48ff0f8a8c782f5c1f7ddde4f7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295237
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11540
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Switch the GPIO controller to use the PCR functions that are
defined in pcr.asl.
Have the default memory regions declare a size of zero and
be fixed up in the _CRS in order to fix compile issues on
some versions of iasl.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: Ic82fcb00285aeb2515e24001ef69a882c3df1417
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: be24d9ccd9db62ca694f3a67436af25a73f59c5a
Original-Change-Id: I13acd891427f467e289d5671add5617befef4380
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295951
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11538
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Remove the old workarounds for XHCI from broadwell
- Add PMC device to expose bits needed for XHCI workarounds
- Implement the new workarounds for XHCI, the first will set
a bit in the XHCI MMIO and the second will send a message
to the PMC if a bit is set indicating the workaround is available.
- Clean up the HS/SS port defines and remove unnecessary
methods to determine the port count since we only support SPT-LP.
BUG=chrome-os-partner:44622,chrome-os-partner:44518
BRANCH=none
TEST=build and boot on glados, verify that D0 and D3 can be
made to work (by disabling unused USB and the misbehaving camera)
Change-Id: I535c9d22308c45a3b9bf7e4045c3d01481acc19c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a945f8bc2976d57373be2305c5da40a5691f1e88
Original-Change-Id: I7a57051c0a5c4f5408c2d6ff0aecf660100a1aec
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295950
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11537
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Skylake moves back to having SerialIO devices be enumerated
as PCI devices instead of putting them all in ACPI mode.
There is currently no code that populates the device_nvs
fields so all the ACPI code to support that is dead.
Additionally because it contains _PS0/_PS3 methods that
causes the kernel to not use the standard PCIe PME handlers
and results in confusing messages at boot about not being
able to transition to a non-D0 state from D3.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=build and boot on glados and ensure I2C devices work
Change-Id: Id0112830211707ba3d67d4dda29dd93397b5b180
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f7dddad9c2269abd292346e35ebd0b4ca2efe72b
Original-Change-Id: Ie5e40b5d73cd3a4d19b78f0df4ca015dccb6f5f6
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295909
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11536
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the storage controller devices out of serialio.asl
and into a new scs.asl file and implement the power
gating workarounds for D0 and D3 transitions.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I43081e661b7220bfa635c2d166c3675a0ff910d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e0c67b386974dedf7ad475c174c0bc75dc27e529
Original-Change-Id: Iadb395f152905f210ab0361121bbd69c9731c084
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295908
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11535
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the itss.asl code that was exporting PIRQ routing
control registers into irqlinks.asl and use the PCR access
methods to find the appropriate address. At the same time
clean up the code in irqlinks.asl to follow formatting rules.
Also now that the GPIO code in itss.asl is unused the file
can be removed.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I1af7d730542fd0e79b9f3db9f0796e7c701c59e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 39a96063d01d00ab768db1c723f78b5af9ed6513
Original-Change-Id: Iafa03c276cb276ec8c00c24ed2dba48d0dc9612b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295907
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11534
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the now unused RCBA base and size from iomap.h
and fix a trivial typo that doesn't seem to get used
anywhere.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emege-glados coreboot
Change-Id: If95dd2ee3f4a8dd0a6a7cf996aef8f19f27ddc48
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ee7b1a8a75a9e9dc191c16ddc32b6a38acec398c
Original-Change-Id: I0c49803d47105c3c55121caedaffaa249c4f0189
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295906
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11533
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the PCR Port ID for the storage controllers and
reformat to put the PCR PIDs in increasing order.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I0f0144ef79d3691fa120dafc9a31d2a681bf2a28
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 208242f58759899f17e52593ed6e1dd631334ac9
Original-Change-Id: I942bcf01b0576136c0039aa62f38fe7f3454ba8a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295905
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11532
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are a few places in ACPI that touch PCR registers,
either to read a value or to set some magic bits.
Expose some functions for this that will keep all the PCR
access in one location instead of spread throughout the code.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: Iafeb3e2cd8f38af10d29eaaf18f2380c5651fe6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e78b2801fbc5c00ba452ae5e4ecb07c3e23bf6c1
Original-Change-Id: I2e4d491157f7ac6d2ebc231b11661c059b4a7fa0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295904
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11531
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Clean up the code in pch.asl:
- move all the C header includes into here instead of duplicated
in various ASL files included from here
- move the trap field definition into platform.asl with the method
- alphebetize the includes
- move gpio.asl include into pch.asl
- remove duplicate irqlinks.asl include from lpc.asl
BUG=chrome-os-partner:44622
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I51b1c5286fc344df6942a24c1dea71abf10ab561
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3ee9c4afa031191d275f0d3d40b2b15b85369b2f
Original-Change-Id: I3bae434ad227273885d8436db23e17e593739f77
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295903
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11530
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the code for PCIE _PRT entries to use an actual root
port number from the device instead of NVS that was never
initialized from zero.
BUG=chrome-os-partner:44622
BRANCH=none
TEST=build and boot on glados with pci=nomsi to ensure interrupts work
Change-Id: I76ff07d2bf7001aed504558d55cca9e19c692d7e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d43392199ec5f37150f2b13732924c47b8dc830c
Original-Change-Id: I1132f1dc47122db08d1b798a259ee9b52a488f5e
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295902
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11529
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The platform ID is an 8 character ASCII string, so our config should
take it in as a string, rather than a set of two 32-bit integers.
Change-Id: I76da85fab59fe4891fbc3b5edf430f2791b70ffb
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11465
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Now that cbfstool supports file alignment, we can use the conveniently
available <filename>-align handler, and remove the need to have a
separate rule in src/Makefile.inc just for adding the microcode.
We can also get rid of the layering violation of having the
CONFIG_PLATFORM_USES_FSP1_0 symbol in a generic src/cpu/ makefile.
Note that we still have a layering violation by the use of the
CONFIG_CPU_MICROCODE_CBFS_LOC symbol, but this one is acceptable
for the time being.
Change-Id: Id2f8c15d250a0c75300d0a870284cac0c68a311b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11526
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We don't build-test with native VGA init, so if the code is broken by
a commit, we won't see it when it's guarded by #ifdefs. This has
already happened in the past. Instead of gurading entire files, use
the IS_ENABLED() macro, and return early. This at least enables us to
build-test the code to some extent, while linker garbage collection
will removed unused parts.
BONUS: Indenting some blocks also makes the difference between
framebuffer init and textmode init clearer.
Change-Id: I334cdee214872f967ae090170d61a0e4951c6b35
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11586
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Native VGA init no longer compiles from commit:
* 7dbf9c6 edid: Use edid_mode struct to reduce redundancy
Tested on a single X60 machine.
This patch basically copies 11491 which does
the same for north/intel/sandybridge.
Change-Id: I0663f3b423624c67c2388a9cc44ec41f370f4a17
Signed-off-by: Axel Holewa <mono-for-coreboot@donderklumpen.de>
Reviewed-on: http://review.coreboot.org/11585
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Native VGA init no longer compiles from commit:
* 7dbf9c6 edid: Use edid_mode struct to reduce redundancy
Change-Id: I51a4f4874ce77178cab96651eb7caf2edd862aa2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11491
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The reason for hardcoding the position of the MRC cache was to satisfy
the alignment to the erase size of the flash chip. Hardcoding is no
longer needed, as we can specify alignment directly. In the long term,
the MRC cache will have to move to FMAP, but for now, we reduce
fragmentation in CBFS.
Note that soc/intel/common hardcoding of mrc.cache is not removed, as
the mrc cache implementation there does not use CBFS to find the cache
region, and needs a hardcoded address.
Change-Id: I5b9fc1ba58bb484c7b5f687368172d9ebe625bfd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11527
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
coreboot has no CREDITS file.
Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11514
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit "7dbf9c6 edid: Use edid_mode struct to reduce redundancy" moved
some fields from "struct edid" to "struct edid_mode". Adapt the bochs
and cirrus drivers to that change.
Change-Id: I9ec82a403d0264955d4b72496219036c7775c758
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/11502
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In order to prepare for more unification of the linker
scripts prefix pci_drivers, epci_drivers, cpu_drivers, and
ecpu_drivers with an underscore.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built different boards includes ones w/ and w/o relocatable
ramstage.
Change-Id: I8918b38db3b754332e8d8506b424f3c6b3e06af8
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11506
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The #include path during compilation already has '-I src'.
Don't encode the src part of a path.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built amd/thatcher while compiling romstage.c with C compiler..
Change-Id: If4fb1064a246b4fc11a958b07a0b76d9f9673898
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11512
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Current code written in C is calling a function implemented
in assembly. However, the symbol's visibility is not set
for such usage. Of course this works because MAINBOARDDIR/romstage.c
is being processed into an assembly file currently.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built digitallogic/msm800sev while not changing romstage.c
into an assembly file.
Change-Id: I84c3af0026f3f98bc64af007aa7cc196429f4e5f
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11511
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The BOOT_STATE_INIT_ENTRY macro can only be used in ramstage, however
the current state of the header meant bad build errors in non-ramstage.
Therefore, people had to #ifdef in the source. Remove that requirement.
Change-Id: I8755fc68bbaca6b72fbe8b4db4bcc1ccb35622bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11492
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add support to the Intel common firmware Kconfig and Makefile.inc to
allow the Gigabit Ethernet (GBE) blob to be added to the final
binary.
Change-Id: Id5fab3061874dad759750b67d3339eb8c99a62d6
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10875
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
When building up which files to include in romstage there
were both 'cpu_incs' and 'cpu_incs-y' which were used to
generate crt0.S. Remove the former to settle on cpu_incs-y
as the way to be included.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. No include file changes.
Change-Id: I8dc0631f8253c21c670f2f02928225ed5b869ce6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the Chrome OS boards were directly calling vboot
called in some form after contorting around #ifdef preprocessor
macros. The reasoning is that Chrome OS doesn't always do display
initialization during startup. It's runtime dependent. While
this is a requirement that doesn't mean vboot functions should be
sprinkled around in the mainboard and chipset code. Instead provide
one function, display_init_required(), that provides the policy
for determining display initialization action. For Chrome OS
devices this function honors vboot_skip_display_init() and all
other configurations default to initializing display.
Change-Id: I403213e22c0e621e148773597a550addfbaf3f7e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11490
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
1. Update hwinfo.hex (add dummy data and update checksums).
2. Delete version.hex from mainboard directory. It can be added
in site-local if needed.
Change-Id: I7af9c4a5f606b96177a8ed4e3edf52535f2f1ec7
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11484
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Drop old incomplete, broken and hardcoded sata.asl properties.
The new sata acpi generator only needs a proper defined device.
Change-Id: Id3eca5551a070dfdd6fa674e1d5b6627e28ab5a7
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9710
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Drop old incomplete, broken and hardcoded sata.asl properties.
The new sata acpi generator only needs a proper defined device.
Change-Id: I2be76097ebd27f2529e3fbbecefd314a0eea3cb0
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9709
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Since more boards are starting to use the EC provided keyboard
backlight interface move the code to a common place and allow
it to get included in mainboards.
Change-Id: I3f307bbce1a96cdd1c8224b1e89a63d6fedef738
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/11478
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the gm45 code, IOMMU is always selected to be enabled. Instead
this patch removes the Kconfig symbol and its dependencies. This leads
to the same effect without the need for the symbol.
The symbol is still used in the K8 code as it's not selected, simply
defaulted to being enabled, and one of the mainboards disables it.
Change-Id: Ibc5939cd1e297d497bf71b1787d852f7cc09a551
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11345
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
This depends on RELOCATABLE_RAMSTAGE, and shouldn't be selected if
its dependency is not activated.
Change-Id: I8e7efc3f87e105715fe3377ed306891f0d209979
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11473
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As pistachio already provides timer_monotonic_get() let the
generic timestamp_get() use that instead of having around
another implementation of timestamp_get().
BUG=chrome-os-partner:44669
BRANCH=None
TEST=None
Change-Id: Iaa6db49f0055b7c2ef116f41453f838093e516e0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11469
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The src/lib/timestamp.c already has an implementation using
timer_monotonic_get() for timestamp_get(). Use that instead
of duplicating the logic.
BUG=chrome-os-partner:44669
BRANCH=None
TEST=None
Change-Id: If17be86143f217445bd64d67ceee4355fa482d39
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11468
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Change-Id: Ieaed5cf76c6f0a6a121e6add731d5c1e1528dfc7
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11375
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Without this change, if one USB3 device is attached when
the board is power up, the USB3 port can not be used.
Change-Id: I98628975000c7d56b1540c2b321d580ace1ef70e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11377
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Idf28faa26a7ea5e94495af5ff027309df444766e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11376
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This option was removed in the following commit:
* 80f5d5b fsp1_1: remove duplicate mrc caching mechanism
Change-Id: I08ef4fc6029cc066e4f7b9c82b6b187a9794afdb
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11462
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The #error messages only say that "CONFIG_* must be defined", which
conveys no more information that the compiler or assembler failing
when it encounters an undefined CONFIG_* symbol.
Change-Id: I6058474d4cd454cfc20290650425d379f388abd9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11461
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
After much consideration, and many years of an EXPERT mode sitting
almost completely unused, we've seen that it doesn't work for us.
There is no standard on what constitutes EXPERT, and most of
coreboot's options Kconfig are expert-level.
We even joked that not selecting "EXPERT" should prevent coreboot
from compiling:
@echo $(shell whoami) is not permitted to compile coreboot
Change-Id: Ic22dd54a48190b81d711625efb6b9f3078f41778
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11365
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
This is just wrong. PAYLOAD_SEABIOS tells us nothing about whether
or not the payload will actually be SeaBIOS:
1. PAYLOAD_SEABIOS, but payload changed with cbfstool
2. !PAYLOAD_SEABIOS, but an elf payload was added which is SeaBIOS
et. cetera.
Change-Id: I4c17e8dde20bf21537f542fda2dad7d3a1894862
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11293
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Damien Zammit <damien@zamaudio.com>
mainboard_ec_init() wasn't getting run due to an invalid
Kconfig symbol. This check isn't required as the Kconfig
option for the EC is forced to be enabled, and the function
should always be run.
BRANCH=none
BUG=none
TEST=Rebuilt glados mainboard.
Change-Id: I2c4a33d80533a19b02b83b3aaa6a3386e927f1c7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: edd8c7a0666208b35ee81f57ec2626390958dfb7
Original-Change-Id: I2a92fd28347455c09ecf2119788ca9b6a97a11de
Original-Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295143
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11435
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds the ASL files with the DPTF related settings and the
thermal devices enabled in the SOC. It also enables the DPTF setting
at the global NVS level.
BRANCH=None
BUG=chrome-os-partner:40855
TEST=Built for kunimitsu board. Tested to see that the thermal devices
and the participants are enumerated and can be seen in the
/sys/bus/platform/devices. Also checked the temperature readings of the
cooling devices and the thermal zones enumerated in the /sys/class/thermal.
Change-Id: I8ad044eaf1ad488fb1682097da83b40d2bede414
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 7624eeca19b4f286b30c3d4ac5b44c5e9619c2c7
Original-Change-Id: I0d92ef42cff5567ea6fc566730588802d8549ce0
Original-Signed-off-by: Shilpa Sreeramalu <shilpa.sreeramalu@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293391
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Reviewed-on: http://review.coreboot.org/11430
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch includes the DPTF specific ASL files in the main
DSDT definition and enables the CPU thermal participant device
in the device tree. It also enables the DPTF flag in the global
NVS table.It also adds the ASL settings specfic to the mainboard.
BRANCH=None
BUG=chrome-os-partner:40855
TEST=Built for kunimitsu board. Tested to see that the thermal devices
and the participants are enumerated and can be seen in the
/sys/bus/platform/devices. Also checked the temperature readings of the
cooling devices and the thermal zones enumerated in the /sys/class/thermal.
Change-Id: I5fb28e4480648eab39cc9b13ed55eae1d3db4d42
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 54f7f33a12eb5744d6108e362fa1d078fe838b3c
Original-Change-Id: I82527989919bd4f3c49fb58dfc9463f1c1bd3353
Original-Signed-off-by: Shilpa Sreeramalu <shilpa.sreeramalu@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/284821
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294650
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Reviewed-on: http://review.coreboot.org/11429
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the macro for GPP_E22_IRQ instead of the ACPI code so it
can be removed.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=emerge-sklrvp coreboot
Change-Id: I09bea748fea34072d4f8ad7470d37e423b7f63de
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 89069f5f318329182390cad679511547b7d2a6d5
Original-Change-Id: Iad181b4ce1c557ce8d17645431d8ba6f558bb837
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295171
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11427
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Early(romstage) SPI write protected status read(wpsr) functionality
was broken causing 2 sec timeout issue.Implementing HW Seq based rd
status operation in romstage.
BRANCH=NONE
BUG=chrome-os-partner:42115
TEST=Built for sklrvp and kunimitsu and tested using below command
flashrom -p host --wp-enable [this should enable WP on flash chip]
Read using romstage SPI.c. WPSR=0x80 (CB is reading Bit 7 as locked)
flashrom -p host --wp-disable [this should disable WP on flash chip]
Read using romstage SPI.c. WPSR=0x00 (CB is reading Bit 7 as unlocked)
Change-Id: I79f6767d88f766be1b47adaf7c6e2fa368750d5a
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 4b798c44634581ebf7cdeea76c486e95e1f0a488
Original-Change-Id: I7e9b02e313b84765ddfef06724e9921550c4e677
Original-Signed-off-by: Subrata <subrata.banik@intel.com>
Original-Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/294445
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11423
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is needed to fix error in depthcharge:
src/vboot/util/flag.c:38 flag_fetch(): Don't have a gpio set up
for flag 3.
BUG=chrome-os-partner:44214
TEST=Verify depthcharge prints EC ID on boot up
BRANCH=None
Change-Id: Ia2d88b8427e54e2dc9e6c9abecc95fd7656abb66
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 142b156c72ceedfbd4bf3f54c0cb1128c0fad5a3
Original-Change-Id: I7e7a7d1b92bc1ee2c5ebac8de6946550ddd68a68
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/294715
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11421
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the gpio pad configuration prior to SiliconInit()
in case there are dependencies of the pads being configured
in prior to SiliconInit().
BUG=chrome-os-partner:43522
BUG=chrome-os-partner:43492
BRANCH=None
TEST=Built and booted glados.
Change-Id: I84f8e965bf205a4945b14a63fa8074953750f785
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 5cce5347449f69ac6cf7030ea3b91d3f8b4cc7f9
Original-Change-Id: I18cd33a455d5635a866abb76142cab516b04f446
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294642
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11420
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On proto2 boards the kepler device has its reset line pulled up
to one of its IO rails with a zener in between. This results in the
device not being visible at MemoryInit() time because for some
reason FSP is doing PCIE configuration/probing in that path. Hack
around the broken FSP logic by configuring the pads for kepler's
power and clkreq.
BUG=chrome-os-partner:44326
BRANCH=None
TEST=Built and booted glados. lscpi shows the device on bus 2.
Change-Id: I543eb3ccd3ab5ffacd6efc959e6e2f7a88de78b3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 67f6b57487e8724b469f74870e0083d4e1dac4d2
Original-Change-Id: I7fe4a707f9321b7bdec4b4be729c5d0dcce65f6e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294810
Original-Reviewed-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11419
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Export the proper GPIO for EC_IN_RW so it can be picked up and
used by depthcharge/vboot.
BUG=chrome-os-partner:43072
BRANCH=none
TEST=build and boot on glados P2
Change-Id: I32d338ef424086ec9701900e976bd0dffe4637a0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: dd983c84de0c3b896b20d38438a3285cfcaf7e56
Original-Change-Id: I77f7d3a0c0d733302b81273d96026d39b001ed19
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294712
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11418
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The RMT flag that was attempting to disable saved training to
force a full memory train was happening too late. In testing
I was actually hitting a case where FSP was training every time
but it was not because it was properly being told to.
This moves the check of the RMT flag from devicetree to happen
ealier, before it is actually consumed by romstage_common().
BUG=chrome-os-partner:40635
BRANCH=none
TEST=do both power off+on and warm resets to ensure that FSP
is doing a full memory train every time with RMT enabled.
Change-Id: Icf36e7b1ae20e08f6bc24bf832498d69b37dee92
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: f3fa3846d51dec65f22f018acc8fb8c4d18688a7
Original-Change-Id: I2128b4a24bb8b2c8ddcb792c09b6fb0284d1fda4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294177
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11417
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The previously driven TX state of the buffer was not
being cleared before or'ing in the new value. Fix this
oversight.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados. Also dumped assembly and saw the
masking happen.
Change-Id: I74ea469564d37d6b29e9481b0ea704f04f54ac30
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: d399e8b32b30b8b2275bb6ff8dd24f7d5cfeadda
Original-Change-Id: I341b396af5de20ffeeb2e42066b224dd54251793
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294541
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11416
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
RMT is useless if the memory does not do a full training pass,
and since FSP does not seem to handle that case itself have
coreboot not pass in a valid set of saved training data so FSP
will do a full memory train.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot twice on glados with p2 and RMT enabled
and see it do a full memory train on each boot.
Change-Id: Ia4f29a937e726a5a676f056ce8970086988da5b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: f01e99204409899d4adbaebbe221b0348975cfa6
Original-Change-Id: I0bb193c5f3c9206a67315906745aad96a95b3f74
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294067
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11414
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SOC handler for memory init params is only taking UPD
as an input which does not allow it to use romstage_params.
In addition the UPD input is called params which is confusing
so rename it to upd so romstage_params can be passed properly.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados p2
Change-Id: I414610fee2b5d03a8e2cebfa548ea8bf49932a48
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: db94d6f3e6cad721de2188a136df10ccf66aff6a
Original-Change-Id: I7ec15edd4a16df121c5967aadd8b2651267ec773
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294066
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11413
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The BUNIT controls the policy for read/write access to physical
memory. For the SMRAM range the policy was not allowing dirty
evictions to the SMRAM when the core causing the eviction was not
in SMM mode. This could happen when the SMM handler dirtied a line
and then RSM'd back into non-SMM mode. The cache line was dirtied
while in SMM mode, but when that particular cache line was evicted
it would be silently dropped. Fix this by allowing the BUNIT to honor
writes to the SMRAM range while the evicting core is not in SMM mode.
The core SMRR msr provides the mechanism for disallowing general access
to the SMRAM region while it is not in SMM mode.
BUG=chrome-os-partner:43091
BRANCH=None
TEST=Run suspend_stress_test and ensure there is no hang SMI handler
on suspend-path.
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Change-Id: Ie794aa3afd54b5e21d0d59a2a7388d507f233537
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 9c481ab339b4e5ab063e2c32b1f0a48b521142b2
Original-Change-Id: I3e7d41c794c6168eb2ad4eb047675bdb1728f72f
Original-Reviewed-on: https://chromium-review.googlesource.com/292890
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Hannah Williams <hannah.williams@intel.com>
Original-Tested-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: http://review.coreboot.org/11412
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CBFS_SIZE is living as a mainboard attribute. Because
of the Kconfig include ordering the SoC *cannot* set
the default.
BUG=chrome-os-partner:43419
BRANCH=None
TEST=None
Change-Id: If34e8fd965573fdc7f57b63201dbcb5256e132d6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: a820b11a0aa3b820c79b1f76b15370d969153175
Original-Change-Id: I7ba637e66878f5ae9caedb63fdd37ed7e375224e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289832
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11410
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We don't need the code in romstage, and it saves us a few #ifdefs.
Change-Id: I26d867566f07c7d80890cd01bf055be7497130d3
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It doesn't make sense to die() when printing information. In fact the
die() are protected by DISPLAY_HOBS config option. This can get
confusing, so replace die() calls with printk().
Also since these messages are designed to be informational, keep them
at BIOS_INFO log level.
Change-Id: Id75b9a54f4aea23074a7489d12809cc2da05f1cd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11456
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For some reason fsp 1.1 has a duplicate mechanism for saving
mrc data as soc/intel/common. Defer to the common code as all
the existing users were already using the common code.
BUG=chrome-os-partner:44620
BRANCH=None
TEST=Built and booted glados. Suspended and resumed.
Change-Id: I951d47deb85445a5f010d23dfd11abb0b6f65e5e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Original-Commit-Id: 2138b6ff1517c440d24f72a5f399bd6cb6097274
Original-Change-Id: I06609c1435b06b1365b1762f83cfcba532eb8c7a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295236
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11454
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The code in mrc_cache.c doesn't check for the presence of 'mrc.cache',
and just returns hardcoded value for he location of he MRC cache. This
becomes a problem when there is a CBFS file at the same location,
which can get overwritten. A CBFS file is created to cover this region
so that nothing can be added there.
This has the advantage of creating a build time error if another cbfs
file is hardcoded over the same region.
The default location of the MRC cache is also moved to 4G - 128K to
ensure that it defaults to something within CBFS.
Change-Id: Ic029c182f5a2180cb680e09b25165ee303a448a3
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11440
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Aaron Durbin found that soc/common is already included as a subdir via
the wildcard in Makefile.inc:
subdirs-y += $(wildcard src/soc/*/*)
Since the entire file is protected by CONFIG_SOC_INTEL_COMMON, there
is no problem with including it for every platform. On the other hand,
when it is included by the skylake and braswell makefiles, any rule is
duplicated. As a result fix the braswell and skylake makefiles.
Change-Id: If5bad903c78dbce418852935ee55cdc7162b3b2d
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11439
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This patch adds support to enable a linker workaround to a hardware
erratum on some early Cortex-A53 revisions. Since the linker option was
added very recently, we use xcompile to test whether the toolchain
supports it first. It is also guarded by a Kconfig since only a few
ARM64 SoCs will need this and it incurs a performance penalty.
BRANCH=none
BUG=none
TEST=Turned it on or off for Smaug and confirmed that it (dis)appeared
in verbose make output accordingly.
Change-Id: I01c9642d3cf489134645f0db6f79f1c788ddb00d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 57128785760c4dfa32d6e6d764756443a9323cb7
Original-Change-Id: Ia5dd124f484e38460d75fb864304e7e8b18d16b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294745
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Fix following compilation error.
LINK cbfs/fallback/verstage.debug
/bin/sh: verstage-objs: command not found
/usr/x86_64-pc-linux-gnu/aarch64-cros-linux-gnu/binutils-bin/2.24/ld.bfd.real: warning: cannot find entry symbol stage_entry; defaulting to 00000000000d7000
BRANCH=chromeos-2015.07
BUG=none
TEST=emerge-oak coreboot
Change-Id: I30e4c43625b2d1d076f24e8c2639ce951839661b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 2a8936cdf34d315f580819df682335b2998f044f
Original-Change-Id: I9afd57a5a868a348dff2c66cad0a8a09cdb2e911
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292557
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11402
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Need to save EmcBctSpare2 field to scratch register. Without it,
system may not resume from LP0 suspend.
BUG=chrome-os-partner:43797
BRANCH=none
TEST=able to suspend/resume >30 times on a known failed board
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 6d1623c4c791f79e097193dfbc4bc894ef63e230
Original-Change-Id: I53ebf8c4d4c7cd19827128a84fbd97a377d78ff7
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/294765
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-(cherry picked from commit ce38d902e889068d0068150c9352c2ecdb2f8815)
Original-Reviewed-on: https://chromium-review.googlesource.com/294864
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I2ff21afbe9278413033101877c2581df51913709
Reviewed-on: http://review.coreboot.org/11401
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
GPIO(0, B, 3) and GPIO(7, C, 5) are not actually connected,
GPIO(0, B, 4) is named differently.
BUG=chrome-os-partner:43031
TEST=Rialto should still boot just fine, USB should still work
BRANCH=master
Change-Id: I11879385de6e9b57ac28bcae699333beb5a0d64c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: a66bf1fd73ff8d15d4ec1a8f3602465941285c32
Original-Change-Id: Ib7d2baa6ed1ab38db786eb4d5e77316ad72cbfd4
Original-Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294713
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Without this, the leds would be stuck to whatever the pullup/down states the
pins come with on rk3288.
Ready2_LED, an orange led, is one of the leds in this state.
This might confuse some users thinking there's an error.
Turn all of them on instead.
Later on depthcharge will use the same LEDs to indicate dev mode status.
BUG=chrome-os-partner:44274
BRANCH=master
TEST=Boot firmware without anything else, note all leds on
Change-Id: I5cf19aabd2a59a61699ef491ae11424cf5a0c874
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 2e1a332a5653fb76bbf8fe624274ec64d2b443a5
Original-Change-Id: I4c4e8940dd9cf1ac0301ac00bfc5992ba16e1589
Original-Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294065
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11398
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
only modify the MR3 value, there will always be some mickey not working properly.
After enable ODT, we use many mickey do tests, now functioning properly.
BRANCH=None
BUG=chrome-os-partner:43626
TEST=My mickey now boots up
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 681c169d59f5638d35b777eb2b7543e3b0dd90c8
Original-Change-Id: Ieb2b8a56054f91b6be81260e4c574425fb72fed3
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293324
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Original-Trybot-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-(cherry picked from commit 5397c2f32f5851b9f514b0bd2ae68999a77cabbf)
Original-Reviewed-on: https://chromium-review.googlesource.com/294126
Change-Id: Icb3c839bebebfcae54fc6e96e9958c7020d49eff
Reviewed-on: http://review.coreboot.org/11396
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
do_dcsw_op is coded as a label, it's possible that linker will place
do_dcsw_op on unaligned address. To avoid this situation, we declare
do_dcsw_op as a function. Also explicitly set the 2nd argument of
ENTRY_WITH_ALIGN(name, bits) to 2.
do_dcsw_op:
cbz x3, exit
c103d: b40003e3 cbz x3, c10b9 <exit>
mov x10, xzr
c1041: aa1f03ea mov x10, xzr
adr x14, dcsw_loop_table // compute inner loop address
BRANCH=none
BUG=none
TEST=build and check do_dcsw_op in elf file
Change-Id: Ieb5f4188d6126ac9f6ddb0bfcc67452f79de94ad
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 4ee26b76089fab82cf4fb9b21c9f15b29e57b453
Original-Change-Id: Id331e8ecab7ea8782e97c10b13e8810955747a51
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293660
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/11395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When power is cut/restored to audio block, mbist workaround must be reapplied
or I2S will not function. Handle this in lp0 resume firmware with the rest of
the mbist WAR. This sequence for audio is also present in boot block code for
T210.
BUG=chrome-os-partner:41249
BRANCH=None
TEST=lp0 suspend/resume with audio playback
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 84933da8188f8263c19f38ba37e88e32ca46cb3d
Original-Change-Id: Ia6432e8556ee64f528d94f2dc3279b152294e132
Original-Signed-off-by: Christopher Freeman <cfreeman@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293618
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Anatol Pomazau <anatol@google.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Anatol Pomazau <anatol@google.com>
Original-Tested-by: Anatol Pomazau <anatol@google.com>
Original-(cherry picked from commit 1e529c3e2ff929975fd654ef75396bc98d3b785c)
Original-Reviewed-on: https://chromium-review.googlesource.com/293886
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I3e72bc10f7e2bea2fa5f946e25803a7928ce9276
Reviewed-on: http://review.coreboot.org/11394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Due to HDMI need to set dclk_rate to 27Mhz, and we can't
caclu a suitable config paramters for this rate, so we
need to multiple rate unless the vco larger then VCO_MAX.
When NPLL rate multiple to 54MHz, pll_para_config could
caclu a right paramters, and I have verify the clock jitter
is okay to HDMI output.
Jitter Reports:
Dclk Rate NPLL Rate nr/no/nf jitter Margin
27MHz 54MHz 2/10/45 449.0ps +51.0%
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, show right recovery picture on TV,
and 480p clock jitter test passed
Change-Id: Iaa0a6622e63d88918ed465900e630bdf16fde706
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 59f1552026889f61167cfeaec3def668ba709c10
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Change-Id: Iab274b41f163d2d61332df13e5091f0b605cb65c
Original-Reviewed-on: https://chromium-review.googlesource.com/288416
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290331
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If an HDMI display is detected (EDID can be read), set the
display mode to 480p. If for some reason 480p is not supported
then we'll fall back to the automatically detected display mode.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=dev mode screen shows up on Mickey at 480p resolution
Change-Id: I2c431eff6673392d3c09e1b66c66ba12ecc6eeb0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 76203a683c4501f368c50fe24101f68746ddb7f0
Original-Change-Id: I90dea37daa2d78628230d7d47f7ef0e917cbd7bb
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290554
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11392
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Assume that HDMI implies usage of an external display, and that we
want to try bringing up display if we can read an EDID.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none; need a display with corrupt EDID to test with
Change-Id: I11cc61140d905d70798a7b46db7847f3a1b3c886
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: ace7773623eac57f068ecd50baa9108ce028cf1b
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I9e22984a98b1a5f8cd9645b92dc9b87e8d968f01
Original-Reviewed-on: https://chromium-review.googlesource.com/293548
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11391
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: I8a9dedfe08057d42d85b8ca129935a258cb26762
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 090583f90ff720d88e5cfe69fcb2d541c716f0e6
Original-Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289671
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This ensures the output buffer is initialized before exiting
decode_edid() so that if the return value is ignored in higher-level
logic (like when dealing with external displays) we don't leave
the struct filled with garbage.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none
Change-Id: I557e2495157458342db6d8b0b1ecb39f7267f61f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: bb12dca133576543efa4d3bcc9aadf85d37c8b71
Original-Change-Id: I697436fffadc7dd3af239436061975165a97ec8c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293547
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11389
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I660f28c850163e89fe1f59d6c5cfd6e63a56dda0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: ee8ea314a0d8f5993508f560fc24ab17604049df
Original-Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Original-Reviewed-on: https://chromium-review.googlesource.com/290333
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The value of 0x4 (60 Ohm) apperas to be causing lots of problems.
Since 0x1 (34.3 Ohm) was _almost_ right, let's try 0x2 (40 Ohm) and
hope it's the sweet spot.
BRANCH=None
BUG=chrome-os-partner:43626
TEST=My mickey now boots up
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 06db96e00d39972edbaf8429cbe88bbc66804e15
Original-Change-Id: If8b7d51d058ae000c0af189a648c62fa38a872ac
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291121
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-(cherry picked from commit 0dabadca1ab3bb310f85646d020bdcf672014071)
Original-Reviewed-on: https://chromium-review.googlesource.com/291291
Change-Id: Id32790c894c09616e32503aa790fa294093eca8a
Reviewed-on: http://review.coreboot.org/11386
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This basically does the same thing for firmware what CL:290631
did in the kernel. We want to keep the modem off until it needs
to be used to avoid enumeration/detection issues.
BUG=chrome-os-partner:43271
BRANCH=none
TEST=needs testing
Change-Id: I3b63a77c732dc4895b728b30f1dd71210a9c0e90
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: a90ccd7fbffe44abe05e96341cc77067442c85e4
Original-Change-Id: I3516de1ea9160f7186ad7f5fb3b5d29ac73143b5
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290890
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Reviewed-on: http://review.coreboot.org/11385
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The NV security team requested that coreboot allocate a 128MB
region in SDRAM for VPR (Video Protection Region). We had
previously just disabled the VPR by setting BOM/SIZE to 0.
Once allocated, the VPR will be locked from further access.
The ALLOW_TZ_WRITE_ACCESS bit is _not_ set, as dynamic VPR config
is not supported at this time (i.e. trusted code can _not_ remap
or resize the VPR).
BUG=None
BRANCH=None
TEST=Built and booted on my P5 A44. Saw the VPR region in the
boot spew (ID:3 [f6800000 - fe800000]). Dumped the MC VideoProtect
registers and verified their values.
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: a7481dba31dc39f482f8a7bfdaba1d1f4fc3cb81
Original-Change-Id: Ia19af485430bc09dbba28fcef5de16de851f81aa
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/290475
Original-Reviewed-by: Hyung Taek Ryoo <hryoo@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Hridya Valsaraju <hvalsaraju@nvidia.com>
Original-(cherry picked from commit 9629b318eb17b145315531509f950da02483114f)
Original-Reviewed-on: https://chromium-review.googlesource.com/291095
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I19a93c915990644177c491c8212f2cf356d4d17d
Reviewed-on: http://review.coreboot.org/11384
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BL31 makes an assumption that TZDRAM always starts at its base. This
was not true in our case since coreboot page tables were located
towards the start of TZDRAM. Instead move page tables to the end, thus
satisfying the assumption that BL31 base is the base of TZDRAM as
well.
BUG=chrome-os-partner:42989
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: aabed336da6e9aea426650c5ca5977ccfc83a21b
Original-Change-Id: Ic4d155525dbb4baab95c971f77848e47d5d54dba
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/291020
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-(cherry picked from commit a57127f1655ef311b82c41ce33ffc71db5f9db35)
Original-Reviewed-on: https://chromium-review.googlesource.com/290987
Change-Id: Ie7166fd0301b46eb32f44107f7f782c6d79a278c
Reviewed-on: http://review.coreboot.org/11383
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The NV security team requested that coreboot allocate the NVDEC
and TSEC carveouts. Added code to set up NVDEC (1 region, 1MB)
and TSEC (2 regions, splitting 2MB), and set their lock bits.
Kernel/trusted code should be able to use the regions now.
Note that this change sets the UNLOCKED bit in Carveout1Cfg0
and Carveout4Cfg0/5Cfg0 (bit 1) to 0 in the BCT .inc files
(both 3GB and 4GB BCTs) so that the BOMs can be written.
Any future revisions to these BCT files should take this
into account.
BUG=None
BRANCH=None
TEST=Built and booted on my P5 A44. Saw the carveout regions
in the boot spew, and CBMEM living just below the last region
(TSEC). Dumped the MC GeneralizedCarveoutX registers and
verified their values (same as BCT, with only BOM/CFG0 changed).
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: a34b0772cd721193640b322768ce5fcbb4624f23
Original-Change-Id: I2abc872fa1cc4ea669409ffc9f2e66dbbc4efcd0
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/290452
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-(cherry picked from commit f3bbf25397db4d17044e9cfd135ecf73df0ffa60)
Original-Reviewed-on: https://chromium-review.googlesource.com/291081
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I924dfdae7b7c9b877cb1c93fd94f0ef98b728ac5
Reviewed-on: http://review.coreboot.org/11381
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Struct edid defien pvsync & phsync as an character,
like '+' or '-', so we need to check sync polarity
by comparing with characters '+' and '-' instead of
treating as boolean.
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, light monitor normally
Change-Id: I92d233e19b6df8917fb8ff9a327ccb842c152d65
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 2d22d4b6e7108474f67200e0fb1e4894cd88db85
Original-Change-Id: I14c72aa8994227092a1059d2b25c1dd2249b9db1
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/289963
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It doesn't hurt to expose declarations. Instead of
a compile-time error there'll be a link error if someone
tries to malloc() anything.
Change-Id: Ief6f22c168c660a6084558b5889ea4cc42fefdde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11406
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Do not guard the inclusion of "drivers/intel/gma/int15.h"
and "arch/interrupt.h" with configs that control option rom execution.
These headers already have the proper guards. The
install_intel_vga_int15_handler() is unconditionally called, even when
the header that declares it is guarded out.
Change-Id: Ia273437486f5802aa2b53212f2a1b5704c9485fa
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11379
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This seems like more of a debug option, than something that should
be forced to be enabled by the platform. Since it's causing a Kconfig
warning, I'm just removing it.
The alternative to removing it would be to add dependencies on
CONSOLE_CBMEM && !CONSOLE_SERIAL
Change-Id: Ifc4e4cbeea08a503c38827dd75e0e2e78e8a5eda
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11343
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The acpi_fill_ssdt_generator function pointer is evaluated for
each device. As there are multiple cpus in the system the
acpi_fill_ssdt_generator was being called more than once creating
duplicate ACPI entries because there was more than 1 cpu device.
Fix this by only generating them once by removing the
acpi_fill_ssdt_generator for the cpu devices, but add the
generator to the cpu cluster device.
BUG=chrome-os-partner:44084
BRANCH=None
TEST=Built and booted on glados. Noted ACPI entries only generated once.
Original-Change-Id: I695c30e6150f6d3a79d13744c532f1b658b10402
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294240
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Change-Id: I7c85f44ba65398bda668e13db8be531535a983c5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11285
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The prior implementation of PAD_CFG_GPI kept the pad
ownership as ACPI. The gpio driver in the kernel then
wouldn't allow one to export those GPIOs through sysfs
in /sys/class/gpio. Fix this by setting the ownership
to GPIO.
BUG=chrome-os-partner:44147
BRANCH=None
TEST=Built and boot glados. PCH_WP gpio is properly exported
by crossystem.
Original-Change-Id: I9fc7ab141a3fd74e0ff8b3ff5009b007b8a0d69b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294081
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ifbb61c5d64bb6a04f140685c70f4681e2babecef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11283
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move all the various places that look at board specific GPIOs into
the mainboard gpio.h so it can be easily ported to new boards.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados p2
Original-Change-Id: I3f1754012158dd5c7d5bbd6e07e40850f21af56d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293942
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I93c4dc1795c1107a3d96e686f03df3199f30de8a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11282
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Implement the required Chrome OS specific handlers to read the
recovery mode, clear the recovery mode, read the lid switch state,
and read the write protect state using the appropriate methods.
Also update the Chrome OS ACPI device to use the GPIO definitions
that are exposed now by the SOC.
BUG=chrome-os-partner:43515
BRANCH=none
TEST=build and boot on glados and successfully enter recovery mode
Original-Change-Id: Ifd51c11dc71b7d091615c29a618454a6a2cc33d7
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293515
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia6ef83a80b9729654bc87bb81bd8d7c1b01d7f42
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11281
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a helper function to read the EC switch state on LPC based
ECs instead of having each board need to understand and use the
specific EC LPC IO method that is required.
BUG=chrome-os-partner:43515
BRANCH=none
TEST=build and boot on glados
Original-Change-Id: Id046c7ddf3a1689d4bf2241be5da31184c32c0e1
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293514
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Id11009e0711b13823e4f76dc9db9c9c20abf4809
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11280
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The part number was the same as the H9CCNNNBLTLAR which means it
is not possible to distinguish the two based on part number alone.
This breaks mosys and thus the factory tests.
BUG=chrome-os-partner:43514
BRANCH=none
TEST=boot on glados P2 SKU3 and verify memory reported by mosys
Original-Change-Id: I606ef3989bd7273d134a258bc933088ccc865542
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293513
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7cea7cc4c61a20fda47673c8e25c431d391aa3bc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11279
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the ELAN touchscreen device in ACPI to bind it to the I2C
device at bus I2C0, address 0x10, interrupt 31 (GPP_E7).
BUG=chrome-os-partner:43514
BRANCH=none
TEST=boot on glados P2 and see touchscreen initialized by kernel
Original-Change-Id: I23b071b2767547baed239c94216cda6162d045dd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293512
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I8a9492e6fa1f650cef0871329ae8944caffdaf5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11278
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Clean up the device code for the glados mainboard, using
the defined values for interrupts by the SOC and moving the
various codec i2c addresses to the top of the file.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados
Original-Change-Id: Iead1aeb54363b15a6176d4f4a9511674195c0505
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293511
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I083c9ef6140e20a433cb2017e4c3cbc7a41e8fed
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11277
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patche enables the deep S5 and disables Deep S3.
Kunimitsu does not resume from deep S3. This change will
unblock the S3 resume path on kunimitsu board.
BRANCH=None
BUG=chrome-os-partner:42331
TEST=Built and booted on kunimitsu; check s3 works.
Original-Change-Id: Ia828a39bceef615fd194bb3614ba2de87c3af805
Original-Signed-off-by: Naveen Krishna Chatradhi <naveenkrishna.ch@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/291250
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I07b95a324a27ab658e80674686b47b86412ea097
Signed-off-by: Naveen Krishna Chatradhi <naveenkrishna.ch@intel.com>
Reviewed-on: http://review.coreboot.org/11274
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
RISCV requires a trap handler at the machine stage to deal with
misaligned loads/stores, as well as to deal with calls that a linux
payload will make in its setup. Put required assembly for jumping
into and out of a trap here to be set up by the bootblock in a later
commit.
Change-Id: Ibf6b18e477aaa1c415a31dbeffa50a2470a7ab2e
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11367
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
With VIRTUAL_DEV_SWITCH moved under 'config CHROMEOS' in all of the
mainboards, this is no longer needed.
Change-Id: I5fbea17969f6b0c3b8a5dcd519ab9d36eb2ad6f1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11337
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the CHROMEOS dependent symbols VIRTUAL_DEV_SWITCH and
VBOOT_DYNAMIC_WORK_BUFFER under the CHROMEOS config options for the
mainboards that use them.
Change-Id: Iad126cf045cb3a312319037aff3c4b1f15f6529d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Add 'select MAINBOARD_HAS_NATIVE_VGA_INIT' which is just used as a gate
symbol to display MAINBOARD_DO_NATIVE_VGA_INIT to the mainboards that
are already selecting MAINBOARD_DO_NATIVE_VGA_INIT.
Since MAINBOARD_HAS_NATIVE_VGA_INIT is not used in any code, this should
not have any other effects.
This fixes the warning:
warning: (BOARD_SPECIFIC_OPTIONS) selects MAINBOARD_DO_NATIVE_VGA_INIT
which has unmet direct dependencies (VENDOR_ASUS && BOARD_ASUS_KFSN4_DRE
|| MAINBOARD_HAS_NATIVE_VGA_INIT)
Change-Id: I8ceee69ebae90dc32f55df58c2e80fe25397f049
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Kconfig symbol CACHE_MRC_BIN was getting forced enabled everywhere
it existed.
Remove the Kconfig symbol and get rid of the #if statements
surrounding the code.
This fixes the Kconfig warning for Haswell & Broadwell chips:
warning: (NORTHBRIDGE_INTEL_HASWELL &&
NORTHBRIDGE_INTEL_SANDYBRIDGE &&
NORTHBRIDGE_INTEL_SANDYBRIDGE_NATIVE &&
NORTHBRIDGE_INTEL_IVYBRIDGE &&
NORTHBRIDGE_INTEL_IVYBRIDGE_NATIVE &&
CPU_SPECIFIC_OPTIONS) selects CACHE_MRC_BIN
which has unmet direct dependencies
(CPU_INTEL_SOCKET_RPGA988B || CPU_INTEL_SOCKET_RPGA989)
Change-Id: Ie0f0726e3d6f217e2cb3be73034405081ce0735a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When the check for global symbols in romstage happens, if everything is
good, a warning appears, telling us that the segment is empty. While the
empty segment is good, the warning is distracting:
"BFD: build/cbfs/fallback/romstage_null.debug: warning: Empty loadable
segment detected, is this intentional ?"
This change hides that particular warning, but shouldn't hide any other
output from objcopy.
Change-Id: If22489280712d02a61c3ee5e0cb2a53db87d6082
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11302
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The AMD K8 northbridge uses the Kconfig symbol QRANK_DIMM_SUPPORT,
but the symbol was used on a number of Family 10 boards as well.
AMD Family 10 doesn't use this Kconfig symbol for anything.
I verified that the symbol wasn't used actually getting used in any
of these platforms.
Fixes Kconfig warnings for these 19 mainboards:
warning: (BOARD_SPECIFIC_OPTIONS...) selects QRANK_DIMM_SUPPORT which
has unmet direct dependencies (NORTHBRIDGE_AMD_AMDK8)
Change-Id: I454992a4975566fd6439a21f5a800d0cfa1b4d3b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11300
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Add CHROMEOS dependencies to selects for the following Kconfig
symbols:
CHROMEOS_RAMOOPS_DYNAMIC
CHROMEOS_RAMOOPS_NON_ACPI
CHROMEOS_VBNV_CMOS
CHROMEOS_VBNV_EC
CHROMEOS_VBNV_FLASH
EC_SOFTWARE_SYNC
LID_SWITCH
RETURN_FROM_VERSTAGE
SEPARATE_VERSTAGE
VBOOT_DISABLE_DEV_ON_RECOVERY
VBOOT_EC_SLOW_UPDATE
VBOOT_OPROM_MATTERS
VBOOT_STARTS_IN_BOOTBLOCK
WIPEOUT_SUPPORTED
This gets rid of these sorts of Kconfig errors:
warning: BOARD_SPECIFIC_OPTIONS selects CHROMEOS_VBNV_EC which has
unmet direct dependencies (MAINBOARD_HAS_CHROMEOS && CHROMEOS)
Note: These two boards would never actually have CHROMEOS enabled:
intel/emeraldlake2 has MAINBOARD_HAS_CHROMEOS commented out
google/peach_pit doesn't have MAINBOARD_HAS_CHROMEOS
Change-Id: I51b4ee326f082c6a656a813ee5772e9c34f5c343
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CHROMEOS is a user-visible bool. It must not be 'select'ed in Kconfig.
That's why we have MAINBOARD_HAS_CHROMEOS. This is the fifth time I
find this being used wrong.
Why is this confusing/so hard to get right?
Change-Id: Icb4629355c63508f5a044b46842524b3d203c2da
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11290
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbmem_top was using CHIPSET_RESERVED_MEM_BYTES to w/a unknown memory
regions reserved by fsp for chipset use. With that being removed, the
function needs to properly walk though the memory map resulted from fsp
memory init to find out the usable address for cbmem root.
Refer the FSP 1.3.0 Integartion guide for more details on the Memory
Map.
systemagent should also use the same mechanism to create the reserved
RAM resource.
BRANCH=None
BUG=None
TEST=Build and Boot kunimitsu (FAB3)
CQ-DEPEND=CL:*226035,CL:*226045,CL:291573
Original-Change-Id: Id0954cf8e6388e549c7d4df67b468572b5bea539
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/291611
Original-Tested-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Robbie Zhang <robbie.zhang@intel.com>
Change-Id: I4e716170f40936081ce9d4878bf74c75f469f78d
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: http://review.coreboot.org/11239
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(1) Wifi is connected on RP1 which is 1c.0 , so enabling
1c.0 and disabling 1d.0
(2) kepler is on RP5 which is 1c.4, so enabling it
(3) enabling ClkReqSupport for RP1 and RP5 so that L1 substates can
get enabled.
BRANCH=None
BUG=chrome-os-partner:43738
TEST=Built and boot for Kunimitsu. checked all PCIe powersaving
states (LTR, L1, L1S) are enabled
Original-Change-Id: I525661399d1a4d939b53d5ed5f7991598b84ddcd
Original-Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293482
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ib9a771a6ec137217668fb0385efc13b1824772b4
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: http://review.coreboot.org/11237
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The skylake IO-APIC supports up to 120 redirection entries.
In practice it seems FSP has already written to this write-once
register. However, it doesn't hurt to actually be correct within
the source.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I666b1b6034f0d37a37ea918f802317f9d5f15718
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293251
Original-Reviewed-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I6ddbc89c98c262e2dd0f9f0b76adb092d3043602
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11235
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The skylake SoC code now has macros for the previously
hard-code numbers for IRQs and GPEs. Switch over to using
those as they bring a little more clarity.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: Ic8fcc59d680cdddec9dfbc3bf679731f6d786793
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293411
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I594907005372100a3c9d17dda9d17769844ad272
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11234
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
One thing that is brittle is lining up GPE0 bits in ASL
and with a board's design proper. This results in open
calculated magic numbers. To help alleviate this provide
just #defines that C preprocessor can use before handing
the source off to the ASL compiler.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados. Everything's intact.
Original-Change-Id: I359616ebe4bfc83c05bafe0ca36b766efd16dcca
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293410
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I32513c324b923fa0adbd6a0ee920c27e9b97dd1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11233
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The location of the AMD ROMSIG binary was being checked and warnings
were being printed even when the ROMSIG file wasn't being used.
These false warnings are avoided by moving the warnings into the
block where the CBFS file for the ROMSIG is generated.
Change-Id: Ie44a2ad97ff3b15df6dc9b8166992de6ed837997
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11161
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit 27baa32 (cpu/amd/model_10xxx: Do not initialize SMM memory if
SMM is disabled) deactivated TSeg SMRAM, which had the side effect
of routing legacy VGA memory access to DRAM. Restore the correct
MMIO mapping via the MMIO configuration registers.
TEST: Booted KGPE-D16 with nVidia 7300LE card and verified proper VGA
functionality.
Change-Id: Ie4b7c0b2d6f9a02af9a022565fe514119513190a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11240
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Broadwell and Skylake chipsets, along with a few mainboards were
selecting ALWAYS_LOAD_OPROM without making sure that the dependency
for that symbol was met as well.
Looking at the dependencies for VGA_RUN_ROM, we see:
PCI && !PAYLOAD_SEABIOS && !MAINBOARD_DO_NATIVE_VGA_INIT
Since ARCH_X86 selects PCI, that's always met here.
Since Broadwell and Skylake don't have native VGA init yet, that's
not needed.
- Make sure that VGA_RUN_ROM is selected as well.
- Add dependency on !PAYLOAD_SEABIOS for both ALWAYS_LOAD_OPROM and
VGA_RUN_ROM symbols where they're selected.
Fixes Kconfig warning for these boards and chipsets:
warning: (BOARD_SPECIFIC_OPTIONS && BOARD_SPECIFIC_OPTIONS &&
BOARD_SPECIFIC_OPTIONS && CPU_SPECIFIC_OPTIONS && CPU_SPECIFIC_OPTIONS)
selects ALWAYS_LOAD_OPROM which has unmet direct dependencies
(VGA_ROM_RUN)
Change-Id: I787a87e9467e1fc7afe8b04864b2a89b54824b9f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11246
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change the dependency on CONSOLE_SERIAL to select CONSOLE_SERIAL based
on this question.
The dependency was causing multiple warnings on every platform tested.
src/console/Kconfig:21:error: recursive dependency detected!
src/console/Kconfig:21: symbol CONSOLE_SERIAL depends on
DRIVERS_UART_8250MEM
src/drivers/uart/Kconfig:16: symbol DRIVERS_UART_8250MEM is selected by
UART_DEBUG
src/soc/intel/skylake/Kconfig:198: symbol UART_DEBUG depends on
CONSOLE_SERIAL
Change-Id: Ia0426cd150561694081b5ea7c6797d36022c1f57
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11243
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
When the user's primary group contains a space ls -l and awk get the
wrong value for the file size. This results in padding the
coreboot_psp_directory_combine_pubkey.bin file too much which ultimately
means RtmPubSigned.key can not be placed at the necessary offset.
Changing from ls -l to ls -ln seemed like the most minimal,
POSIX-friendly way to effect this change.
Change-Id: Icbeaad476753924626adb6de53dc9a30052d91a6
Signed-off-by: Dan Christensen <opello@opello.org>
Reviewed-on: http://review.coreboot.org/11242
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order for the EC_SCI_L to work the GPE0 route needs
to be set along w/ the GPE event for the EC. As the GPE0
route is dynamic the EC_SCI_GPI needs to be set along
with the route so everything lines up. In this case, the
GPE0 route is set to the defaults such that GPP_C, GPP_D,
and GPP_E are routed to GPE0 block 0, 1, and 2, respectively.
This works out for glados because the EC_SCI_L is connected
to GPP_E16.
BUG=chrome-os-partner:43778
BRANCH=None
TEST=Built and booted glados. The 'acpi' interrupt in /proc/interrupts
is incrementing as well as /sys/firmware/acpi/interrupts/gpe50.
Original-Change-Id: I71fc4bec124f3ac87453a099412154e67aba6280
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/292011
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Idbb6d29364655537abc9ae6f012b3abb38edf138
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11210
Tested-by: build bot (Jenkins)
Set the EC_SMI_GPI define to be GPP_E15 and route that
GPIO for SMI generation. Also, the mainboard_smi_gpi_handler()
was introduced on skylake in order to process any GPI that could
generate an SMI. Switch to this handler so one can process the
appropriate events.
BUG=chrome-os-partner:43778
BRANCH=None
TEST=Used 'lidclose' on EC command line during depthcharge
to confirm EC_SMI_L generates SMI and shutdown happens.
Original-Change-Id: Ia365b86161670a809e3fa99dde38fccc612d5e77
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291934
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ic16ea8e8d6ff564977ed2081d2353c82af71adea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11209
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current construction for processing SMI GPI events
didn't allow for the mainboard to query the state of a
particular GPI for the snapshotted SMI event. The
skylake part can route GPIs from any (there are design
limitations) GPIO group. Those status and enable registers
are within the GPIO community so one needs to gather
all the possibilities in order to query the state.
The call chain did this:
southbridge_smi_gpi(
clear_alt_smi_status() -> reset_alt_smi_status() ->
print_all_smi_status() -> return 0)
As a replacement the following functions and types are
introduced:
struct gpi_status - represent gpi status.
gpi_status_get() - per gpi query on struct gpi_status
gpi_clear_get_smi_status() - clear and retrieve SMI GPI status
mainboard_smi_gpi_handler() - mainboard handler using gpi_status
Also remove gpio_enable_all_smi() as that construct was never
used, but it also is quite heavy handed in that it would
enable SMI generation for all GPIs.
BUG=chrome-os-partner:43778
BRANCH=None
TEST=Built.
Original-Change-Id: Ief977e60de65d9964b8ee58f2433cae5c93872ca
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291933
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ida009393c6af88ffe910195dc79a4c0d2a4c029e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11208
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The first pass of the GPIO configuration patch didn't
enable the SMI# generation for GPIs marked as SMI
routed. Now when a pad is configured as SMI routed
the bit for the SMI enablement is set accordingly.
BUG=chrome-os-partner:43778
BRANCH=None
TEST=Built and booted glados. Confirmed SMI_EN being set
for SMI routed GPIOs.
Original-Change-Id: I796b68accb7a49b03ef18539861e72fa9d169c26
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/292010
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I3be770234d3f605ae630ecd5cd4cfe4867243999
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11207
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The gpio pad configuration currently defaults to ACPI
owned GPIs. A '0' was used which wasn't so clear. Add
a comment and explicitly set it to ACPI. Also,
PAD_CFG_GPI_ACPI_SMI wasn't using the _PAD_CFG_ATTRS
macro which causes compliation errors if attempted
to be instantiated. No piece of code tried to use
it so the error was overlooked.
Lastly, allow for soc/gpio.h to be included during
ASL compilation. That allows for gpio_defs.h to be
included and those macros utilized without needing
to know the file name and where it lives; just use
the generic gpio.h.
BUG=chrome-os-partner:43778
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I9dbadb0b494683ab38babfc1ac5e13093ee37730
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291935
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Id4fa8b65ec1e1537dbf09824c2155119a768807e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11206
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of using a hard-coded value leverage the existing
definitions to perform GPE0 block length calculations. There
are 4 pairs of 32-bit status/enable registers.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I14d08298b5750c91ce0ac3fa33569813396f7089
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291932
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I127f026f15180fa79625d4cad96d5e35f85e5090
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11205
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The ec_smi_gpio and alt_gp_smi_en devicetree options are
goign to be removed. The plan for skylake is to set the
settings by the mainboard through either gpio pad
configuration or through helper functions.
Moreover, these values only allow *1* SMI GPIO configuration
in that the following has to be true:
alt_gp_smi_en = 1 << (ec_smi_gpio % 24)
If not, then another gpio(s) from the same group has the
SMI_EN bit set for it.
Lastly, remove all the subsequent dependencies as they are
no longer used: enable_alt_smi() and gpio_enable_group().
BUG=chrome-os-partner:43778
BRANCH=None
TEST=None
Original-Change-Id: I749a499c810d83de522a2ccce1dd9efb0ad2e20a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291931
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I2e1cd6879b76923157268a1449c617ef2aada9c4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On skylake the GPE0 routing can be dynamically changed to
a particular GPIO group. Provide the ability for the mainboard
to set the route accordingly. If any of the values in the
devicetree are the same the current setting in the PMC register
is used. The GPIO communities need to have matching configuration
for the plumbing to work properly.
BUG=chrome-os-partner:43778
BRANCH=None
TEST=Built and booted glados w/ and w/o devicetree changes. Fields
are set accordingly.
Original-Change-Id: I263d648c8ea8a70b21570f01b333d05a5fa2a4e3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291930
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I966d38bc197dbb52a2ba50927c06e243e169afbe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11203
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
IedSize is not used in replace of IED_REGION_SIZE.
Drop it from chip.h.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, resumed on glados.
Original-Change-Id: I38f6518701306c0ffc6d2b2e3fe01624a5eadf54
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290933
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Trybot-Ready: David James <davidjames@chromium.org>
Change-Id: I9dd9e689d4d4f7b4770369dcd042d3325990ae32
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11201
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The skylake code is using IED_REGION_SIZE instead of
devicetree.cb. Drop the the option from the device trees.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=None
Original-Change-Id: Ib252266060fbc6ed0eeaac19a6b79c173c6c9a13
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290932
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Trybot-Ready: David James <davidjames@chromium.org>
Change-Id: Ib08628e163ac27d4c49eddcbec6cab3252abd4aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11200
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The stage_cache_external_region() calculation is actually
dependennt on the properties of the chipset. The reason
is that certain regions within the SMRAM are used for
chipset-specific features. Therefore, provide an API
for abstracting the querying of subregions within
the SMRAM.
The 3 subregions introduced are:
SMM_SUBREGION_HANDLER - SMM handler area
SMM_SUBREGION_CACHE - SMM cache region
SMM_SUBREGION_CHIPSET - Chipset specific area.
The subregions can be queried using the newly
added smm_subregion() function.
Now stage_cache_external_region() uses smm_subregion()
to query the external stage cache in SMRAM, and this
patch also eliminates 2 separate implementations of
stage_cache_external_region() between romstage and
ramstage.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, resumed on glados.
Original-Change-Id: Id669326ba9647117193aa604038b38b364ff0f82
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290833
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Idb1a75d93c9b87053a7dedb82e85afc7df6334e0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11197
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The smm_subregion() support allows the SMM relocation
to not use duplicated math by calling out the specific
regions it wants. IED base is now correct and not
pointing outside from SMRAM.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, resumed on glados.
Original-Change-Id: Ief8940c2ab6320449500ced2121d0cd7ed73af4b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290930
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Trybot-Ready: David James <davidjames@chromium.org>
Change-Id: I00c3284cfacb2a73942640ccfa7912b7d65efb9d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11198
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The fsp_ramstage.c code was not taking advantage of the stage
cache which does all the accounting and calculation work for
the caller. Remove the open coded logic and use the provided
infrastructure. Using said infrastructure means there's no
need for the FSP_CACHE_SIZE Kconfig variable. Therefore, remove
it.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, and resumed on glados.
Original-Change-Id: I4363823c825b4a700205769f109ff9cf0d78b897
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290831
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ifd3cc4a538daac687949c5f4cab2c687368d6787
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11196
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TSEG is defined to be from TSEG->BGSM in the
host bridge registers. Use those registers at
runtime to calculate the correct TSEG size.
Lastly, use a few helper macros to make constants
more readable.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built, booted, suspended, resumed on glados.
Original-Change-Id: I6db424a0057ecfc040a3cd5d99476c2fb8f5d29b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290832
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I6890fa450ce8dc10080321aa1a7580e0adc48ad5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11195
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Using struct prog and struct region_device allows for the
caller to be none-the-wiser about where FSP gets placed. It
also allows for the source location to be abstracted away
such that it doesn't require a large mapping up front to
do the relocation. Lastly, it allows for simplifying the
intel/commmon FSP support in that it can pass around a
struct prog.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, and resumed on glados.
Original-Change-Id: I034b04ab2b7e9e01f5ee14fcc190f04b90517d30
Original-Signed-off-by: Aaron Durbin <adurbin@chroumium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290830
Original-Tested-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibe1f206a9541902103551afaf212418fcc90e73c
Signed-off-by: Aaron Durbin <adurbin@chroumium.org>
Reviewed-on: http://review.coreboot.org/11193
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The stage_cache_add() function should not be manipulating
the struct prog argument in anyway. Therefore, mark it as
const.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, and resumed on glados.
Original-Change-Id: I4509e478d3c98247b9d776f6534b949d9ba6282c
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290721
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ibadc00a9e1cbbf12119def92d77a79077625fb85
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11192
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch enables GPIO controller for skylake. It adds
community base addresses and offset for Community0, Community1,
and Community3. Community2 is not exposed in BIOS or enabled
in the kernel driver.
Also, clean up the carry over GWAK implementation from BDW.
BRANCH=None
BUG=chrome-os-partner:42393
TEST=cat /sys/kernel/debug/gpio should list of GPIOs
TEST=export a GPIO pin using /sys/class/gpio/export
Original-Change-Id: I891c40589d3dbd796cf593626472c7b5674a1ae0
Original-Signed-off-by: Archana Patni <archana.patni@intel.com>
Original-Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/291230
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Wenkai Du <wenkai.du@intel.com>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7481ce682ccae872fddf81b3188c3415d5d3f7d9
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Reviewed-on: http://review.coreboot.org/11191
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
acpi_is_wakeup_s3() was introduced in upstream coreboot
while the FSP support code was written. Move to using
that instead of using the romstage_handoff structure
directly.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, and resumed on glados.
Original-Change-Id: I71601a4be3c981672e25e189c98abb6a676462bf
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290720
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I2ae4d9906e0891080481fb58b941921922a989d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11190
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Explicitly clear all write-1-to-clear fields in the
appropriate power state registers. That way stale
state isn't left around from boot to boot. The
MMIO PMC registers are always added such that the
resource can be accessed from reg_script. It doesn't
hurt to add the resource, and it's actually more
informative by attaching the actual resources
owned by the device.
BUG=chrome-os-partner:43625
BRANCH=None
TEST=Built and boot glados. Did global reset. Noticed bits
set. Did normal reset and saw those same bits no longer set.
Original-Change-Id: Idd412bd6bf2c6c57b46c74f9411bdf8413ddd83e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290339
Change-Id: Ibef1aefedf6ba006f17f9f94998a10b39cc6bfec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11186
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Leaving a sentinel 0xC0DEBABE and fixing it up is
is the old way of setting the correct base address
for GNVS. One just needs to reference NVSA which is
already filled in by the skylake ACPI code.
BUG=chrome-os-partner:43611
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados. /sys/firmware/log shows
up as well as ramoops using the correct address.
Original-Change-Id: I1d4979b1bb65faa76316a4ec4c551a7b9b9eed32
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290338
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I25efea73a383215f9365ce91230f79516b0201a6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11185
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Provide #defines for the bit fields in the SMI status register.
This allows for one to set the callback accordingly without
hard coding the index.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I3e61d431717c725748409ef5b543ad2eb82955c4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289802
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I1a91f2c8b903de4297aaa66f5c6ff15f1b9c54f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11184
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
DISB (bit 23) in GEN_PMCON_A represents to MRC that DRAM
training is complete. However, as a 8-bit write was
being performed the bit was never being set.
BUG=chrome-os-partner:43516
BRANCH=None
TEST=Built and booted to kernel. Rebooted. Noted full memory
training was not being peformed.
Original-Change-Id: If2a9cc2f80bc38ea86fb0d7ff855ef95540b561b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290337
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ic7973e0ec279304797e0b3d83d7378f620f2b548
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11183
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Open coding bitfields is really annoying as no one knows
what they are unless you have a doc in front of you.
Fill in the bitfields for the GEN_PMCON_A and GEN_PMCON_B
registers.
BUG=chrome-os-partner:43522
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: Id48de68eaa3896c17d5da2ffb0bcf17062f73e5e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290336
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I968be9736419e26a771e0a0c3c964d540fbb1efe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11182
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Timothy Pearson