| Age | Commit message (Collapse) | Author |
|---|
|
During power on from cold (S5) state, numerous MCEs are generated
before DRAM training starts, e.g. during HT link training. Clear
these MCEs before DRAM training start, and report any MCEs generated
during DRAM training.
Change-Id: I7d047571242e5bd041e4aac22c1ec1d7d26ef0e6
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14191
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
On Family 15h processors, with certain RDIMMs, MCEs are generated
as a normal part of DCT startup / DRAM training. Disable sync
flood on parity or UC data error until ECC has been enabled.
Change-Id: Ife54751ff127ffd59baaad35d3fea14ea01ef505
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14186
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Datasheet: http://www.fintek.com.tw/files/productfiles/F81865_V028P.pdf
There is a multi-function select register listed as 0x2a-1 and 0x2a-2.
These are the original names in the datasheet, but superiotool will
display register 0x29 and 0x28 and their values.
This patch renames them both to 0x2a and shows both of the default values
for them. They are both 0x00, so one of them could be dropped though.
Change-Id: Iad91f9e4755d2d1a123e56ab0fa9257be7ea9978
Signed-off-by: Wilbert Duijvenvoorde <w.a.n.duijvenvoorde@gmail.com>
Reviewed-on: https://review.coreboot.org/5404
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This resolves a long-standing issue with RDIMM control word
configuration failure, likely due to random parity failure.
Change-Id: If8b8dc5b8b99f4c2fe29b3a133b064631e4693be
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14184
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I96d695ed10176276116fcf3a2b77605fb3f2d5db
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13710
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In order to add a fallback mechanism, move the ram training code
into a new function. This function will be called multiple times
and must return error or success to the calling function.
Change-Id: I5ee1b3a528290d8252d236b9152b81291736958a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14169
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Somehow the missing header file in
https://review.coreboot.org/#/c/14182 did not trigger compilation
errors before. Add the required header file to enable proper
compilation of storm.
Change-Id: I83c8f2b5fc41e38c1385ff405370753e6eba2abc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14185
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This patch would enable PROCHOT feature in skylake. Asserting
PROCHOT line would throttle the GPU/CPU.
BUG=chrome-os-partner:51142
BRANCH=glados
TEST=manually tested on lars. asserting PROCTHOT by EC
reduces FSP in fish-tank from approx 40 to 20. (50 fish setting),
also CPU freq. drops to from 1600000 to 400000
Change-Id: I8fc0c015ea2c26d20bbbfc619f720f231d540feb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1b88b1f183df9c7362d7e58acb0a1fa0b076d56e
Original-Change-Id: Ida8636efc3d8da56ebd3931144d31ab1b88fe806
Original-Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/331690
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-(cherry picked from commit d091a999c3827179182b62a1274a9b3581f7f006)
Original-Reviewed-on: https://chromium-review.googlesource.com/333073
Original-Commit-Ready: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Tested-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/14120
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
MinPL1: 2.5W
MaxPL1: 7W
StepPL1: 0.25W
_PSV(TSR2): 51C
_TRT(TSR2): 9 second
BUG=chrome-os-partner:49859
BRANCH=glados
TEST=build and boot on chell
Change-Id: I69de1d66fb0d52ad0ad77eb51ca56f50fc44c255
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 845f1d046a5143057d683b2bd9cf5dab2ab2ef34
Original-Change-Id: I8a161c979a22621f5f854926677cb7835f8ce88b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/332857
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-(cherry picked from commit 4d5023524591fc6b651a199874ed990bd5be1d50)
Original-Reviewed-on: https://chromium-review.googlesource.com/333071
Reviewed-on: https://review.coreboot.org/14119
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
GPP_E_21_DDPC_CTRLDATA is pulled low by default.
This causes 2.5mW leakage from 3.3S to GND via R877.
So configuring GPP_E21 in native mode.
BUG=chrome-os-partner:50958
BRANCH=glados
TEST=Build and boot. Measure Power at 3P3S(R955).
Change-Id: I2bdcb698d0b0cd3228c2e59653ac3fb3b1a26951
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d01f932cda44b0b44c5494b316aefc43c8b84c52
Original-Change-Id: Ifd13ea4b16108ef98d09891365f0d17831ab5f65
Original-Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332369
Original-Commit-Ready: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14108
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When doing verification of memory init code in verstage vboot
should issue a TPM_Startup(ST_STATE) instead of TPM_Startup(ST_CLEAR)
in order to preserve the flags in TPM_STCLEAR_FLAGS which include
things like physical presence. In doing so we can also skip the rest
of the TPM init work in this function in the S3 resume path.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=S3 resume on chell and ensure TPM is resumed instead of being
cleared and that 'tpmc getvf|getpf|getf' does not show any difference
in flags between boot and resume.
Change-Id: I7a48eaf7f57d2bc6ebc182178cbe60ceb2ad8863
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f059f39a0f5c2f21e564b9554efacf26a41ad794
Original-Change-Id: I647869202d2f04328764155d3de4cad9edf10ae4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332434
Original-(cherry picked from commit 5fc7792e4104523569140cd84ce313da721ec34b)
Original-Reviewed-on: https://chromium-review.googlesource.com/332542
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
For platforms that do verification of memory init (and have verstage
execute before romstage) FSP should not attempt to re-initialize the
TPM again in romstage as it has already been done.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=boot and resume on chell and ensure TPM is not re-initialized
Change-Id: Ied6f39dc8dacdbc3d76070b6135de2308196ff53
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fefd4d4b3fde4c7fe4b6de304790914b7a2f87d8
Original-Change-Id: I60a2e4e2d73270697218f094527e09d444e6ab56
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332433
Original-(cherry picked from commit 2de1fd57fe1db7960e0bb86c64dccf827fa55742)
Original-Reviewed-on: https://chromium-review.googlesource.com/332299
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14106
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The board status script wasn't checking the entire tree to make sure
that all boards had board_info.txt files. Also it would only print
out the first issue that was found.
Change-Id: I5f2fa9e564c805c6dbee7a35cab80c1c342567a5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14118
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
It's required to store the dimm_info in ramctr_timing as only ramctr_timing
is written to mrc cache.
Allows to fill SMBIOS type 17 if mrc cache is used.
Change-Id: I7634b05069df307d471938d9854997a018de81b3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
DRAM initialization on storm requires ipq blobs to be
loaded from cbfs. vboot_locator first checks cbmem_find to see if cbmem is
initialized and contains selected region info, else it falls back to
vboot work buffer.
Since cbmem_find calls into cbmem_top to identify the location of
cbmem area, board/chipset is expected to return NULL until the backing
store is ready, which in this case until DRAM is initialized in
romstage, return NULL for cbmem_top.
Change-Id: I1880ce61dcfdabaa527d7a6dcc3482dfe5d5fd17
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Board or chipset needs to ensure that cbmem backing store is ready
when returning the cbmem top address. cbmem infrastructure has no
support for checking the validity of the backing store/address.
E.g.: If romstage handles cbmem coming online, chipset or board need
to ensure that call to cbmem_top in romstage returns NULL if the
backing store is not yet initialized.
Add a comment to ensure that developers know this requirement while
implementing cbmem_top for future chipsets/boards.
Change-Id: I0086b8e528f65190b764a84365cf9bf970b69c3f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14181
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In the board status repository, there is trailing whitespace in the
coreboot log of the board ASUS KFSN4-DRE.
```
SATA S SATA P
```
Remove it, as it’s unnecessary.
Change-Id: I5c505eb7c734dca3fa18235e2bc0bc82b5b50b16
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/14175
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
|
|
Replace open coded memset() functions with calls to the library function.
The new code also explicitly backs up and restores the data structures
that are preserved across calls to mct_ResetDataStruct_D(), and no longer
relies on structure member order to function correctly.
Change-Id: I6dd6377deda0087cd1b65f7555588978657d6516
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ic5482dc13ab7b53ec4df408bbe32d20888ae2e12
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13725
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
If you want to be a maintainer Damien just add yourself to the list.
Change-Id: I15c646fc23d0804a8172da66d9297ab7977e6e6a
Reviewed-on: https://review.coreboot.org/14157
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add coreboot build tests after running the toolchain build. This
verifies that everything still builds with the new toolchain.
Change-Id: Ifa51db897925c0b77791c83bbcbfd75045c907b5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14156
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The lint script didn't catch that these mainboard directories didn't
have board_info files.
Add all missing board_info.txt files
Change-Id: Ib1d61a3c04e91b22480527885faf60c22093d98a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14117
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
The intelmetool shows information about the Intel
Management Engine for different platforms.
Original source code can be found under following link:
https://github.com/zamaudio/intelmetool.git
Change-Id: I0eb17833a21eb04cf9245a7312289a4102bec1a9
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/14136
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A call to i2c_read() for a non-existent address followed by an i2c_read()
to a valid address results in a false abort status for the 2nd call.
i2c_read(1, 0x40, 0, buf, sizeof(buf)) => 0x2000000 (I2C_ERR_TIMEOUT)
i2c_read(1, 0x74, 0, buf, sizeof(buf)) => 0x4000000 (I2C_ERR_ABORT)
Because the abort status register is cleared on read and wait_tx_fifo()
reads it twice, the returned status does not contain the abort status.
Fixing that changed the 2nd read to reflect the abort status.
i2c_read(1, 0x40, 0, buf, sizeof(buf)) => 0x2000000 (I2C_ERR_TIMEOUT)
i2c_read(1, 0x74, 0, buf, sizeof(buf)) => 0x4000001 (I2C_ERR_ABORT)
Bit 0 indicates that the address was not acknowledged by any slave.
That's the abort status from the previous transaction.
So I added a read of the abort status before starting a transaction in
both i2c_read() and i2c_write().
i2c_read(1, 0x40, 0, buf, sizeof(buf)) => 0x2000000 (I2C_ERR_TIMEOUT)
i2c_read(1, 0x74, 0, buf, sizeof(buf)) => 0 (I2C_SUCCESS)
Tested on a Bay Trail E3845 SoC.
Change-Id: I39e4ff4206587267b6fceef58f4a567bf162fbbe
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14160
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
i2c.c uses "*(volatile unsigned int *)" constructs where it could use
read32() and write32().
Switch to using read32() and write32().
The remaining instances in wait_tx_fifo() and wait_rx_fifo() are fixed
in https://review.coreboot.org/#/c/14160/
Change-Id: I39e4ff4206587267b6fceef58f4a567bf162fbbe
(intel/fsp_baytrail: Fix I2C abort logic)
I also fixed a few minor white space issues.
Change-Id: I587551272ac171ef1f42c7eb26daf877dc56646b
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14162
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
- Copy each config in configs/ to the junit_config, update each,
in turn, and clean up when done. This avoids updating the saved
config files and creating dirty files in git.
- Use 'make olddefconfig' instead of 'yes "" | make oldconfig'
- Update clean target to remove junit_config file
- Update distclean target to remove junit.xml
Change-Id: Ib023eb3197f2d8806c73c9c18464157ce3de958f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14164
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Add check_for_library routine to test for missing libraries.
- Add a check for zlib.
- Remove 'utility' text from please_install() routine since we can test
for libraries or utilities now.
- Remove incorrect 'solution' text from alternate install since I was
updating that line.
Change-Id: Id5ef28f8bde114cbf4e5a91fc119d42593ea6ab2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14147
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These are multi-threaded decompressors for .gz and .bz2 compressed
files. If they're installed, use them to decompress, if they're not,
use the standard single-threaded decompressors.
Change-Id: I397740817e6b234a43b62075899964bdab14f121
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14146
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add a newline after the supported version text.
Move $TARGETDIR left so that longer paths print better.
Change-Id: If520e1b8657a526dee27763aee62cb78777d020d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
During maximum read latency training on Family 15h processors,
the maximum read latency was incorrectly set from the NBP1
value instead of the correct NBP0 value.
Modify maximimum read latency training to explicitly operate
on the NBP0 value, and store the previously calculated NBP1
value for reference by other portions of the training algorithm.
Change-Id: I5d4a6c2def83df3e23f1a4c598314c31a0172cd7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14150
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This is required on powerpc64 to build both little endian and big endian
libgcc.
Change-Id: I295c8ee5e8131d4108e98d1bfd53abb8bd8982b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14163
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Update IASL from 20150619 to 20160318
See release notes at acpica.org
Change-Id: Ic7e7b3956378ad611069e984d5a59c78e4cb08b1
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/12817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Coreboot and most payloads support three basic pixel widths for the
framebuffer. It assumes 32 by default, but several chipsets need to
override that value with whatever else they're supporting. Our struct
edid contains multiple convenience values that are directly derived from
this (and other properties), so changing the bits per pixel always
requires recalculating all those dependents in the chipset code. This
patch provides a small convenience wrapper that can be used to
consistently update the whole struct edid with a new pixel width
instead, so we no longer need to duplicate those calculations
everywhere.
BUG=None
TEST=Booted Oak in all three pixel widths (which it conveniently all
supports), confirmed that images looked good.
Change-Id: I5376dd4e28cf107ac2fba1dc418f5e1c5a2e2de6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: If8c07fb3bee4bf0b531e52fae29890af99f924b4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14161
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
dqsTrainMaxRdLatency_SW_Fam15()
Change-Id: Ic3f636983cf6ba2796ee56e2a25b56513a4343c1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/14148
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As a follow up to Change-Id: I1fb3fc139e0a813acf9d70f14386a9603c9f9ede,
use as builtin compiler hint instead of inline assembly to allow the
compiler to generate more efficient code.
Change-Id: I690514ac6d8988a6494ad3a77690709d932802b0
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12083
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current Apollolake flow has its code executing out of
cache-as-ram for the pre-DRAM stages. This is different from
past platforms where they were just executing-in-place against
the memory-mapped SPI flash boot media. The implication is
that when cache-as-ram needs to be torn down one needs to be
executing out of DRAM since the act of cache-as-ram going
away means the code disappears out from under the processor.
Therefore load and use the postcar infrastructure to bootstrap
this process for tearing down cache-as-ram and subsequently
loading ramstage.
Change-Id: I856f4b992dd2609b95375767bfa4fe64a267d89e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14141
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This patch adds support for an alternative ternary number system in
which group of GPIOs can be interpreted. In this system, the digit
combinations that would form a binary number (i.e. that contain no 'Z'
state) are used to represent the lower values in the way they're used in
the normal binary system, and all the combinations that do contain a 'Z'
are used to represent values above those. We can use this for boards
that originally get strapped with binary board IDs but eventually
require more revisions than that representation allows. We can switch
their code to binary_first base3 and all old revisions with already
produced boards will still get read as the correct numbers.
Credit for the algorithm idea goes to Haran Talmon.
BRANCH=None
BUG=None
TEST=Stubbed out the actual GPIO reading and simulated all combinations
of 4 ternary digits for both number systems.
Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14116
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: If3b49c3056abe6e1c1a14578d6c62a866bc6834d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14127
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Hannah Williams <hannah.williams@intel.com>
|
|
In order for a caller to utilize an rmodule's parameters section
after calling rmodule_stage_load() export the rmodule's parameter
pointer in struct rmod_stage_load.
Change-Id: I9cd51652cf8cdb3fae773256989851638aa1a60f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14139
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Change-Id: Ib127af5392ca2b349480f5b21fad2186b444d7e6
Signed-off-by: Lance Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/13348
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Set MMCONF_BASE_ADDRESS to 0xf8000000.
It was already done for some boards, but not all.
The sandybridge chipset code assumes 64 pci buses behind MMCONF.
Therefore, only 64MiB of physical address space is required.
Increasing the address allows to use additional 128MiB of MMIO
space and to use the Intel IGD and a PEG at the same time.
Previously it wasn't possible to use both at the same time,
as two 256MiB areas won't fit into MMIO space.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* Onboard GPU Intel IvyBridge Desktop
* PEG GPU AMD RV770
Change-Id: I3bf72439056c8089ada6899bb0605e5cd9d89cd6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14096
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
In Chromium OS downstream this was done together with adding the support
for ATF, but unfortunately ATF upstream isn't ready yet. This commit
is a reminder to enable things once ATF caught up.
Change-Id: Id0d6908d906a1e54cdda4f232d572d996d9c556f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13968
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As the DA9212 and MT6311 external buck can be controlled by hardware
since rev-5 board, we don't need to pass any board specific parameter
to ARM TF.
BRANCH=none
BUG=none
TEST=build pass
Change-Id: I43eebe25ab14d3dd84e8bb4286e2bb55c8c3c063
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c4dfe61c69042e464b384e2e0edbc55eda23a74
Original-Change-Id: I541357fee6afb1ff2d771bcb073f7c9a9db52f00
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332344
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14124
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove the code which is passing parameters to ARMTF and move external
buck initilizaton from ARMTF to coreboot.
BRANCH=none
BUG=none
TEST=verified on Oak rev4/rev5
Change-Id: I4f4b30acbee9b42a202b326f2fe4517cb4b9d83c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 37bec54b4d8a3bce38878e292e4821da3959026a
Original-Change-Id: Ib81709812a064f6daf13c9b4d6525f1858c81393
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332343
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14123
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add secondary PMIC for external buck control on Oak rev0/1/2/5
BRANCH=none
BUG=none
TEST=verified on Oak rev4/rev5
Change-Id: Ia000b0c7d61e8396856656247f9627e33b21b19b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 241508e7d781fac8ee085ee81962043dd654c52d
Original-Change-Id: I6c75e2462363a5523bf1ebb03af7a36740293624
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332342
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14122
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add secondary PMIC for external buck control on Oak rev3/4
BRANCH=none
BUG=none
TEST=verified on Oak rev4/rev5
Change-Id: I24c18a1cf71fc57deacedcbeb6a100b131c28077
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7f7f8ceac795d8193194a6918a73c4b391009025
Original-Change-Id: I312d8281d2c09d8bc43f092edef3e405d51ee7d0
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332341
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14121
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
i2c_read_field() - read the value from the specific register field
i2c_write_field() - write the value to the specific register field
BRANCH=none
BUG=none
TEST=none
Change-Id: I2098715b4583c1936c93b3ff45ec330910964304
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0817fc76d07491b39c066f1393a6435f0831b50c
Original-Change-Id: I92c187a89d10cfcecf3dfd9291e0bc015459c393
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14105
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Under certain conditions (training abort) BlockRxDqsLock could
remain set in violation of the BKDG. Ensure BlockRxDqsLock is
reset to 0 after a lane training abort.
Change-Id: I1a49a24d02b2b7cacae074794ec274a424a9e66b
Reviewed-on: https://review.coreboot.org/14144
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Document how to test TempRamExit and verify the MTRR setup and loading.
TEST=None
Change-Id: I57a604fa139edac4b05453547d3caf185db491e0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14113
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add datasheet links for the components supporting GPIO. This includes
I2C I/O ports, I2C PWMs, bus buffers and multiplexers.
TEST=None
Change-Id: I0a1d222d6f9bdbd824b78edf2338cd797e83ebba
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14114
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add documentation on disabling the SPI flash which is mapped (shadowed)
into the x86 address space at 0x000e0000 - 0x000fffff.
TEST=None
Change-Id: I1d94d84c6cade97886a3274a7e7403f7b3275c5a
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14112
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Disable the ROM shadow and enable RAM for 0x000e0000 - 0x000fffff.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing successful display of 0x000ffff0 - 0x000fffff does not match
the end of the SPI flash.
Change-Id: I6e0a50417815320333eae0b69b96280c39db7eaa
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14110
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Enable the SPI controllers on the Quark SoC.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Load the SPI driver stack
* Testing is successful when the time is able to be displayed on a
set of seven-segment displays controlled by a Maxim MAX6950 SPI
display controller.
Change-Id: Ic9c4575730c5a9a27cf9a38a41e82d8462467f3f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14109
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add missing punctuation and align output.
No functionality is changed.
Old logging output:
Revision: 11
Type : b
Key : 2
Banks : 8
Capacity: 4 Gb
Supported voltages: 1.5V
SDRAM width : 8
Bus extension : 0 bits
Bus width : 64
Optional features : DLL-Off_mode RZQ/7 RZQ/6
Thermal features : ASR ext_temp_range
Thermal sensor : no
Standard SDRAM : yes
DIMM Rank1 Address bits mirrored!!!
DIMM Reference card B
DIMM Manufacturer ID cd04
DIMM Part number F3-1866C9-8GSR
XMP Profile 1
Max DIMMs per channel: 4
XMP Revision: 1.3
Requested voltage: 1500 mV
New logging output:
Revision : 11
Type : b
Key : 2
Banks : 8
Capacity : 4 Gb
Supported voltages : 1.5V
SDRAM width : 8
Bus extension : 0 bits
Bus width : 64
Optional features : DLL-Off_mode RZQ/7 RZQ/6
Thermal features : ASR ext_temp_range
Thermal sensor : no
Standard SDRAM : yes
Rank1 Address bits : mirrored
DIMM Reference card: B
Manufacturer ID : cd04
Part number : F3-1866C9-8GSR
XMP Profile : 1
Max DIMMs/channel : 4
XMP Revision : 1.3
Requested voltage : 1500 mV
Change-Id: Iee4d7a7c0e1070706fb60d7316fad49813963b51
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14083
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When CONFIG_X86_TOP4G_BOOTMEDIA_MAP was introduced verstage
was not updated. Correct this oversight.
Change-Id: I2775c08798906ba0ba55a361407d7d2b52313229
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14142
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I0eedda5f31c2809db7871b81ceb3045b782f9df1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14126
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I3efd4116da1ffda2dbc768d1a447141d8ec76f81
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Being able to fetch this list will allow the jenkins builder to securely
fetch the external payloads so we can start testing payload builds.
Change-Id: I777229216b2f11f0f427cd5f8cfa003da4171a77
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14132
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Instead of adding each payload to each common target, create a list
and loop through the list for all of the payloads
- '.phony' doesn't work - the target needs to be uppercase '.PHONY'
Change-Id: I4a7712c94d0f127c2fff8cb8fada4b8132a4ab3b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14131
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These makefiles are not included by anything, so they shouldn't be
named Makefile.inc. Also, having them all be named 'Makefile' makes
some other consolidation work I'm doing much easier.
Change-Id: I1234539ba6a0a6f47d2eb0c21de3da3607c6b8de
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14130
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When using coreinfo on a serial console (at least
with gtkterm, picocom and minicom on Ubuntu 15.10)
you can't send F keys to the payload. Allow 1..9
for F1..F9
Change-Id: Ie3a11fa1de57c7345737a1ccaff177f407cd5e48
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14065
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The previous implementation assumed the CPU physical address size to
be 40 which is not true of all platforms. Use an existing function to
obtain the correct CPU physical address to report in the DMAR ACPI
table.
Change-Id: Ia79e9dadecc3f5f6a86ce3789b213222bef482b3
Signed-off-by: Jacob Laska <jlaska91@gmail.com>
Reviewed-on: https://review.coreboot.org/14102
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Instead of hard-coding var mtrr numbers in code, use this function to
identify the first available variable mtrr. If no such mtrr is
available, the function will return -1.
Change-Id: I2a1e02cdb45c0ab7e30609641977471eaa2431fd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14115
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
BRANCH=none
BUG=chrome-os-partner:50820
TEST=check /proc/device-tree/firmware/coreboot/ram-code
Change-Id: I5ecf45cada7f8999ad607487d5d9281c4fb659ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 79d2f0e183a2bde70817d673ae315709f46e3361
Original-Change-Id: I35e91b4e29f8e09acd74770715c96cf7320ac22c
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332564
Original-Reviewed-by: Milton Chiang <milton.chiang@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14104
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When system enters suspend, SPM will pull SRCVOLTEN low to turn off some
power rails. VSRMCA7 should follow this pin to turn on/off the power.
BRANCH=none
BUG=none
TEST=verified on Oak rev5
Change-Id: I9d81f855a74fe02a59246ce0c6a7f0e162b9fd0a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d92fb1029b810028138eb91b064b63a58b82602f
Original-Change-Id: I37ff0694cbd7b17d5a1ae172c463b4e6aae2b99c
Original-Signed-off-by: henryc.chen <henryc.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/332345
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14103
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I84e68e8407149780769c3e6a1148c175e42d1025
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/14100
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to make this work earlymtrr.c needed to be removed
from intel/truxton/romstage.c. It's not a ROMCC board so
there's no reason to be including .c files.
Change-Id: If4f5494a53773454b97b90fb856f7e52cadb3f44
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14094
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
I see no user of any of this code. Remove it.
Change-Id: I776cd3d9ac6578ecb0fe6d98f15611e4463afb7a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14098
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The Intel i3100 northbridge code is the only user of
cache_ramstage(). Therefore, place it next to the sole
consumer.
Change-Id: If15fb8d84f98dce7f4de9e089ec33035622d8f74
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14097
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Add all the default options with:
for i in configs/*
do
cp $i .config
make savedefconfig
mv defconfig $i
done
This also switches to minimal config files instead of the full
configuration files that were previously checked in.
Change-Id: If18a32eca4df9e1dfeb0e212b652d972cea8e4b8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14077
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
LIBCONFIG_PATH -> LIBPAYLOAD_PATH
LIBPAYLOAD_DIR -> LIBPAYLOAD_OBJ
Change-Id: Idd9947bac594f5b109b877aefac70b1a1d2336eb
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14099
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
make_idb.py only support RK3288 before, add chip parameter, so we can
support RK3399 either.
Change-Id: I6811acb7f0cdaf1930af9942a70db54765d544d5
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://review.coreboot.org/13913
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With gpio PADRSTCFG set to DEEP & GPIROUTIOXAPIC=1 & PADRSTCFG, causes
IRQ storm after S3 resume. GPIOs that fire IRQs via IOAPIC need to get
their logic reset over pltrst and hence configuring PADRSTCFG to
PLTRST to prevent IRQ strom after S3 resume.
BRANCH=glados
BUG=chrome-os-partner:50536
TEST=Build for kunimitsu and Boot on FAB4, no irq storm observed
after S3 resume.
Change-Id: I7f1ae90aed03778e7d6cb2d79de0efe9a6d9e20d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aff91da4feaf8f7e42cfeee756cf468288cbfd68
Original-Change-Id: I7cac60fb0144e090b8decb05d948b2d8d2f8deac
Original-Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/329453
Original-Commit-Ready: Naresh Solanki <naresh.solanki@intel.com>
Original-Tested-by: Naresh Solanki <naresh.solanki@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/331174
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13992
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This includes a fix that allows using cbootimage with paths containing
the "@" sign, which happens sometimes in jenkins configurations.
Change-Id: I83154afa35b6d24449e713e57031b1a93d7ac748
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14090
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Sort out some style issues that were identified by Paul.
Change-Id: I9ed946ae613c87234f8c9824eb14b8d28909dfcf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14064
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When using PDcurses over a serial line, the background of
coreinfo is not properly cleared. Hence use tinycurses, which
was the only option when coreinfo was developed.
Change-Id: I15bb6eb552cf924de98d09ef63be33ecf336c526
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14067
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
The two external USB ports and the internal USB header have overcurrent
protection chips with the low-active overcurrent signal connected to the
chipset.
The power-on default for this register disables the software detection
of overcurrent conditions.
After setting the register Linux correctly shows the overcurrent
condition in the kernel log (tested by shorting the 5v and gnd lines on
J14 / the internal USB header):
[ 2015.229921] usb usb1-port3: over-current condition
[ 2015.449925] usb usb1-port4: over-current condition
Simlar for the external ports:
[ 256.237916] usb usb1-port1: over-current condition
[ 256.458084] usb usb1-port5: over-current condition
Note that each signal is shared between two ports:
usboc0#: External ports (port1/5)
usboc1#: Internal ports (port3/4)
Change-Id: I02d498053b8ec61dc206e74a96c4a1dcfd4fae92
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: https://review.coreboot.org/14084
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix for the T4xx and T5xx series.
It does not apply to X2xx/X6x series as those have only
one GPU, which is always connected to the display.
The T6x series needs special care not handled with this patch.
Without ONBOARD_VGA_IS_PRIMARY the onboard GPU would be
deactivated in case a dedicated GPU is found and active,
leaving the system without a working display.
Change-Id: I94d1700e9afb75de83a4f2ed1ff53ba3b0559ae1
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14031
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
BRANCH=none
BUG=chrome-os-partner:49229
BUG=chrome-os-partner:50806
TEST=power on to kernel on Oak Rev3 with 4GB dram
Change-Id: I32fa881df12eb9b7f66086904aebde3dd1483fbf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 94c8b7ad911c93c4325113e7afc009f2f81d2275
Original-Change-Id: Ia3640882a46e695550e679dc70611855b64a560f
Original-Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/331811
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14089
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
If the system is using 4GB of memory, enable 4GB mode in
the memory controller.
Change-Id: I4d0f8ad8d43ff45dd786f4244b11c0879d2088cd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 94c8b7ad911c93c4325113e7afc009f2f81d2275
Original-Change-Id: Ia3640882a46e695550e679dc70611855b64a560f
Original-Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/331811
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14088
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This pin is not used anymore since Rev5.
BRANCH=none
BUG=chrome-os-partner:49375
TEST=make and boot on Rev4/5
Change-Id: I3c775eb2b5e05256523bfd8be814e516944a2f90
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a87e3babe28413bd879a2d95d4612a5b6b541419
Original-Change-Id: I87972ff8961309ecdad03639e1b6fac1da119cd7
Original-Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/331810
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14087
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a few additional macros that can be used throughout the coreboot
makefiles.
tolower: returns the value in all lowercase
toupper: returns the value in all uppercase
ws_to_under: returns the value with any whitespace changed to underscores
Change-Id: Icd0e6586481d8f229af0e899e0c94ef7c5c672c3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14093
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For CHROMEOS builds, depthcharge can be built automatically.
This dependency exists because depthcharge without vboot and subsequent
signing of the image doesn't work very well, and both are keyed to that
flag as well.
Change-Id: Id0195bd3b4e454f382782106d6512469106daac5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/10924
Tested-by: build bot (Jenkins)
|
|
This option is no longer needed, as FMAP support has been
fully integrated in coreboot
Change-Id: I6121b31bf946532717ba15e12f5c63d2baa95ab2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14078
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This will allow more payloads to use the standard linker script
instead of implementing their own.
Change-Id: Ie60120769829f427ceb722109d85859b61dbde31
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14074
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I8c8669e73e335e12cb3785cf84b878c305dd5929
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14068
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
_LDFLAGS+="foo" did not work in my shell (bash on Ubuntu 15.10),
so change it to _LDFLAGS="$_LDFLAGS foo". I'm mildly surprised
that this ever worked.
Change-Id: I59c10f34992240c6df2ec7f24aebc6daafb76493
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14076
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I8b74cbf6bdde32c90ad0510e14e899711269e57f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14075
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of 500, print 0x00000500 in the ram dump module.
Change-Id: Id250bd99f36dad4088ab88953fb371c400b4231b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14072
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
MEMMAP_RAM_ONLY is not an architecture specific option,
hence move it out of the architecture specific menu.
Change-Id: Iaeef03ed8cbff930a580ad03b1e712087b48714e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14071
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This is adding complexity to the code more than it saves
space, plus some of the tables could potentially be interesting
outside of the ChromeOS context.
Change-Id: I4bf24608f3e26d3b7871a5031ae8f03bc2c8c21f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14070
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Bring defconfig and defconfig-tinycurses in sync, so that
defconfig and defconfig-tinycurses only differ in the selection
of the curses implementation.
Change-Id: I739c5122b5aaaa2681055c845905721a0b2a11c1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14069
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The Kconfig lint tool is complaining because this symbol doesn't
exist. Create a temporary definition that can be removed when
the chipset is added.
Change-Id: I6a8abffcc91773aae16721ee1f48c4c64bd6b486
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14091
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change the comparison of build_timeless from -eq to =
This was generating an error if BUILD_TIMELESS wasn't set:
util/genbuild_h/genbuild_h.sh: line 27: [: : integer expression expected
This wasn't causing the script to fail, and won't even if 'set -e' is
added to the script because the error happens inside an 'if' clause,
which is specifically excluded from failue on 'set -e'.
Change-Id: I6a4e147ece23e83ee682d72db35be9e5d4088c78
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14080
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Commit c49014e (timestamp: add tick frequency to exported table)
refactors the code, but forgets to correctly scale the frequency to
megahertz, where the value is read from sysfs, so that printing time
stamp information shows milliseconds instead of microseconds, as can be
seen on the output `cbmem -t` for the ASRock E350M1 below.
```
0:1st timestamp 515
10:start of ramstage 515 (0)
30:device enumeration 515 (0)
40:device configuration 610 (94)
50:device enable 614 (4)
60:device initialization 624 (9)
70:device setup done 639 (14)
75:cbmem post 844 (205)
80:write tables 844 (0)
90:load payload 849 (4)
15:starting LZMA decompress (ignore for x86) 849 (0)
16:finished LZMA decompress (ignore for x86) 869 (20)
99:selfboot jump 869 (0)
Total Time: 350
```
So scale the return value correctly to megahertz, by dividing it with
1000.
```
0:1st timestamp 515,655
10:start of ramstage 515,655 (0)
30:device enumeration 515,663 (7)
40:device configuration 610,620 (94,957)
50:device enable 614,680 (4,059)
60:device initialization 624,618 (9,938)
70:device setup done 639,553 (14,934)
75:cbmem post 844,707 (205,154)
80:write tables 844,710 (2)
90:load payload 849,532 (4,821)
15:starting LZMA decompress (ignore for x86) 849,655 (123)
16:finished LZMA decompress (ignore for x86) 869,903 (20,247)
99:selfboot jump 869,922 (19)
Total Time: 354,261
```
Change-Id: Iea032c62487c7946b6194a90268755034c6350df
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/14086
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Initial vendor codes to support Broadwell-DE SoC. This is FSP 1.0 based
project and is based on Broadwell-DE Gold release. Change has been
verified on Intel Camelback Mountain CRB.
Change-Id: I9262c9d70a58f0c7427f0658948adf080f2f6d8f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/14030
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This change fixes LPSS ACPI mode. Previously, enabling ACPI mode would
result in unusable devices, as the resources were set to 0 and the devices
were disabled.
lpss.c was copied from intel/baytrail with a few minor adjustment for the
different config structure.
ACPI mode requires setting PcdLpssSioEnablePciMode==LPSS_PCI_MODE_DISABLE
and applying the patch that disables clearing gnvs.
https://review.coreboot.org/#/c/14040/
This doesn't handle the case where the FSP has PcdLpssSioEnablePciMode
set to disable and the devicetree set to default.
Change-Id: I12fffea3820ed948defe7a4f11af6b6363402560
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14042
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
If the VBT was provided to the FSP GOP driver then graphics init
will be done as part of SiliconInit step and we can mark that
when it is completed.
This will result in the "oprom" flag being set properly in the
coreboot gpio table and the netboot firmware will have video.
[pg: avoided conflict with Quark that comes without
silicon_init_params.GraphicsConfigPtr]
BUG=chrome-os-partner:50864
BRANCH=glados
TEST=boot image.net.bin on chell and get working graphics
without being setuck in a reboot loop thinking graphics needs
to be started when it already has been.
Change-Id: I0e481b4be57096ed5c60d78e3fa00f3bb2a4eae1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 089d93c712431d1b5923e844137c558994555e95
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/331301
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-(cherry picked from commit eeb9d470d8118422feb39ca71106972f2882e240)
Original-Change-Id: Ic59bad27eb9f184ca3eba24643851bfadfe23ab5
Original-Reviewed-on: https://chromium-review.googlesource.com/331355
Reviewed-on: https://review.coreboot.org/13986
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
