- Move the 'Intel FSP' Kconfig comment inside the 'if' block so that it
doesn't show up on platforms that aren't using it.
- Update the comment to reflect that this is version 1.1 of the FSP
interface.
Change-Id: I7182c5b07332c4f95620f7374526ab1de0484d01
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10650
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Use 3rdparty/blobs subdirectory for binary files
Display the MTRRs after TempRamExit and before the MTRR setup
Clear all of the variable MTRRs before the MTRR setup
Define the FSP attributes location and bits
Properly display the FSP_RESERVED_MEMORY_RESOURCE_HOB and the
FSP_BOOTLOADER_TOLUM_HOB.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: I788a5f1e7676b1a06c1bcd66ddbd0a2249cad47c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10589
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's derived from EEPROM on Lenovo machines and not from user config
which is ignored.
Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7055
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
It can be helpful to certain users of the cbmem init hooks
to know if recovery was done or not. Therefore, add this
as a parameter to the hooks.
Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use of scan_static_bus() and tree traversals is somewhat convoluted.
Start cleaning this up by assigning each path type with separate
static scan_bus() function.
For ME, SMBus and LPC paths a bus cannot expose bridges, as those would
add to the number of encountered PCI buses.
Change-Id: I8bb11450516faad4fa33b8f69bce5b9978ec75e5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8534
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Follow up for commit b890a12, some contributions brought
back a number of FSF addresses, so get rid of them again.
Change-Id: Idcd059f05523916f726b94931c2487ab028b7d72
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10409
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
This should be an internal selectable variable rather than user-visible config.
Moreover the description is misleading.
This is a typical case of an option "Should it work?" where there is only one
right answer yet we still ask it.
Change-Id: Idc0ce2e1b9f89eddd034966cc877483d994ce0eb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10378
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch provides support for TPM Infineon SLB9670 by adding its
device ID to the list.
BRANCH=None
BUG=chrome-os-partner:40640
TEST=Built and test SLB9670 on SKL U Reference board Fab 2
Change-Id: I2d26fc6c7d074881f2e6189e1325808544b7d26d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3c92884be75b631c302801e162292c245ed7bf5d
Original-Change-Id: I4607fc96f70175b2461b40ba61e7a821e187de40
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/274053
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/10387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch provides support for TPM Infineon TT1.2
devices by enumerating the TT1.2 ID in the Infineon
device list.
BRANCH=None
BUG=None
TEST=Built for sklrvp and tested on RVP3.
Change-Id: I9daecc09311477fd9947e829d80abc040b2c9e3d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3ff86f96cb3e2f203dbc86e7004f1a037b98b90a
Original-Change-Id: I8b59eba348fc44632e22600646eb0b10eb2f4901
Original-Signed-off-by: Subrata <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/271256
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Original-Tested-by: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Reviewed-on: http://review.coreboot.org/10302
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Current TPM driver does not support multiple devices for
a given vendor. As the device object never takes the 2nd
ID in the list. This patch fixes the same.
BRANCH=None
BUG=None
TEST=Built for sklrvp and tested on RVP3.
Change-Id: I82c3267c6c74b22650fc53dc6abdc2eb3daa138e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ff42613f11b4f1a79e907601f1ecb7b83a3aeaab
Original-Change-Id: Ieb44735c37208bfe90a8e22e0348dd41c8c642d2
Original-Signed-off-by: Subrata <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/271727
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Original-Tested-by: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Original-Commit-Queue: Pravin K Angolkar <pravin.k.angolkar@intel.com>
Original-Tested-by: Pravin K Angolkar <pravin.k.angolkar@intel.com>
Reviewed-on: http://review.coreboot.org/10303
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Old igd.asl had inconsistent addresses (between _DOD and actual device)
and ghost devices. Any of those is enough to make brightness on windows
fail and make igd.asl out-of-ACPI-spec. Also old code favoured ridiculous
copying of the same thing 6 times per chipset. Leave only hooking up and
chipset-specific part in chipset directory. Move NVS handling and ACPI-spec
parts to a common file.
Change-Id: I556769e5e28b83e7465e3db689e26c8c0ab44757
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7472
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Follow up for commit b890a12, some contributions brought
back a number of FSF addresses, so get rid of them again.
Change-Id: I0ac0c957738ce512deb0ed82b2219ef90d96d46b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10322
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Just not exporting TPM isn't good enough as it can still be accessed.
You need to send it a deactivate command.
Change-Id: I3eb84660949c2d1e2b492d541e01d4ba78037630
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10270
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This code is not specific to ChromeOS and is useful outside of it.
Like with small modifications it can be used to disable TPM altogether.
Change-Id: I8c6baf0a1f7c67141f30101a132ea039b0d09819
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10269
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Update the FSP driver files from 1.0 to 1.1.
Updates will occur manually to these files only for FSP 1.1 support. An
fsp_x_y should be added in the future to support newer versions of the
FSP specification.
Please note that due to the interface with EDK2, these files make
references to data structures and fields that use CamelCase.
BRANCH=none
BUG=None
TEST=Build for Braswell or Skylake boards using FSP 1.1.
Change-Id: I2914c047d786a3060075356783ac9758bc41f633
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10049
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
My main payload is GRUB and I load SeaBIOS as secondary payload when for some
reason I want to boot windows. In this scenario SeaBIOS runs VGA oprom
(SeaVGABIOS is not good enough with intel gfx). VGA oprom expects either
completely uninited gfx or some special state in gmbus and software scratch
registers. Provide this state.
The only alternative without this patch for such usecase is to use oprom and
I'd like to avoid doing so when going my main boot path to GNU/Linux.
Change-Id: I38e78fb845e43b81df084cd4d65f4618bfb2506d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10205
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
0x20 was incorrectly represented as 4 * 5 while in fact it's 4 * 8
Change-Id: I6053a3baa6de0da9f1d648009353bc1fe542f81f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10237
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
disabled by GIC CPU interface. This is done by adding a bypass override
capability when the interrupts are disabled at the CPU interface. To
support this, there are four bits about IRQ/FIQ BypassDisable in CPU
interface Control Register. So the CPU can exit from WFI when an
asserted IRQ is coming. This is critical for power gating a CPU.
BRANCH=none
BUG=chrome-os-partner:39620
TEST=testing with CPU idle with power down state support and CPU can
wake up normally
Change-Id: I71ac642e28024a562db898665b74a5791fce325a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3a3f098cbf3fbfdab8150ebd4fd688fdb472b529
Original-Change-Id: I20569a18f34a4b11b8c8c67ea255b3d0f021839f
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/269116
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10172
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is based on commit f2b3cd63
(lenovo/x60: Support digitizer on X60t and X201t)
Tested on Thinkpad X200 Tablet (7450): all pen functionallity
works (i.e. movements, presure sensitivity and buttons)
Change-Id: I9bd18642a6ea4211dc3be065456a507fc0b72561
Signed-off-by: Alex David <opdecirkel@gmail.com>
Reviewed-on: http://review.coreboot.org/10208
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Inclusion of ricoh driver was lost in 1d7b9de350.
So the relevant code wasn't even compiled.
Fix copy-paste mistakes without significance while on it as well.
Change-Id: Ie548cb43f986f147658fc9c67963f8a055250598
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10211
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
verstage previously lacked serial console support.
Add the necessary objects and macro checks to allow
verstage to include the serial console.
Change-Id: Ibe911ad347cac0b089f5bc0d4263956f44f3d116
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10196
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Tested with gizmosphere/gizmo1 Explorer add-on board, which
exposes the following device:
0x0403 Future Technology Devices International, Ltd
0x6014 FT232H Single HS USB-UART/FIFO IC
For now UART is hard-coded to 115200, 8n1, no flow-control.
Change-Id: I4081f84f7700751ccbf079e7fcbb1467aa71d872
Signed-off-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10063
Tested-by: build bot (Jenkins)
secmon is referring to uart's default_baudrate() and
various coreboot version strings.
Change-Id: I40a8d1979146058409a814d94ea24de83ee4d634
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This allows the backlight control register to be set via devicetree.cb
Change-Id: I32b42dfc1cc609fb6f8995c6158c85be67633770
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/9330
Tested-by: build bot (Jenkins)
The 'A' indicates the production process(64 nm). All other chips from
the same family leave this out.
TEST=Build and booted on Minnowboard Max
Change-Id: I21e6c01de5d547bbc2252e679a001948e7ab752c
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10078
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
'.op_erase' was not specified for this chip. Set it to sub sector
erase(CMD_M25PXX_SSE). Adjust page/sector size for sub sector erase
to work.
TEST=Untested, due to lack of hardware.
Change-Id: Icc2748fbd3afeb56693e1c17d97eb490fba67064
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10077
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
N25Q064 is similar to N25Q128.
TEST=Build and booted twice on Minnowboard Max
Change-Id: Iec105f8b81f619846cf40b40042cc59150b81149
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10076
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
What is described by the comment has already been fixed in f0d038f4
(flash: use two bytes of device ID to identify stmicro chips).
This also means that STM_ID_N25Q128 doesn't have to be at the top of
stmicro_spi_flash_table anymore.
TEST=Untested, due to lack of hardware
Change-Id: I7a9e9a0cdfdb1cf34e914e186fc6957c1d9b5ca6
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10068
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The log message says 'page size' while actually the sector size is
printed. This is confusing since for stmicro page size != sector size.
Also add '0x' prefix to numbers to make it clear they are in hex.
TEST=Build and booted on Minnowboard Max
Change-Id: I795a4b7c1bc8de2538a87fd4ba56f5a78d9ca2ac
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10067
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Fix up commit c13ad6c6 (driver/intel/fsp: Correct the fastboot data (MRC
data) printing length) unintentionally making the changed files
executable.
Change-Id: I909c323023a9ccfb0c20094d9085ae90043b9e04
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10060
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Consolidate the FspNotify calls into the FSP driver directory,
using BOOT_STATE_INIT_ENTRY to set up the call times.
Change-Id: I184ab234ebb9dcdeb8eece1537c12d03f227c25e
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/9780
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Remove Kconfig files that are no longer used:
src/vencorcode/Kconfig
src/soc/marvell/Kconfig
- Fix the drivers/sil/Kconfig to point to drivers/sil/3114 which had
the same code.
- Make sure all Kconfig files have linefeeds at the end. This can cause
problems, although it wasn't in this case.
- Include cpu/intel/model_65x/Kconfig which was not being included.
Change-Id: Ia57a1e0433e302fa9be557525dc966cae57059c9
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/9998
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The offset of 0x2000 was for a configuration with two separate OxPCIe
chips. The setup we support is a single chip with 8 UART pors.
Change-Id: If4be046a14464af7b90b86aca5464c6b3400dffc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8780
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fastboot data in Intel FSP project is printed by hexdump32() in dword
length. So the data length needs to be divided by 4 when printing it.
Change-Id: I959d538bd6e60282882dd138045cc730b4bd8159
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/9976
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific
directory. See follow-on patches for sharing of common code.
Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It became necessary to indicate the beginning of the normal boot
process. This patch adds a new pattern, a slow (over 2 seconds) fade
in into the 0, 87, 155 color.
BRANCH=storm
BUG=chrome-os-partner:39044
TEST=tested by the next patch.
Change-Id: Idd977688e5aa2cc55fc295072c0766526ae95016
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 577c8bd6f8c69073cfdd7acd4a87e7ae603d48e6
Original-Change-Id: I9aff3f4558e733ff2e47206075533556e400f183
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265535
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9922
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
After testing on a final assembly the PD team adjusted the wipeout
request and recovery request modes' colors.
BRANCH=storm
BUG=none
TEST=verified new colors while booting an SP5 device in recovery mode
Change-Id: I9bd2dac63b99140573533c2cda8eaa9213478ab1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 41c34a619dc0317af67907f18ee844c71a73d623
Original-Change-Id: Iab84710ebdeed35ddd4a8a163bbb6b8ac9cdb799
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262602
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9890
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Modify colors as suggested by product review folks. This is not final,
to make it easier to identify RGB locations in the hex dumps, express
their values in decimal as opposed to hex.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=verified new all three color schemes while pressing the recovery
button at boot for 20 seconds.
Change-Id: I7461acd7004e3d10cba6665a9bfe25ec8aa6f3ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a075824a1954eb5d1b65ce887304924724a6d21
Original-Change-Id: I7f5968e361333572fd1f84aa11b7150194ad902a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261690
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The originally loaded blinking program was written to allow gradual
change in LED brightness, which required controlling each LED with its
own engine. In fact there is no need in gradual brightness changes
when the firmware is controlling the ring. This allows to control all
LEDs by one engine, making the code simpler and more robust (no need
to synchronize the three engines any more).
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=verified that recovery boot WW ring patterns work as expected.
Change-Id: I89d231fb61693f4e834d8d9323ae5a7ddd149525
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 19809cf8120df8865da9b5b9e7b8e932334bf4b5
Original-Change-Id: I41038fd976dc9600f223dc0e9c9602331baf68f9
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261026
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9873
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The two controllers on the ring are programmed independently, and if
the second controller is running the old pattern while the first one
was loaded with a new pattern, there is a window of when the two
unrelated patterns might interact.
To avoid this shut down execution on both controllers before starting
downloading the new pattern code.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=verified recovery/wipeout LED ring behavior did not change.
Change-Id: I163f2983d414fe839208054ae3e9025663a46aeb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3502ca6b119c033855b45388e7b782d35cfdd82b
Original-Change-Id: I0f71f94a7e82f6c0e7f98d3aad1f93ece207248f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261200
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9872
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add compiled lp55231 code snippets to allow display certain patterns
when booting the device with the recovery button pressed.
As soon as the press is detected, the low intensify solid white
pattern is enabled. Holding recovery button long enough causes the
device transition between the wipeout requested and recovery requested
states, with the appropriate changes in the displayed pattern.
The patch also includes the source code for the LED controller as well
as instructions on how to compile and modify the code to result in
different colors, intensities, blink periods and duty cycles.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=reboot an SP5 device with the LED ring attached, keep the
recovery button pressed, observe the changes in the LED display
pattern while the device progresses through the boot sequence.
Change-Id: Ic7d45fc7c313b6d21119d4ae6adaeb4f46f7d181
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0fd6a5c0067d705197816629f41640a931d2f7cd
Original-Change-Id: Ib5cc5188c2eeedbba128101bf4092a0b9a74e155
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260670
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9870
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The patterns displayed on the LED ring while under the coreboot
control are not driven by the vboot, but by the board code instead,
The four distinct states of the LED display are:
- all off
- recovery button push detected, waiting for it to be released
- wipeout request pending - recovery button was pushed long enough
to trigger this request
- recovery request pending - recovery button was pushed long enough
to trigger this request.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=no functional changes
Change-Id: I38d9a3028013b902a7a67ccd4eb1c5d533bf071c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bdfff0e646283da6a2faaacf33e0179d2fea221c
Original-Change-Id: Ie279151b6060a2888268a2e9a0d4dc22ecaba460
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260649
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9868
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When in development environment, some SP5 devices might not have the
LED ring attached. They are still fully functional, but when booting
up are generating massive amount of i2c error messages. This patch
prevents accesses to non-existing lp55321 devices.
When loading the program into the device the vendor recommends 1 ms
delay when accessing the program control register. This patch
separates these accesses into a function and add a delay after every
access.
Another fix - advance the program address when loading multipage
programs.
Set the global variable register 3c, not used by coreboot programs, to
a fixed value. This will allow depthcharge to avoid re-initializing
the controller when not necessary.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=booted firmware on an SP5 with no LED ring attached, no excessive
error messages are generated, saw the default pattern displayed
when the recovery button is pressed during reset.
Change-Id: I6a2a27968684c40dae15317540a16405b1419e30
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e0b4c84aca27460db594da1faf627ddee56f399
Original-Change-Id: I10f1f53cefb866d11ecf76ea48f74131d8b0ce77
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260648
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9867
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a copy of the depthcharge ww ring driver implementation ported
into coreboot. The main differences are:
- direct use of the i2c driver instead of using the callback driver
description
- no dynamic memory allocation for the controller structures
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=with the rest of the patches applied the LED ring gets
initialized to the default pattern at coreboot start.
Change-Id: I6902c8b76fc173ad2ec28b8cc94695e892df338a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eda24b78f8aff311dd6296d458bdfecf26c3d65a
Original-Change-Id: I5660dc3f255aab8fbe3a87041c72916a645c193b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257730
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9858
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When RTC is not selected, return all 0.
Change-Id: I892a9489fc1d82fb8e61cf02666f797dc6412e05
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9955
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
RTC drivers now select RTC, so that code which depends on them
can implement fallback behavior for systems that lack the
hardware or driver.
Change-Id: I0f5a15d643b0c45c511f1151a98e071b4155fb5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9953
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Disable and enable GIC before switching off a CPU and after bringing
it up back respectively.
BUG=None
BRANCH=None
TEST=Compiles successfully and psci commands work for ryu.
Change-Id: Ib43af60e994e3d072e897a59595775d0b2dcef83
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5271d731f0a569583c2b32ef6726dadbfa846d3
Original-Change-Id: I672945fcb0ff416008a1aad5ed625cfa91bb9cbd
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265623
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9926
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
These Kconfig options provided a level of configurability that is
almost never necessary, so they are being moved into ordinary
preprocessor defines in elog_internal.h. The new threshold to
trigger shrinking is relative to the number of additional
(maximum-size) events that can fit, and the new target
post-shrink size is a percentage of the total ELOG area size.
BUG=chromium:467820
TEST=Add loop at the end of elog_init() that fills the ELOG area
to just below full_threshold with dummy events. Observe
successful shrinkage when the next event is logged.
BRANCH=None
Change-Id: I414c4955a2d819d112ae4f0c7d3571576f732336
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ce439361e3954a2bf5186292f96936329171cf56
Original-Change-Id: I926097f86262888dcdd47d73fba474bb2e19856a
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260501
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9869
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes quite a bit of code duplication between cpu_to_le32()
and clrsetbits_le32() style macros on the different architectures. This
also syncs those macros back up to the new write32(a, v) style IO
accessor macros that are now used on ARM and ARM64.
CQ-DEPEND=CL:254862
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu,
Storm and Urara. Booted on Jerry. Tried to compare binary images...
unfortunately something about the new macro notation makes the compiler
evaluate it more efficiently (not recalculating the address between the
read and the write), so this was of limited value.
Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b
Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254866
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a manual cleanup of all the rubble left by coccinelle
waltzing through our code base. It's generally not very good with line
breaks and sometimes even eats comments, so this patch is my best
attempt at putting it all back together.
Also finally remove those hated writel()-style macros from the headers.
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: Id572f69c420c35577701feb154faa5aaf79cd13e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 817402a80ab77083728b55aed74b3b4202ba7f1d
Original-Change-Id: I3b0dcd6fe09fc4e3b83ee491625d6dced98e3047
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254865
Reviewed-on: http://review.coreboot.org/9837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to src/:
@@
expression A, V;
@@
- writel(V, A)
+ write32(A, V)
@@
expression A, V;
@@
- writew(V, A)
+ write16(A, V)
@@
expression A, V;
@@
- writeb(V, A)
+ write8(A, V)
@@
expression A;
@@
- readl(A)
+ read32(A)
@@
expression A;
@@
- readb(A)
+ read8(A)
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6
Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254864
Reviewed-on: http://review.coreboot.org/9836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to the
directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>,
src/soc/<arm(64)-soc> and src/drivers/gic:
@@
expression A, V;
@@
- write32(V, A)
+ writel(V, A)
@@
expression A, V;
@@
- write16(V, A)
+ writew(V, A)
@@
expression A, V;
@@
- write8(V, A)
+ writeb(V, A)
This replaces all uses of write{32,16,8}() with write{l,w,b}()
which is currently equivalent and much more common. This is a
preparatory step that will allow us to easier flip them all at once to
the new write32(a,v) model.
BRANCH=none
BUG=chromium:451388
TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky.
Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24
Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254862
Reviewed-on: http://review.coreboot.org/9834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
stmicro flash chips use 2 bytes as a device id: upper byte for memory
type and lower byte for capacity. with this change, we will use all 2
bytes to identify a chip.
BUG=none
BRANCH=broadcom-firmware
TEST=booted purin and verified n25q256a was identified.
Change-Id: I8f382eddc4fa70d3deceb4f9d2e82026a7025629
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 12f70a1d4b7e1142afec9ce097c4a21b6225f66e
Original-Change-Id: Id3378a77318fabb74ddb30f1a9549010636872ba
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/199387
Original-Reviewed-by: Corneliu Doban <cdoban@broadcom.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Original-Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/251305
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9774
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Bootblock does not allow using malloc, use statically allocated chip
structures instead.
BRANCH=storm
BUG=chrome-os-partner:33489
TEST=both drivers compile when configured in, also booted whirlwind
with an STM compatible SPI NOR flash.
Change-Id: I154c33ce5fc278d594205d8b8e62a56edb4e177e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eedbb959a595e0898e7a1dd551fc7c517a02f370
Original-Change-Id: I29b37107ac1d58a293f531f59ee76b3d8c4b3e7c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/248992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some SOCs (like pistachio, for instance) provide an 8250 compatible
UART, which has the same register layout, but mapped to a bus of a
different width.
Instead of adding a new driver for these controllers, it is better to
have coreboot report UART register width to libpayload, and have it
adjust the offsets accordingly when accessing the UART.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: I30b742146069450941164afb04641b967a214d6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42
Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240027
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9738
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a function that allows reading of the status register
from the SPI chip. This can be used to determine whether
write protection is enabled on the chip.
BUG=chrome-os-partner:35209
BRANCH=haswell
TEST=build and boot on peppy
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240702
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit c58f17689162b291a7cdb57649a237de21b73545)
Change-Id: Ib7fead2cc4ea4339ece322dd18403362c9c79c7d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9fbdf0d72892eef4a742a418a347ecf650c01ea5
Original-Change-Id: I2541b22c51e43f7b7542ee0f48618cf411976a98
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241128
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9730
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A payload may want to run erase operations on SPI NOR flash without
re-probing the device to get its properties. This patch passes up
three properties of flash to achieve that:
- The size of the flash device
- The sector size, i.e., the granularity of erase
- The command used for erase
The patch sends the parameters through coreboot and then libpayload.
The patch also includes a minor refactoring of the flash erase code.
Parameters are sent up for just one flash device. If multiple SPI
flash devices are probed, the second one will "win" and its
parameters will be sent up to the payload.
TEST=Observed parameters to be passed up to depthcharge through
libpayload and be used to correctly initialize flash and do an erase.
TEST=Winbond and Gigadevices spi flash drivers compile with the changes;
others don't, for seemingly unrelated reasons.
BRANCH=none
BUG=chromium:446377
Change-Id: Ib8be86494b5a3d1cfe1d23d3492e3b5cba5f99c6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 988c8c68bbfcdfa69d497ea5f806567bc80f8126
Original-Change-Id: Ie2b3a7f5b6e016d212f4f9bac3fabd80daf2ce72
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239570
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The AS3277 RTC code seems to closely follow the corresponding Linux
driver. Unfortunately, while coreboot (and even other parts of Linux,
like mktime()) directly follows the standard IBM PC RTC time
representation (except for the BCD part), Linux' struct rtc_time decided
to use 0-based (instead of 1-based) months instead.
This patch removes the faulty month offset that was copied into our
driver so that we will generate correct timestamps again.
BRANCH=nyan
BUG=chrome-os-partner:34108
TEST=firmware_EventLog (pre-release version) gets further than before
(and then craps up on unrelated problems with suspend/resume events).
Change-Id: Ica221a8bcfd7c1c6cd7ba382d760b586d511e3a3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5b55c3f5bbecc776a71338256b910aecccac1e04
Original-Change-Id: I163fa4778ec534cd9e6f92a6b6dc55e9871a6a82
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238122
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9723
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ia8ddd689a3bf09ed68f94907ea19d4d2ee874542
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/9594
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI
read and write transactions. Limiting transfer size in the wrapper
allows to provide the API user with unlimited transfer size
transactions.
The tranfer size limitation is added to the spi_slave structure, which
is set up by the controller driver. The value of zero in this field
means 'unlimited transfer size'. It will work with existion drivers,
as they all either keep structures in the bss segment, or initialize
them to all zeros.
This patch addresses the problem for reads only, as coreboot is not
expected to require to write long chunks into SPI devices.
BRANCH=none
BUG=chrome-os-partner:32441, chrome-os-partner:31438
TEST=set transfer size limit to artificially low value (4K) and
observed proper operation on both Pistachio and ipq8086: both
Storm and Urara booted through romstage and ramstage.
Change-Id: Ibb96aa499c3eec458c94bf1193fbbbf5f54e1477
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4f064fdca5b6c214e7a7f2751dc24e33cac2ea45
Original-Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232239
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9571
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As per the TCG PC Client TPM Interface Specification v1.2, bit 7 of the
access register (tmpRegValiSts bit) stays "0" until the TPM has complete
through self test and initialization. This bit is set "1" to indicate that
the other bits in the register are valid.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:35328
TEST=Booted up storm p0.2 and whirwind sp3.
Verified TPM chip is detected and reported in coreboot logs.
Change-Id: I1049139fc155bfd2e1f29e3b8a7b9d2da6360857
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 006fc93c6308d6f3fa220f00708708aa62cc676c
Original-Change-Id: I9df3388ee1ef6e4a9d200d99aea1838963747ecf
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242222
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9567
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
CL:243671 moved the initialization of elog_initialized around, which is
now unfortunately so late that the ELOG_TYPE_BOOT event gets omitted
because the code believes the log to be broken at that time. Good thing
we now have a FAFT test for these things that I had of course been too
lazy to run. -.-
The real reason for moving that line was to put it after any point in
elog_init() that could still error out. The problem is that we might add
the "cleared" event before we try to shrink (which can fail and cause an
error)... but those two things cannot happen at the same time, so it
should be okay to flip them around and mark the elog as initialized in
between.
BRANCH=none
BUG=chrome-os-partner:35940
TEST=Ran firmware_EventLog on a Pinky, manually confirmed that I once
again get "System boot" events.
Change-Id: I12dcf4a8e47d302f6cd317194912c31db502bbaf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4a1c0b861017ca25229b1042c4b37dda33e869f9
Original-Change-Id: I4103779790e1a8a53ecabffd4316724035928ce6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246715
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9503
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The elog driver has a really stupid bug that checks a result which is
stored in an unsigned variable for < 0. Surprisingly GCC does not catch
this nonsense right now, and I spent an hour trying out different
warning options without finding one that doesn't also bring a load of
stupid and unavoidable false positives (the biggest offender being
-Wtype-limits, which does exactly what we'd want except for flagging
things like if ((u8)var >= CONFIG_VAR_MIN) where the VAR_MIN Kconfig may
or may not be 0).
So, the only thing we can do is fix this one and wait for the next time
something like that blows up. -.- Also change some more code to make the
behavior more explicit (the old code already intended to work this way
since flash_base is statically initialized to 0, never assigned in the
error path and checked later in elog_init()... but there was an error
message that incorrectly claimed a different fallback behavior, and
explicitly assigning the values makes this easier to see). Finally, add
another state to the elog_initialized variable to avoid trying to
reinitialize a broken eventlog on every event (if it doesn't work the
first time, chances are that it won't work later on during the same boot
either).
BRANCH=None
BUG=chrome-os-partner:35940
TEST=Flashed Jerry with RO 6588.4 and RW 6588.23, observed how it now
cleanly enters recovery mode without blowing its bootblock away with
stray eventlog entries.
Change-Id: I0e5348ba961ce4835c30f7108a2453522095f2ee
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f9798dbf0c2b2e337062ecd84d0f45434343c0d9
Original-Change-Id: I4d93f48d2d01d75a04550d419e023aa42ca95a7a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243671
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9557
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TPM driver by default allocates a 4K transfer buffer on the stack,
which leads to lots of fun on boards with 2K or 3K stack sizes. On
RK3288 this ends up writing over random memory sections which dependent
on the memlayout of the day might contain timestamp data (no big deal)
or page tables (-> bad time).
This patch fixes the problem by reducing the buffer size to slightly
above 1K, which still seems to work as far as I can tell. There was
already some really odd code that #undef'ed this value and redefined it
with the lower number in one .c file (unfortunately not the one with the
buffer declaration), with no explanation whatsoever... I'm removing that
and just assume the smaller value will be fine for everything.
BRANCH=veyron
BUG=None
TEST=Booted Pinky and Falco.
Change-Id: I440a5662b41cbd8b7becab3113262e1140b7f763
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3d3288041b6629b7623b9d58816e782e72836b81
Original-Change-Id: Idf80f44cbfb9617c56b64a5c88ebedf7fcb4ec71
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236976
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is being triggered because the base address is added, but
there is nothing that needs done with it in set_resources step
and the ERROR message is tripping suspend resume test scripts.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=boot on samus and check for ERROR strings,
successfully run suspend_stress_test without failures
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231603
(cherry picked from commit bb789492965d92e309a913dc7b9f09f7036c5480)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I565c8af954f1c5a406d2c65f01c274e9259e43ec
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9062734d884f814dc880589ee615b4d7e1fdc61a
Original-Change-Id: I2b5f44795f1ee445d509b29bd56f498aea7b7fe3
Original-Reviewed-on: https://chromium-review.googlesource.com/231604
Original-Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9476
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds a ramstage driver for the TPM and allows the interrupt
to be configured in devicetree.cb.
The interrupt vector is set like other PNP devices, and the
interrupt polarity is set with a register configuration variable.
These values are written into locality 0 TPM_INT_VECTOR and
TPM_INT_ENABLE and then all interrupts are disabled so they are
not used in firmware but can be enabled by the OS.
It also adds an ACPI device for the TPM which will configure the
reported interrupt based on what has been written into the TPM
during ramstage. The _STA method returns enabled if CONFIG_LPC_TPM
is enabled, and the _CRS method will only report an interrupt if one
has been set in the TPM itself.
The TPM memory address is added by the driver and declared in the
ACPI code. In order to access it in ACPI a Kconfig entry is added for
the default TPM TIS 1.2 base address. Note that IO address 0x2e is
required to be declared in ACPI for the kernel driver to probe correctly.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=manual testing on samus:
1) Add TPM device in devicetree.cb with configured interrupt and
ensure that it is functional in the OS.
2) Test with active high and active low, edge triggered and level
triggered setups.
3) Ensure that with no device added to devicetree.cb that the TPM
is still functional in polling mode.
Change-Id: Iee2a1832394dfe32f3ea3700753b8ecc443c7fbf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: fc2c106caae939467fb07f3a0207adee71dda48e
Original-Change-Id: Id8a5a251f193c71ab2209f85fb470120a3b6a80d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226661
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9469
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This moves the LPC TPM driver to drivers/pc80/tpm so it can
be turned into a ramstage driver with a chip.h
It includes no other changes yet.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=emerge-samus coreboot
Change-Id: Iac83e52db96201f37a0086eae9df244f8b8d48d9
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: be2db391f9da80b8b75137af0fe81dc4724bc9d1
Original-Change-Id: I60ddd1d2a3e72bcf169a0b44e0c7ebcb87f4617d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226660
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9468
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TPS65913 PMIC has an RTC built into it. This change adds
a driver for it which implements the new RTC API.
BUG=chrome-os-partner:33764
BRANCH=None
TEST=Compiles and boots to kernel prompt on ryu. Timestamps for event log
verified across multiple boots.
Change-Id: I49ec9b78afc53f1cbd4be09e448cdae6077fb710
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c16c11e620c830e7a73a2a24fe4823ccea0f3c39
Original-Change-Id: If1d549ea2361d0de6be75fd24b9e9810a6df7457
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229414
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9425
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With kconfig understanding wildcards, we don't need
Kconfig files that just include other Kconfig files
anymore.
Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9298
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In commit 72a8e5e751 the
Makefile's were updated to use named types for cbfs
file addition. However, the call sites were not checked to
ensure the types matched. Correct all call sites to use the
named types.
Change-Id: Ib9fa693ef517e3196a3f04e9c06db52a9116fee7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9195
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some of the files which include cbfs_core.h don't even need
the header definition while others just need the cbfs API
which can be obtained from cbfs.h.
Change-Id: I34f3b7c67f64380dcf957e662ffca2baefc31a90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9126
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
These binaries were being added to CBFS using hexadecimal values instead
of the CBFS binary type names. The same value was being used in
different places for different things.
For example, the value 0xAB is used for SPDs, MRC & FSP binaries.
This patch uses CBFS type names instead of hex values everywhere a
hex value was previously used.
Change-Id: Id5ac74c3095eb02a2b39d25104a25933304a8389
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8978
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
The GIC is ARM's "Generic Interrupt Controller". This
change essentially implements the rudimentary support
for a GICv2 implementation that routes all interrupts
to Group1. This should also work for GICv1 with security
extensions.
BUG=chrome-os-partner:31945
BRANCH=None
TEST=Built and booted kernel using the code.
Change-Id: I9c9202c1309ca9e711e00d742085a6728552c54b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d1cd9b6b76035af107b7dc876f90777698162d34
Original-Change-Id: I4c5b84bfe888ac33fa01c8d64a3dffe1b5ddc823
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217512
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9075
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
with COMMON_CBFS_SPI_WRAPPER enabled
Change-Id: I3ce78c8afc5f7d8ce822bbf8dd789c0c2ba4b99c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b72693c96f7d8ce94ce6fe12b316d5b88fded579
Original-Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223751
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8772
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
GD25LQ64C and GD25LB64C have the same ID and settings.
BUG=chrome-os-partner:25907
BRANCH=baytrail
TEST=Boot with GD25LQ64 and check MRC data save/restore works.
Change-Id: I8a4aa7cabd9a7657c2f0bae255a87341db3f1061
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20b5896adbbbdedcb1b7de435466dcc6bfa703cb
Original-Change-Id: I86d1e69552b6000faa9e0523356e27d7e2a6a6db
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193238
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8770
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This allows us to use the driver before ramstage.
BRANCH=none
BUG=none
TEST=built and booted on Pinky
Change-Id: I0700388b0e4e0562e3c0a52863c8357097bfd8d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cd57587dab74de509d5c50cfc1ad337d765af6c8
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I0ce901331e401274254b8889484ffb41359119fa
Original-Reviewed-on: https://chromium-review.googlesource.com/235864
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8774
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When the driver is included in bootblock, malloc() is not available.
Come to think of it, it is perfectly fine to use a statically
allocated structure for the SPI device descriptor - coreboot is
unlikely to require concurrent support of multiple SPI devices of the
same kind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=bootblock on the FPGA board recognizes the installed Winbond
device:
coreboot-4.0 bootblock Tue Nov 11 07:27:24 PST 2014 starting...
SF: Detected W25Q16 with page size 1000, total 200000
Change-Id: Iea1936a219d38848580a10f75eb8bbcab17e6507
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0b4082442aa526d387a80cb5872d78670e6b468b
Original-Change-Id: Iaa69d610ef18e69b1ae5ade2d958f9fe1595a723
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228959
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8771
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
S25FL116K family uses the first 3 bytes in response to a legacy identification
command (9f) while previously supported models use the last 4 bytes. This change
defines identify functions to allow both types to be handled correctly.
BUG=none
BRANCH=tot
TEST=verified romstage is loaded on cosmos development board.
Change-Id: I1970a9af17e81299fada5029724d405de4022156
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 65ff436db2355cb68a766a3dedbcd7e2f765e6db
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Icdd2645e356652672c4482e7b805da1bc0f21e71
Original-Reviewed-on: https://chromium-review.googlesource.com/234431
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8773
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On ChromeOS devices the ELOG section size and offset are
provided by the FMAP, rather than KConfig. Some upstream
refactoring broke compilation in that case.
Change-Id: I8b08daa327726218815855c7c2be45f44fcffeed
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This was missed in commit bde6d309 as the driver is not enabled
in any configuration by default.
Change-Id: I3d886531f5bcf013fc22ee0a1e8fa250d7c4c1a4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8660
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add a new driver for Intel i210 MACPHY with the goal to
update the MAC address in i210 if it is found
during PCI scan.
Change-Id: I4d4e797543a9f278fb649596f63ae8e1f285b3c3
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/8404
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
xgifb_probe() doesn't own the object it tries to free
in its error code path, potentially leading to a
double-free in xgi_z9s_init().
Since we don't actually implement free, it doesn't matter
too much, but let's keep things proper.
Change-Id: I70c8f395fd59584664040ca6e07be56e046c80fc
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/8506
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
That's just how we roll.
Change-Id: I47ef62476703fdf2544d9cd77c30ae12452afeae
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8514
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
If function cmos_init() was called with parameter invalid
set, this indicates, that the caller has found a power
loss event in the RTC registers. In this case, we need to
load the default date and time because it can be corrupted.
Change-Id: Ib8d58a14da0182ceb8167e67440a0f1ea2a20eb7
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/8373
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Fan 2 and Fan 3 were inexplicably set to zero after device
setup.
Change-Id: I37945745dbfaf33eb28808d85cdf75dca401e44b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8520
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Originally, axp209_(read|write) accessors relied on i2c_(read|write)
to return the number of bytes transferred. This was changed in
* cdb61a6 i2c: Replace the i2c API.
to return an error code or 0 on success. This caused the AXP209 check
to fail. Fix the accessors to account for this new behavior.
Change-Id: Ib0f492bd52260d224d87f8e8f2d3c1244d1507df
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8432
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
In specific configurations, such as homogeneous supercomputing systems,
changeable NVRAM parameters are more of a liability than a useful tool.
This patch allows a coreboot image to be compiled that will always set
the NVRAM parameters to their default values, reducing maintainance
overhead on large clusters.
Change-Id: Ic03e34211d4a58cd60740f2d9a6b50e11fe85822
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8446
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On x86, change the type of the address parameter in
read8()/read16/read32()/write8()/write16()/write32() to be a
pointer, instead of unsigned long.
Change-Id: Ic26dd8a72d82828b69be3c04944710681b7bd330
Signed-off-by: Kevin Paul Herbert <kph@meraki.net>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7784
Tested-by: build bot (Jenkins)
Probing is done by reading the ID register and comparing it to a known
value. When there is a mismatch, print an error.
Change-Id: I36fb1fe9b56e97660556dcb27be25bfe5129ad73
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8433
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Two source files were accidently marked executable. Switch them back to
mode 644 (rw-r---r--)
Change-Id: Ic96f6e5e9a05cbffb65cdfb627023d04d3866dc9
Signed-off-by: Stefan Reinauer <stepan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8426
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Because the pointer to the FSP HOB list is now being saved, we can
use that to find the top of usable memory. This eliminates the need
to hardcode the size of the FSP reserved memory area.
Tested on minnowboard max for baytrail.
The HOB structure used does not seem to be present for the rangeley
or ivybridge/pantherpoint FSPs. At the very least, the GUID is not
documented in the integration guides.
Change-Id: I643e57655f55bfada60075b55aad2ce010ec4f67
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8308
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
cmos_init() had layers of preprocessor directives, which resulted in
a complete mess. Refactor it to make use of the IS_ENABLED() macro.
This improves readability significantly.
One of the changes is to remove in inline stub declaration of
(get|set)_option. Although that provided the ability for the compiler
to optimize out code when USE_OPTION_TABLE is not selected, there is
no evidence that such savings are measureable.
Change-Id: I07f00084d809adbb55031b2079f71136ade3028e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8306
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
TEST: Booted KFSN4-DRE with on-board XGI Volari Z9s
Initial text from coreboot appeared, and the Linux
console was displayed immediately at the start of
kernel initialization. After boot was complete
the text mode console continued to behave normally.
SeaBIOS does not currently make use of the legacy
VGA text-mode display.
Change-Id: I2177a1d00e6f07db661dd99fe0184e2c228404d1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8360
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add native XGI Z9s framebuffer support to coreboot
XGI initialization code largely taken from Linux 3.18.5
TEST: Booted KFSN4-DRE with XGI Volari Z9s into SeaBIOS
with SeaVGABIOS enabled. Text appeared correctly on screen
and interaction with graphical comboot menu was successful.
However, Linux cleared the framebuffer on boot, rendering the
screen useless until Linux loaded its native xgifb driver.
Change-Id: I606a3892849fc578b0c4d74536aec0a0adef3be3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8331
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch clears the CAR area. The FSP loads the entire CAR area with a
pattern instead of clearing it. At least the cbmem area needs to be
cleared or cbmem will not use it.
Change-Id: I829ddc26133353a784dfc01729af9b3bf427e889
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8195
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add a function to retrieve the location of the CAR temporary memory
that was saved by the FSP into the HOB structure.
Change-Id: I2635de5207cd699740721d333a7706425b837651
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8194
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Add new functions to:
- Compare two GUIDs
- Find a hob based on its GUID
- Print information about GUID_EXTENSION type HOBs
- Print a GUID's address and value
Change-Id: I89377ec8ab7d98fe7dc129097e643aac061ab3a3
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8066
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The correct type-signature of 'do_smbus_write_byte' is:
int do_smbus_write_byte(u32 smbus_io_base, u32 device, u32 address, u8 val)
and so storing the return type in a 'u32' is inappropriate, leading
to a tautological compare of 'ret < 0' and 'err < 0'.
Change-Id: I65486df7156c70af84fa00c336142d9a45998620
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/8209
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This makes it so that we always log the generic "system boot" event.
If boot count support has not been implemented, fake it.
BUG=chrome-os-partner:28772
BRANCH=nyan
TEST=booted on Big, ran "mosys eventlog list" and saw
"System boot" event logged with boot count == 0
Original-Change-Id: I729e28feb94546acf6173e7b67990f5b29d02fc7
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/204525
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 2598dc63ddc0d76bcdf9814cadd4c75653fd9832)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieb4e2e36870e97d9c5f88f0190291863a65a6351
Reviewed-on: http://review.coreboot.org/8142
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Storm devices use more recent Spansion flash, add its description to
the table of supported devices.
BUG=chrome-os-partner:29871
TEST=the updated firmware boots all the way to depthcharge
Original-Change-Id: I81661c01ae679d49918e40d940b8d348f3081f9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/205182
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit ea7bb1cf65b7130164b869fef09c55138100206b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I1e0136a5c575951b4e464aab0f380f19e886a84f
Reviewed-on: http://review.coreboot.org/8146
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These files were trying to document the parameters, but didn't have
the syntax quite right. Change the comments from @varname to
@param varname as required by doxygen.
Change-Id: I63662094d3f1686e3e35b61925b580eb06e72e28
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8100
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The FSP uses a lot of UEFI HOB (Hand Off Block) functions for reporting
and passing information to coreboot. These seem to me like they should
be in their own file, so I'm splitting them out of fsp_util.c. I'll
be adding a couple more functions in the next patch.
These functions should all be compliant to the Hand Off Block spec.
Change-Id: Ie8bbc0a9277b9484f13dd077b3a52e424a8600fe
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8065
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Re-factor to_flash_offset() into 'spi_flash.h' header. Motivated by
Clang complaining that the function 'to_flash_offset' is unused.
Change-Id: Ic75fd2fb4edc5e434c199ebd10c7384d197e0c63
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7519
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Original-Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197798
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 493b05e06dd461532c9366fb09025efb3568a975)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4fad296ecfeff8987e4a18054661190239245f32
Reviewed-on: http://review.coreboot.org/7891
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The AS3722 PMIC, like many PMICs, has an RTC built into it. This change adds a
driver for it which implements the new RTC API.
BUG=None
TEST=Built and booted with the event log code modified to use this interface.
Verified that events had accurate timestamps.
BRANCH=nyan
Original-Change-Id: I400adccbf84221dcba8d520276bb91b389f72268
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197796
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 011e49beba3a99abbd122866891e3c20bf1188d2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ibc1d342062c7853a30d195496c077e37a02b35b0
Reviewed-on: http://review.coreboot.org/7890
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch has a rather twisted history. It was originally split off
from a chromium patch, which moved ALTCENTURY to Kconfig. However,
since we have no user without ALTCENTURY, we've agreed that the best
way to proceed is to eliminate the non-ALTCENTURY case entirely.
The old commit message and identifiers are kept below for reference:
The availability of "ALTCENTURY" is now set through a kconfig
variable so it can be available to the RTC driver without having to have a
specialized interface.
BUG=None
TEST=Built and booted on Link with the event log code modified to use the RTC
interface. Verified that the event times were accurate.
BRANCH=nyan
Original-Change-Id: Ifa807898e583254e57167fd44932ea86627a02ee
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197795
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
This is the second half the following patch.
(cherry picked from commit 9e0fd75142d29afe34f6c6b9ce0099f478ca5a93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8e871f31c3d4be7676abf9454ca90808d1ddca03
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7987
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
BUG=chrome-os-partner:25907
BRANCH=baytrail(rambi)
TEST=Read and write MRC and ELOG on Glimmer with Eon device.
Original-Change-Id: If883ff6eb14dd49a06f57a01ca61661854ded78d
Original-Reviewed-on: https://chromium-review.googlesource.com/198324
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Marc Jones <marc.jones@se-eng.com>
Original-Tested-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 536c34c2d92178f4e62b8ca7cfffceaf80a305f6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I199451ed2b29c55bfb5e1487afa8cf3b9978e63e
Reviewed-on: http://review.coreboot.org/7935
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The Eon SPI25 code had a number of issues:
- fix page write calculation
- fix erase segment
- fix id check
- fix sector size
- make commands EN25 generic
This makes the code similar to other SPI25 devices used in coreboot.
BUG=chrome-os-partner:25907
BRANCH=baytrail(rambi)
TEST=Read and write MRC and ELOG on Glimmer with Eon device.
Original-Change-Id: I7667eab28b850790d92a591c869788d51c26a56c
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/198323
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Marc Jones <marc.jones@se-eng.com>
Original-Tested-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 2ee0da695bf6a6c6aedc0dd2b3a3b7c9c3165bca)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8917e778cd62f3745189336d23c0c6118887d893
Reviewed-on: http://review.coreboot.org/7934
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Since the same driver is going to be used at all coreboot stages, it
can not use malloc() anymore. Replace it with static allocation of the
driver container structure.
The read interface is changed to spi_flash_cmd_read_slow(), because of
the problems with spi_flash_cmd_read_fast() implementation. In fact
there is no performance difference in the way the two interface
functions are implemented.
BUG=chrome-os-partner:27784
TEST=manual
. with all patches applied coreboot proceeds to attempting to load
the payload.
Original-Change-Id: I1c7beedce7747bc89ab865fd844b568ad50d2dae
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197931
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 57ee2fd875c689706c70338e073acefb806787e7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9d9e7e343148519580ed4986800dc6c6b9a5f5d2
Reviewed-on: http://review.coreboot.org/7933
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197800
Original-Tested-by: Vadim Bendebury <vbendeb@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41
Reviewed-on: http://review.coreboot.org/7932
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Add the device ID definitions and properties for the SPI chip used on
the AP148 board (Google Storm).
BUG=chrome-os-partner:27784
TEST=manual
. with the rest of the patches applied AP148 boots all the way to
trying to read the payload.
Original-Change-Id: I5a0e5c9d3cc9ea81bc5227c0fbc1d0a5fc7bec27
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197895
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a7c69981b18ac6b1158273596b94df0def65963d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I14e2f4f8f691a7db6ed596a3440914e08680867b
Reviewed-on: http://review.coreboot.org/7931
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This CL adds an API for RTC drivers, and implements its two functions,
rtc_get and rtc_set, for x86's RTC. The function which resets the clock when the
CMOS as lost state now uses the RTC driver instead of accessing the those
registers directly.
BUG=None
TEST=Built and booted on Link with the event log code modified to use
the RTC interface. Verified that the event times were accurate.
BRANCH=nyan
Original-Change-Id: Ifa807898e583254e57167fd44932ea86627a02ee
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197795
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
This is the first half of the patch.
(cherry picked from commit 9e0fd75142d29afe34f6c6b9ce0099f478ca5a93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I159f9b4872a0bb932961b4168b180c087dfb1883
Reviewed-on: http://review.coreboot.org/7889
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This cleans up a mis-merge in elog.c and puts the following
change back:
drivers/elog: Unmangle header include out of pre-proc cond
commit a3119e5835
Change-Id: Iafbbd381efdb103717022d2a3c342da376a9428f
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit 474313d1b6.
This reverted commit was applied out of sequence and there are a number
of dependencies that need to be in place prior to adding it. Remove it
for now.
Change-Id: If80c40867098dee2feff2b9a1d824558f4d7028d
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This consolidates all calls to spi_claim_bus() and spi_release_bus()
to a single location where spi_xfer() is called. This avoids confusing
(and potentially redundant) calls that were being done throughout the
generic spi_flash.c functions and chip-specific functions.
I don't think the current approach could even work since many chip
drivers assert /CS once and then issue multiple commands such as page
program followed by reading the status register. I suspect the reason
we didn't notice it on x86 is because the ICH/PCH handled each
individual command correctly (spi_claim_bus() and spi_release_bus()
are noops) in spite of the broken code.
BUG=none
BRANCH=none
TEST=tested on nyan and link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3257e2f6a2820834f4c9018069f90fcf2bab05f6
Original-Reviewed-on: https://chromium-review.googlesource.com/194510
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit d3394d34fb49e9e252f67371674d5b3aa220bc9e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieb62309b18090d8f974f91a6e448af3d65dd3d1d
Reviewed-on: http://review.coreboot.org/7829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a wrapper function and a Kconfig variable to differentiate
between SPI controllers which use atomic cycle sequencing versus
those where the transaction sequence is controlled manually. Currently
this boils down to x86 vs. non-x86.
Yes, it's hideous. The current API only worked because, for better or
worse, x86 platforms have been homogeneous in this regard since they
started using SPI as an alternative to FWH for boot flash. Now that
we have non-x86 platforms which use general purpose SPI controllers,
we should overhaul the entire SPI infrastructure to be more adaptable.
BUG=none
BRANCH=none
TEST=tested on nyan and link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: If8ccc9400a9d04772a195941a42bc82d5ecc1958
Original-Reviewed-on: https://chromium-review.googlesource.com/195283
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4170c59d06206667755402712083452da9fcd941)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I54e2d3d9f9a0153a56f7a51b80f6ee6d997ad358
Reviewed-on: http://review.coreboot.org/7828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Original-Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197798
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 493b05e06dd461532c9366fb09025efb3568a975)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8481adde86d836b5f0b019c815bada6d232a4186
Reviewed-on: http://review.coreboot.org/7833
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This attempts to isolate/fix some x86-isms:
- Translate flash offset to memory-mapped address only on x86.
- Guard ACPI-dependent line of code
- Use a Kconfig variable for SPI bus when probing the flash rather
than assuming the bus is always on bus 0.
- Zero-out timestamp on non-x86 until we have a better abstraction.
(note: this is based off of some of Gabe's earlier work)
BUG=none
BRANCH=none
TEST=needs testing
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I887576d8bcabe374d8684aa5588f738b36170ef7
Original-Reviewed-on: https://chromium-review.googlesource.com/191203
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 1fc7a75f8c072098e017104788418aeed0705e93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ida4b211cf21ecdde9745d4dbef6a63ffb9fbba8d
Reviewed-on: http://review.coreboot.org/7832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This severs a dependency the eventlog code has on initializing
chipset/SoC SPI controller. Currently elog_init() calls spi_init()
as a catch-all. This worked for x86 since the SPI controller is only
used for one thing on existing platforms. As we add eventlogging
support to non-x86 platforms we need to consider the more generalized
case where the assumptions about how SPI works on x86 are no longer
valid.
BUG=none
BRANCH=none
Signed-off-by: David Hendricks <dhendrix@chromium.org>
TEST=built and booted on Link, Beltino and Rambi. See below for
"mosys eventlog list" output on Link showing boot and suspend/resume
events (including lid close/open) added successfully.
localhost ~ # mosys eventlog list
0 | 2014-04-14 13:52:44 | Log area cleared | 4096
1 | 2014-04-14 13:52:44 | System boot | 50
2 | 2014-04-14 13:52:44 | EC Event | Power Button
3 | 2014-04-14 13:52:44 | SUS Power Fail
4 | 2014-04-14 13:52:44 | System Reset
5 | 2014-04-14 13:52:44 | ACPI Wake | S5
6 | 2014-04-14 13:53:25 | ACPI Enter | S3
7 | 2014-04-14 13:53:35 | ACPI Wake | S3
8 | 2014-04-14 13:53:35 | Wake Source | RTC Alarm | 0
9 | 2014-04-14 13:53:49 | ACPI Enter | S3
10 | 2014-04-14 13:54:00 | EC Event | Lid Open
11 | 2014-04-14 13:54:00 | ACPI Wake | S3
12 | 2014-04-14 13:54:00 | Wake Source | GPIO | 15
Original-Change-Id: I26e25c0a856f7b8db5ab6b8e7e1acae291d2eadc
Original-Reviewed-on: https://chromium-review.googlesource.com/194526
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2971d20b6ebdd9803b05ccbbaeefe1bde1a21af4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia5f2913fd8e4fee6e741e6d1e39d32bb86525cb3
Reviewed-on: http://review.coreboot.org/7831
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Similar to the W25Q64DW, the W25Q32DW has basically the same
attributes as the earlier W25Q32 parts but with a different
value in the MSB of the ID.
BUG=none
BRANCH=none
TEST=tested on nyan, now SPI flash commands actually work.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I697768a443c98515d893f9cf8f8b4258ae0f159d
Original-Reviewed-on: https://chromium-review.googlesource.com/191205
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 35f03f4f4f21c470d172ce7cce257517b959346d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I73606737835e4f8ea00d2c331ca37957e4abd953
Reviewed-on: http://review.coreboot.org/7755
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The old print simply said "Got idcode". This makes it actually
display what it got.
BUG=none
BRANCH=none
TEST=tested on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I8f1c8fde6e4ac00b12e74f925b7bcff83d1f69f3
Original-Reviewed-on: https://chromium-review.googlesource.com/191204
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 5f13789be77d038d3c1602037afe29a0351f72ee)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I65d0d51c17b3bda62351532aac1756b630433ea3
Reviewed-on: http://review.coreboot.org/7754
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Original-Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193561
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 00c423fb2c06c69d580ee3ec0a3892ebf164a5fe)
This cherry-pick required additional changes to the following:
src/cpu/allwinner/a10/twi.c
src/drivers/xpowers/axp209/axp209.c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I691959c66308eeeec219b1bec463b8b365a246d7
Reviewed-on: http://review.coreboot.org/7751
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This replaces a hard-coded bus number of 0 with a Kconfig variable,
CONFIG_BOOT_MEDIA_SPI_BUS. This removes an assumption made for x86
where this value is always 0 and makes it easy to add support for
other platforms where the bus number for the backing SPI flash is
more arbitrary.
BUG=none
BRANCH=none
TEST=tested on Nyan (bus=4) and Link (bus=0)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I1e878a1628af7f4ccc2f39a70b2190192767e536
Original-Reviewed-on: https://chromium-review.googlesource.com/194854
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 371c6c14d8d4b98004eebce7049a88a219682bc4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie105b4654e028098f2137c96e4309b8d85f096df
Reviewed-on: http://review.coreboot.org/7753
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For some UART hardware registers are 32 bits wide, so we will need
base_port + reg << 2 instead. Prepare for that change and unification of
MMIO between ARM and x86.
Change-Id: I5fa2c2f7ee4872499a01754c1ba872a8addf499c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7793
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Depending on the platform the underlying regions vboot requires
may not be accessible through a memory-mapped interface. Allow
for non-memory-mapped regions by providing a region request
abstraction. There is then only a few touch points in the code to
provide compile-time decision making no how to obtain a region.
For the vblocks a temporary area is allocated from cbmem. They
are then read from the SPI into the temporarily buffer.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted a rambi with vboot verification.
Original-Change-Id: I828a7c36387a8eb573c5a0dd020fe9abad03d902
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190924
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit aee0280bbfe110eae88aa297b433c1038c6fe8a3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia020d1eebad753da950342656cd11b84e9a85376
Reviewed-on: http://review.coreboot.org/7709
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is not actually required. Tested on 'minnow max' hardware as
well as compared the asm of the optimized and non-optimized. Thanks Martin!
Change-Id: I06e71876c3a3a15101013623797c2ebbf449756d
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Found-by: Clang
Reviewed-on: http://review.coreboot.org/7694
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move the Kconfig variable into a .h file - this does not need to be
in Kconfig.
Change-Id: I1db20790ddb32e0eb082503c6c60cbbefa818bb9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7646
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add macros and #defines for working with the UPD data. This makes
the code look much cleaner.
Remove the UPD_ENABLE / UPD_DISABLE from fsp_rangeley/chip.h and include
the fsp_values header instead. This fixes a conflict.
Change-Id: I72c9556065e5c7461432a4593b75da2c8a220a12
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7487
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7d8922d1812814ea2ebd72aaf5b5e28dc592bfb3
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Thereby making consistent with other i2c drivers
Change-Id: I5ddc9d98fbbc1db68a933e3b9a6b92f309b72c41
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Not sure what this is about.
Required for BeagleBone (not Black) with HUB in the middle, also
old FX2 senses extra reset if we do this.
Change-Id: I86878f8f570911ed1ed3ec844c232ac91e934072
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3868
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
According to EHCI specification, host controller software stops
the USB Reset condition by writing PORT_RESET=0. Software then
poll-waits this bit until controller hardware has completed USB
Reset sequence and read returns with PORT_RESET==0.
Change-Id: I6033c4d904c2af9eb16f5f3c1eb825776648cc1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3863
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Organized such that it is easy to support devices that do not
export special Debug Descriptor. Some of these can still work
in a fixed configuration and/or require additional initialisation
for UART clocks etc.
Change-Id: Id07fd6b69007332d67d9e9a456f58fdbca1999cd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7209
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
We only reference with ehci_caps and ehci_regs during initialisation,
no need to carry those around.
When EHCI BAR is relocated during PCI allocation, record the changed
address even if usbdebug is not enabled. Use the DBGP_EP_VALID flags
to determine if endpoints have been configured or not.
Change-Id: Idfd52edf7c2fc25b1b225985462ac488264e4c6d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7207
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
On entry to ramstage CBMEM is looked for a copy of an already initialized
EHCI debug dongle state. If a copy is found, it contained the state before
CAR migration and the USB protocol data toggle can be out of sync. It's an
even/odd kind of a parity check, so roughly every other build would
show the problem as invalid first line: 'ug found in CBMEM.'
After CAR migration, re-direct the state changes to correct CBMEM table.
Change-Id: I7c54e76ce29af5c8ee5e9ce6fd3dc6bdf700dcf1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7206
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Provide dummy ramstage symbol to keep the linker happy. Borked
in commit fd95624
Change-Id: I2c49e82fec8eb936390cc3b30698f1bf73968c99
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7548
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
As build.h is an auto-generated file it was necessary to add it as
an explicit prerequisite in the Makefiles. When this was forgotten
abuild would sometimes fail with following error:
fatal error: build.h: No such file or directory
Fix this error by compiling version.c into all stages.
Change-Id: I342f341077cc7496aed279b00baaa957aa2af0db
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7510
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The sequence of bytes to create a method is used several times in codebase.
Put it into a function with logical arguments rather than duplicating magic
bytes everywhere.
Change-Id: I2c33fa403832eb1cfadfbf8d9adef5b63fb9cb24
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7348
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
The sequence of bytes to create a method is used several times in codebase.
Put it into a function with logical arguments rather than duplicating magic
bytes everywhere.
Change-Id: I0e55d8dc7d5e8e92a521c7a83117c470d0614008
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7347
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
'%02hx' is unsigned short, where as the argument is typed as
uint8_t and so '%02hhx' is actually correct here.
Found-by: Clang
Change-Id: I40c48dcecf12845f4708e511236184908e90fb56
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7428
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Just when you thought you found them all..
Reduces loc and makes NOP's explicit.
Change-Id: I416e0468b7f2f462c940daae695d67fb409aa4c6
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7350
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Most of the code related to the mc146818 is not related to the RTC and is
really for managing the CMOS storage. Since we intend to add a generic API
for RTC drivers it's inconvenient for those functions to have an rtc_ prefix.
This CL renames those functions so they start with cmos_ instead. There are
some places where rtc_init was called with a comment that says something about
starting the RTC. That wasn't correct before (the RTC is always running), but
it looks a little odd now that the function is called cmos_init.
This CL also opportunistically cleans up some style problems in this file.
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197794
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9a9ad24888b185fb58965457704e326bb508d788)
Removed the addition of stdint.h to mc146818rtc.h since
types.h is now included. Changed rtc_init to cmos_init for
fsp_bd82x6x, fsp_rangeley, fsp_baytrail, ibexpeak, vortex86ex.
Change-Id: Id4b9f6bea93e8bd5eaef2cb17f296adb9697114c
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6977
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Not doing so makes it fail when run at high frequency.
Change-Id: I1cfb69c55f03cb90f66f437289803d897a1aad5c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/191812
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 04452441d2bfe2cacd3e0b6990c0e9261b5350d1)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7007
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Support added for Micron N25Q128 SPI flash, which has
the same manufacturer id as ST Micro. Jedec ID =
0x20 0xBB 0x18. Since existing stmicro.c only compares
the last device id byte, this flash is mistakenly
identified as M25P128, which has ID = 0x20 0x20 0x18.
To handle this situation and avoid breaking code for
existing devices, a two byte .id member is added.
New devices should be added to the beginning of the
flash table array with .idcode = STM_ID_USE_ALT_ID and
.id = the two byte jedec device id.
A 4KB subsector erase capability is added and used for
this new device. It requires using a different SPI
op-code supported by adding .op_erase member. Previous
devices defined in stmicro.c are assigned their original
op-code for 64KB sector erase.
N25Q128 is now working on a custom designed Bayley Bay
based board. Tested by verifying the MRC fastboot cache
is successfully (re)written. Note that previous devices
were not retested.
Change-Id: Ic63d86958bf8d301898a157b435f549a0dd9893c
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7077
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
We had lots of casts that caused warnings when compiling on RISCV.
Clean them up.
Change-Id: I46fcb33147ad6bf75e49ebfdfa05990e8c7ae4eb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7066
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds S3 Suspend / Resume support to Intel's Bay Trail FSP
It is based on the "src/soc/intel/baytrail/romstage/romstage.c"
implementation.
Change-Id: If0011068eb7290d1b764c5c4b12c17375fb69008
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6937
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
The W25Q128FW spi part is programatically equivalent
to the other W25Q128 parts except it operates at 1.8V.
Just add a new entry with the appropriate ID.
Tested on a modified MinnowMax Board.
Change-Id: Id6a426418a7f785a9d959b02a9e3d2ffc421804f
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6971
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
Add a Kconfig variable so that driver code knows whether
or not to use dual-output reads.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I31d23bfedd91521d719378ec573e33b381ebd2c5
Reviewed-on: https://chromium-review.googlesource.com/177834
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit de6869a3350041c6823427787971efc9fcf469b8)
tegra124: implement x2 mode for SPI transfers on CBFS media
This implements x2 mode when reading CBFS media over SPI.
In theory this effectively doubles our throughput, though the initial
results were almost negligibly better. Using a logic analyzer we see
a pattern of 12 clocks, ~70ns delay, 4 clocks, ~310ns delay. So if we
want to see further gains here then we'll probably need to tune AHB
arbitration and utilization to eliminate bubbles/stalls when copying
from APB DMA.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I33d6ae30923fc42b4dc7103d029085985472cf3e
Reviewed-on: https://chromium-review.googlesource.com/177835
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 29289223362b12e84da5cbb130f285c6b9d314cc)
nyan: turn on dual-output reads for SPI flash
Nyan's SPI chip is capable of dual-output reads, so let's use it.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I51a97c05aa25442d8ddcc4e3e35a2507d91a64df
Reviewed-on: https://chromium-review.googlesource.com/177836
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 62de0889a9cfc5686800645d05e21e272e4beb5c)
Squashed three commits to enable dual output spi reads for nyan.
Also fixed the spi_xfer interface that has been updated to use bytes
instead of bits.
Change-Id: I750a177576175b297f61e1b10eac6db15e75aa6e
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6909
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Drop a lot of u-boot-isms and share common TIS API
between I2C driver and LPC driver.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I43be8eea0acbdaef58ef256a2bc5336b83368a0e
Reviewed-on: https://chromium-review.googlesource.com/175670
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3fc8515b9dcef66998658e1aa5c020d22509810c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6855
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As a first step towards removing hardcodes from the FUI support,
change the haswell call to i915_lightup to panel_lightup, and pass the
intel_dp * as a parameter. Get rid of the scalar arguments and make
them part of intel_dp. Get rid of file-scope variables and use the
ones in the intel_dp struct. In falco, use functions that peppy
uses. Drop slippy support for FUI, it's a dead board; if this is ok
I'll remove the files next.
And, incidentally, fix the broken RGBX constant and change it to BGRX.
Change-Id: I46ef5a9ed8433382d042066ee3542af04cfc319a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/174932
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 1e1ed410b445c8e2b7411e163d9d6f61499dc3f6)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6833
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
We had brought this code in from the kernel but found it best to
use mainboard- or chipset specific versions. Firmware should
strive to be as non-generic as possible.
Change-Id: Ic1ca746cc52c3f9ea4de6895f2b32946229beada
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172625
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 7dba0dfd25bf9e367f9e5128b15edb018e958c3a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6779
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tablets have different mainboard version than laptop variants.
Change-Id: I77a1e2b50d30dcf3fa064e0c378ceca7ccf96e89
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6785
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
commit 9518b56 (intel/gma: Clarify code and use dedicated init for
Google Peppy) changed "struct edid" and thereby broke the build.
Adapt drivers/emulation/qemu/bochs.c to the changes to fix this.
Build failure triggers with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE=y.
Change-Id: I2d3cecde21d495e9b99ff8d2f741f8a462c75a4d
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/6771
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
commit 9518b56 (intel/gma: Clarify code and use dedicated init for
Google Peppy) changed "struct edid" and thereby broke the build.
Adapt drivers/emulation/qemu/bochs.c to the changes to fix this.
Build failure triggers with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE=y.
Change-Id: Ic295c6d31284555e1463af5bca673231b8722d54
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/6769
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Move (and rename to make it clearer) the function that computes display
parameters from the dpcd and edid.
Change-Id: Idfbb56fd312b23c742c52abca1a34ae117a8fece
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171366
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 8f2b3bafee7cb05db8fae1c52fc9e1ee64e5e35d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6768
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
Old-Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
(cherry picked from commit 8cdaf73e3602e15925859866714db4d5ec6c947d)
snow: Fix a typo in devicetree.cb that was breaking the snow build.
A typo in a recent change broke the snow build.
Old-Change-Id: I93074e68eb3d21510d974fd8e9c63b3947285afd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171014
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 154876c126a6690930141df178485658533096d2)
Squashed a fix into the initial patch and updated nehalem/gma.c
to have a non-static gtt_poll.
Change-Id: I2f4342c610d87335411da1d6d405171dc80c1f14
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6657
Tested-by: build bot (Jenkins)
The register indexes and bitfield masks were guarded by the UART8250 config
options, but it might be (is) necessary to use them in a driver that is
UART8250 like without actually using the 8250 driver itself. To avoid any name
collision with other drivers, also change the constant prefix from UART_ to
UART8250_.
Change-Id: Ie606d9e0329132961c3004688176204a829569dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171336
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a93900be8d8a8260db49e30737608f9161fbf249)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6715
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Martin Roth