| Age | Commit message (Collapse) | Author |
|---|
|
Rename soc_display_upd_value to fsp_display_upd_value since the routine
was moved from src/soc/intel/common into src/drivers/intel/fsp1_1.
BRANCH=none
BUG=None
TEST=Build and run on Kunimitsu
Change-Id: Ifadf9dcdf8c81f8de961e074226c349fb9634792
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 95238782702999a178989467694ac1f15c079615
Original-Change-Id: Ibd26ea41bd5c7a54ecd3c237f7fb7bad6dbf7d8a
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/306351
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12157
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
Move the FSP common code from the src/soc/intel/common directory into
the src/drivers/intel/fsp1_1 directory. Rename the Kconfig values
associated with this common code.
BRANCH=none
BUG=None
TEST=Build and run on kunimitsu
Change-Id: If1ca613b5010424c797e047c2258760ac3724a5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e8228cb2a12df1cc06646071fafe10e50bf01440
Original-Change-Id: I4ea84ea4e3e96ae0cfdbbaeb1316caee83359293
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/306350
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12156
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
With SPI TPMs there is no SERIRQ for interrupts, instead it is
a PIRQ based interrupt. The TCG PC Client Platform TPM Profile
Specification says it must be active low and shared.
This can be enabled with the CONFIG_TPM_PIRQ option that will
specify the interrupt vector to report for the TPM.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=verify TPM interrupt functionality in /proc/interrupts on glados
Change-Id: Iad3ced213d1fc5380c559f50c086206dc9f22534
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: abdd0b8ecdf51ff32ed8bfee0823bbc30d5d3d49
Original-Change-Id: If7d22dfcfcab95dbd4c9edbd8674fc8d948a62d2
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/304133
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12147
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch provides the lb_framebuffer() for coreboot table with
fsp gop usage, add Igd Opregion register defines, and update the
UPD naming following fsp.
BRANCH=none
BUG=chrome-os-partner:44559
TEST=Built and boot on kunimitsu/glados.
Change-Id: I9cf9d991eb09d698e7a78323cd855c4c99b55eca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cd6834057cca60716bc0e24cfc2cd60fed02be7a
Original-Change-Id: I64987e393c39a7cc1084edf59e7ca51b8c5ea743
Original-Signed-off-by: robbie zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303539
Original-Commit-Ready: Robbie Zhang <robbie.zhang@intel.com>
Original-Tested-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12141
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch was tested with the following card:
IDE interface: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller [1095:0680] (rev 02)
Change-Id: I988b73684b54942d8ee6e44a9319dcc54086fca7
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/12171
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I37763a59d2546cd0c0e57b31fdb7aa77c2c50bee
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11937
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I5a9b5eba992853b84b0cb6c3a1764edf42ac49b2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12080
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
Add full support for fan control, fan monitoring, and voltage
monitoring. Fan speeds and functions are configurable via
each mainboard's devicetree.cb file.
NOTE: This patch effectively rewrites large portions of
the original driver. You may need to re-verify correct
operation on your hardware if you were using the old
driver code.
Change-Id: I3e246af0e398d65ee43ea708060885c67fd7d202
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11936
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Those are actually board specific. Keep the old value as defaults,
though. The defaults are included by all affected boards.
Change-Id: Ib865c7b4274f2ea3181a89fc52701b740f9bab7d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11705
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
In order to support verstage the cache-as-ram split
is taken advantage of such that verstage has the
cache-as-ram setup and rosmtage has the cache-as-ram
tear down path. The verstage proper just initializes
the console and attempts to run romstage which triggers
the vboot verification of the firmware. In order to
pass the current FSP to use during romstage a global
variable in cache-as-ram is populated before returning
to the assembly code which tears down cache-as-ram.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with verstage support as well as
VBOOT_DYNAMIC_WORK_BUFFER with direct link in romstage.
Change-Id: I8de74a41387ac914b03c9da67fd80f8b91e9e7ca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11824
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Changes to CR1 and CR2 were effectively overwriting the backlight
configuration from the devicetree with static values.
Instead read the maximum brightness value from BCLM (backlight
modulation frequency) and calculate the target level (Arg0 is the
target level as percentage).
Turned out that _BQC has to return a value from the list returned by
_BCL. So XBQC got a little heavier to search for the correct value.
Change-Id: I35419993c8250c95fc69ba4db30db9dba9e6f8ff
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11704
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
The two cases only differ in the register locations.
As the values in BRIG were all the same, consolidate them. They also
got normalized to percentages as the ACPI spec wants that (0x61 was 100%
before).
Change-Id: I9216a953bb89458ed102c39194ea370cbf463d5e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11703
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Consolidate some common (and mostly broken) code. Will try to fix things
in separate commits.
Maybe, igd.asl taken from gm45 (the non-PCH case) could also be used for
i945 and sch. But this needs further investigation.
Change-Id: Id3663bf588458e1e71920b96a3149f96947921e9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11702
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
In order to introduce a verstage which performs vboot
verification the cache-as-ram environment needs to be
generalized and split into pieces that can be utilized
in romstage and/or verstage. Therefore, the romstage
pieces were removed from the cache-as-ram specific pieces
that are generic:
- Add fsp/car.h to house the declarations for functions in
the cache-as-ram environment
- Only have cache_as_ram_params which are isolated form the
cache-as-ram environment aside from FSP_INFO_HEADER.
- Hardware requirements for console initialization is done
in the cache-as-ram specific files.
- Provide after_raminit.S which can be included from a
romstage separated from cache-as-ram as well as one that
is tightly coupled to the cache-as-ram environment.
- Update the fallout from the API changes in
soc/intel/{braswell,common,skylake}.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I2fb93dfebd7d9213365a8b0e811854fde80c973a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302481
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Id93089b7c699dd6d83fed8831a7e275410f05afe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11816
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of just passing bits, tsc_low, tsc_high, and an
opaque pointer to chipset context those fields are bundled
into a cache_as_ram_params struct. Additionally, a new
struct fsp_car_context is created to hold the FSP
information. These could be combined as the existing
romstage code assumes what the chipset_context values are, but
I'm leaving the concept of "common" alone for the time being.
While working in that area the ABI between assembly and C code
has changed to just pass a single pointer to cache_as_ram_params
struct. Lastly, validate the bootloader cache-as-ram region
with the Kconfig options.
BUG=chrome-os-partner:44676
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: Ib2a0e38477ef7c15cff1836836cfb55e5dc8a58e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/300190
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Change-Id: Ic5a0daa4e2fe5eda0c4d2a45d86baf14ff7b2c6c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11809
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Only one value would work with corresponding gma code currently (which one
depends on board). Going forward, it's possible to compute which number can
be used, so there is no need to keep this info around.
Change-Id: Iadc77ef94b02f892860e3ae8d70a0a792758565d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11862
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Commit 47818b4d6017b89e398cfbc86e3c437e0f81cfdf
(fsp/cache_as_ram.inc and boards: Fix incorrect usage of POST_IO)
breaks the logic which decides whether FSP
could be found or not in cache_as_ram.inc.
Fix the error by inverting the logic of the test.
TEST=Bootet mc_tcu3 board
Change-Id: I993d3422ac406d204a53e4dc890210fb9a52469d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11806
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
POST_IO is a user-visible config bool. fsp_1_0/cache_as_ram.inc made a
mess of it, by forcing a build-time error when CONFIG_POST_IO was not
being set. fsp 1.0 boards ended 'select'ing this in their Kconfig.
Refactor fsp/cache_as_ram.inc handling of POST codes, and remove the
"select POST_IO" from boards that have it. Instead of implementing an
ad-hoc changing post code display and a delay based on port 0xed, just
encode the FSP failure code in the POST code. Since FSP failure codes
are > 16, we can encode the failure code in the lower nibble, and theirfailing function in the upper nibble.
Change-Id: Iaa3e6533e8406b16ec0689abd704984d79293952
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8485
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
The EM100Pro allows the debug console to be sent over the SPI bus.
This is not yet working in romstage due to the use of static variables
in the SPI driver code. It is also not working on chipsets that have
SPI write buffers of less than 10 characters due to the 9 byte
command/header length specified by the EM100 protocol.
While this currently works only with the EM100, it seems like it would
be useful on any logic analyzer with SPI debug - just filter on command
bytes of 0x11.
Change-Id: Icd42ccd96cab0a10a4e70f4b02ecf9de8169564b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Users of DRIVERS_UART_8250MEM_32 would have to also select
DRIVERS_UART_8250MEM to avoid missing Kconfig dependencies. Instead,
do what the OXPCIE driver dies and select the appropriate options.
Change-Id: I40d93df024fcb3a9ad6dc51d6a5966e7b1b6c07f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11786
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
In order to support FSP 1.1 relocation within cbfstool
the relocation code needs to be moved into commonlib.
To that end, move it. The FSP 1.1 relocation code binds
to edk2 UEFI 2.4 types unconditionally which is separate
from the FSP's version binding.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: Ib2627d02af99092875ff885f7cb048f70ea73856
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11772
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that the commonlib/endian.h routines have landed utilize
those in the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: If431d64fd2843bea864d971ca1ea06b07c0d6435
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11771
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Using a copiler to compile something that's already a binary is pretty
stupid. Now that Stefan converted most microcode in blobs to a plain
binary, use the binary version.
Change-Id: Iecf1f0cdf7bbeb7a61f46a0cd984ba341af787ce
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11607
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Id2063fb29226dcb55fe84f680b7b9cb10313ef2b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11753
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Avoid specifying the size of the microcode in microcode_size.h.
Instead, the size will be determined during build time and
microcode_size.h will be generated. This way, the size does
not need to be adjusted by hand.
Change-Id: I868f02b0cc03af12464a6a87c59761c200eb2502
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11709
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Since the TPM _CRS method creates named objects it needs
to be serialized to prevent a warning in recent iasl.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build glados with iasl-20150717
Change-Id: I59a52552ab24b7d9c9928331aa8c8d19f54fd1b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a5c474c94980661573a99eb94d5f661f2d0114b
Original-Change-Id: Ie9d164ea8781304dd0bf1833d182d7c601b8e18d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302162
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11715
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
In order for easier consumption in userland tools split the
FSP 1.1 relocation logic into a single file w/ an aptly named
function name.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I49998b8621611c638375bc90884e80d0cd3bdf78
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bc898e1c528df60683575d553d6194a1e8200afa
Original-Change-Id: I736c0059d43f6d0be4fdb6e6f47cdb5c189a7ae8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298833
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11665
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
UEFI defines everything as little endian. Additionally the
EDK II header files assume they are used on machines
which are running UEFI -- thus little endian. This patch
attempts to fix up all the possible endian violations
when running on a big endian machine. This is for
in preparation of using the FSP 1.1 code in userland
for relocating FSP images.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I39f4de84688e48978a4650303b8af8345f44fd03
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3c7eab9b7c10765355feffa3c3cac403275f9479
Original-Change-Id: I33a7661281307cf31ae33899d1a4eb6a2fbd01a1
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298832
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In order to integrate fsp 1.1 relocation with cbfstool one
needs to be able to supply the address to relocate the FSP
image. Therefore, allow this by returning offset for return
values. Note that exposed API has not changed.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. Confirmed relocation values matched.
Change-Id: I650a08ffb9caf7e0438a988cae9bec56dd31753c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 53870b0df809418e9a09e7d380ad2399a09fb4fb
Original-Change-Id: Ic2ec63681ed4e652e2624b40e132f95d1e5a0887
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/298831
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/11663
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
FSP has some unique attributes which makes integration
cumbersome:
1. FSP header files do not include the types they need. Like
EDKII development it's expected types are provided by the
build system. Therefore, one needs to include the proper
files to avoid compilation issues.
2. An implementation of FSP for a chipset may use different
versions of the UEFI PI spec implementation. EDKII is a
proxy for all of UEFI specifications. In order to provide
flexibility one needs to binding a set of types and
structures from an UEFI PI implementation.
3. Each chipset FSP 1.1 implementation has a FspUpdVpd.h
file which defines it's own types. Commonality between
FSP chipset implementations are only named typedef
structs. The fields within are not consistent. And
because of FSP's insistence on typedefs it makes it
near impossible to forward declare structs.
The above 3 means one needs to include the correct UEFI
type bindings when working with FSP. The current
implementation had the SoC picking include paths in the
edk2 directory and using a bare <uefi_types.h> include.
Also, with the prior fsp_util.h implementation the SoC's
FSP FspUpdVpd.h header file was required since for providing
all the types at once (Generic FSP 1.1 and SoC types).
The binding has been changed in the following manner:
1. CONFIG_UEFI_2_4_BINDING option added which FSP 1.1
selects. No other bindings are currently available,
but this provides the policy.
2. Based on CONFIG_UEFI_2_4_BINDING the proper include
paths are added to the CPPFLAGS_common.
3. SoC Makefile.inc does not bind UEFI types nor does
it adjust CPPFLAGS_common in any way.
4. Provide a include/fsp directory under fsp1_1 and
expose src/drivers/intel/fsp1_1/include in the
include path. This split can allow a version 2,
for example, FSP to provide its own include files.
Yes, that means there needs to be consistency in
APIs, however that's not this patch.
5. Provide a way for code to differentiate the FSP spec
types (fsp/api.h) from the chipset FSP types
(fsp/soc_binding.h). This allows for code re-use that
doesn't need the chipset types to be defined such as
the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Change-Id: I894165942cfe36936e186af5221efa810be8bb29
Reviewed-on: http://review.coreboot.org/11606
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
|
|
Add a parameter to find_fsp which is the image base address. Adjust the
fake stack in cache_as_ram.inc to pass in the read-only FSP image base
address. In fsp_notify, pass in the read-only FSP image base address
when the FSP header pointer is NULL. In find_fsp, validate the FSP
binary image starting from the specified image base address.
BRANCH=none
BUG=None
TEST=Build and run on Skylake
Change-Id: Iac43c8aac8491390479af551765b514ca919928a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 592dae53f3b32694190cc5cb0fa6ca94df68aa95
Original-Change-Id: I7d6a415458a81f3b6bcdcfc9a90eceb2ac22144e
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/295593
Original-Commit-Ready: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11545
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The most common payloads do not need this set, so optimize for the
common case.
Change-Id: I2e5b68d74e9b91b41bbbcffc17d31d5c1bb38fd4
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8599
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Having no supplied printk level makes this info message
printed at all levels and so it shows up when booting with
DEFAULT_CONSOLE_LOGLEVEL=3.
BUG=chrome-os-partner:40635
BRANCH=none
TEST="USE=quiet-cb emerge-glados coreboot"
Change-Id: I6c52aafbe47fdf297e2caeb05b4d79a40a9a4b9d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e6cffc6d5a9fcda60a04f8a31f2b2ffe4b620c77
Original-Change-Id: Ie6715d15f950d184805149619bebe328d528e55a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297336
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11559
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The platform ID is an 8 character ASCII string, so our config should
take it in as a string, rather than a set of two 32-bit integers.
Change-Id: I76da85fab59fe4891fbc3b5edf430f2791b70ffb
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11465
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
|
|
The reason for hardcoding the position of the MRC cache was to satisfy
the alignment to the erase size of the flash chip. Hardcoding is no
longer needed, as we can specify alignment directly. In the long term,
the MRC cache will have to move to FMAP, but for now, we reduce
fragmentation in CBFS.
Note that soc/intel/common hardcoding of mrc.cache is not removed, as
the mrc cache implementation there does not use CBFS to find the cache
region, and needs a hardcoded address.
Change-Id: I5b9fc1ba58bb484c7b5f687368172d9ebe625bfd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11527
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
coreboot has no CREDITS file.
Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11514
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Commit "7dbf9c6 edid: Use edid_mode struct to reduce redundancy" moved
some fields from "struct edid" to "struct edid_mode". Adapt the bochs
and cirrus drivers to that change.
Change-Id: I9ec82a403d0264955d4b72496219036c7775c758
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/11502
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The BOOT_STATE_INIT_ENTRY macro can only be used in ramstage, however
the current state of the header meant bad build errors in non-ramstage.
Therefore, people had to #ifdef in the source. Remove that requirement.
Change-Id: I8755fc68bbaca6b72fbe8b4db4bcc1ccb35622bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11492
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When building up which files to include in romstage there
were both 'cpu_incs' and 'cpu_incs-y' which were used to
generate crt0.S. Remove the former to settle on cpu_incs-y
as the way to be included.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. No include file changes.
Change-Id: I8dc0631f8253c21c670f2f02928225ed5b869ce6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Iac4f275c14646b40ffe04fc5a6f6e1402cebfddf
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11464
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The #error messages only say that "CONFIG_* must be defined", which
conveys no more information that the compiler or assembler failing
when it encounters an undefined CONFIG_* symbol.
Change-Id: I6058474d4cd454cfc20290650425d379f388abd9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11461
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Avoid ASSERT() when a better solution exists, avoid UPPERCASE types
when C99 types exist, and use stdlib functions where possible.
Change-Id: Ia40ec8ff34ec82994b687d517dc4b145fb58716c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11455
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
We don't need the code in romstage, and it saves us a few #ifdefs.
Change-Id: I26d867566f07c7d80890cd01bf055be7497130d3
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
For some reason fsp 1.1 has a duplicate mechanism for saving
mrc data as soc/intel/common. Defer to the common code as all
the existing users were already using the common code.
BUG=chrome-os-partner:44620
BRANCH=None
TEST=Built and booted glados. Suspended and resumed.
Change-Id: I951d47deb85445a5f010d23dfd11abb0b6f65e5e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Original-Commit-Id: 2138b6ff1517c440d24f72a5f399bd6cb6097274
Original-Change-Id: I06609c1435b06b1365b1762f83cfcba532eb8c7a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/295236
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/11454
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Using struct prog and struct region_device allows for the
caller to be none-the-wiser about where FSP gets placed. It
also allows for the source location to be abstracted away
such that it doesn't require a large mapping up front to
do the relocation. Lastly, it allows for simplifying the
intel/commmon FSP support in that it can pass around a
struct prog.
BUG=chrome-os-partner:43636
BRANCH=None
TEST=Built, booted, suspended, and resumed on glados.
Original-Change-Id: I034b04ab2b7e9e01f5ee14fcc190f04b90517d30
Original-Signed-off-by: Aaron Durbin <adurbin@chroumium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/290830
Original-Tested-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibe1f206a9541902103551afaf212418fcc90e73c
Signed-off-by: Aaron Durbin <adurbin@chroumium.org>
Reviewed-on: http://review.coreboot.org/11193
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There was no implementation for uart_fill_lb() in the 8250mem
driver. Rectify this so when 8250MEM and CONSOLE_SERIAL are
employed then the build doesn't fail.
BUG=chrome-os-partner:43419
BRANCH=None
TEST=Built with glados using 8250MEM
Original-Change-Id: I35d6b15e47989c1854ddcee9c6d46711edffaf3e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289899
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Change-Id: I972b069a4def666f509268816de91ed6c0f655d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11169
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Run `indent -linux src/drivers/pc80/i8254.c` and manually put the `;` in
the while loop back on a separate line.
Change-Id: I58c4c5df3846a91ef92aafb608962dc26a21f811
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10452
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds UART8250MEM_32 feature flag to support
UART8250 compatible with 32bit access in memory mapped mode.
[pg: rebuilt to reuse the existing UART8250 8bit access driver
which reduces code duplication.]
Change-Id: I310e70dfab81dcca575e9931e0ccf93af70efa40
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0c3b2c628b854e8334540ff5158c2587dbfabf95
Original-Change-Id: I07ee256f25e48480372af9a9255bf487c331e51d
Original-Signed-off-by: Rishavnath Satapathy <rishavnath.satapathy@intel.com>
Original-Signed-off-by: Naveen Krishna Chatradhi <naveenkrishna.ch@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/271759
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Wenkai Du <wenkai.du@intel.com>
Original-Commit-Queue: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: http://review.coreboot.org/10998
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead
check to make sure they're defined and not zero. In some cases, zero
might be a valid value, but it didn't look like zero was valid in these
cases.
Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10886
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Update Makefile.inc to use the simplified CBFS image type.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: Ibb8413ab90b147e9d26d32639a8822c57ca54a46
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The many different places to put vboot support in can be confusing.
Instead of using libverstage (which isn't enough since those functions are
sometimes called outside that, too), mention all stages where it can resides
explicitly.
Change-Id: Idddb9f5e2ef7bcc273f429d9f432bd37b4573567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10728
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
That way it's available wherever the verstage code ends up, bootblock,
verstage or romstage.
Change-Id: I0665e297f199acd60cff93e1b39812f183115d33
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10707
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Because of a misunderstanding of how Kconfig files are parsed, the
OVERRIDE_MRC_CACHE_LOC symbol was added to make sure that the value
was correctly set. This is not needed unless for some reason the
Kconfig parser is suddenly rewritten to parse everything differently.
At some point, the value in the FSP's Kconfig file was updated to
OVERRIDE_CACHE_CACHE_LOC, while the entries in the mainboard
Kconfig files were not updated. This resulted in the default values
not getting set correctly by default on the FSP Bay Trail boards.
This removes the whole bunch of incorrect and unnecessary symbols and
just sets the default for the MRC cache location directly.
Change-Id: I1cec758576866b7e0677272b8309bfde8d4a1ee4
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10611
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
- 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>
|
|
All other Kconfig locations start with tabs.
Change-Id: I0ee5f0b0b82f85c8ae58b3626f142f159554efb3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10438
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
Change-Id: Ieb6f70f5b2863336bd6143b2dfbb1d67c4c26109
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10323
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
Change-Id: I534f992ed479c7cdc049bd598259b1f1cf2953b9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10354
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.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>
|
|
TPM_TIS_BASE_ADDRESS is technical setting, shouldn't be user-visible.
Change-Id: Ibf74f52be16fb7d2cfa78419087a4c3e7607368a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10271
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
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>
|
|
Change-Id: I8df5b7f6707957b925f7bb4dc06a717252c70868
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10275
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Tested-by: build bot (Jenkins)
|
|
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 1d7b9de3504e90f0886fccec3a1f8a783fd4cc58.
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)
|
|
Add FSP 1.0 source for comparison with FSP 1.1.
BRANCH=none
BUG=None
TEST=None
Change-Id: I8df349f97acfa74f4de3607d49633da3d4884546
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10116
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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)
|
|
Change-Id: Id1685c0b28ec8e3ab972a671af6f2de6f321c645
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9805
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
