According to ACPI spec all SSDTs should have distinct OEM table ID.
We end up with 2 SSDTs named "COREBOOT". Fix this.
Change-Id: I01bccb72758baf51c6b4263778716f4bb9d438c9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7016
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Otherwise "reserved" fields end up with a garbage instead of predictable
value.
Change-Id: I8a036769a8f86f1d6752651601de2800f4f1bd00
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7014
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Fix the error 'implicit declaration of function
"southcluster_smm_save_gpio_route"', when SMM module is added.
Change-Id: Ia050ab7e2b036541537b645d3fe4dc747cd1dff8
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7024
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
With SMM enabled the boot stopped while patching up global NVS in DSDT.
The cause is that both CPUs are assigned the same SMBASE address.
So update the "cpu_smm_do_relocation()" function so that each
CPU gets a different SMBASE address
Based on rmodule work that wasn't propagated to the FSP
version: commit 3eb8eb7eba
Change-Id: I77cd27d3a4f207411a689b5be572b4406a03f16b
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7026
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
The static library builder for the stub that interfaces to the
AGESA binary does not include config.h and kconfig.h, so any
header file changes that depend on Kconfig variables fail. Force
these two system headers to be included in the build of any AGESA
stub files.
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Change-Id: I2e8d38fa5aa21cc31b995ee3abe68ab3c3c55a68
Reviewed-on: http://review.coreboot.org/6979
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
In E-EDID (EDID v1.3), Monitor Name (0xfc) and Monitor Range Limits (0xfd) are
always required. However, some panels do not really have these fields. As a
workaround (and since we don't really use these fields), we only print warning
messages for that case.
Change-Id: I81b1db7d7f6c6f9320a862608dec4c7be298d7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193742
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c633215ef8342664d9a4478e821fc8aad368b7f3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7009
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On non-x86 systems, the location of the preram CBMEM console may not be in a
predictable place relative to other things in the linker script. That makes it
difficult to work with as its own section because the linker will complain if
you try to move backwards as it lays out memory. If the console header is
treated as an actual blob of memory which has to be put in the image, we'd
have to predict where to put it so that it isn't before something with a lower
address or after something with a higher address. Symbols, on the other hand,
can be defined arbitrarily.
Change-Id: I3257b981eee0c15bb997a9f2c55a03494c6ec6f0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193164
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a492761c27076bcac080013d509ae4aafd6dc3e3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7013
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The detail block may contain timing descriptor, or other fields like monitor
descriptor, so we should return 1 in detailed_block function when a valid
structure is found, otherwise for any EDID containing monitor descriptor we will
see following error messages:
EDID block does not conform at all!
Detailed blocks filled with garbage
Change-Id: Ib4e91d648741e5b54a558d53a1152273c7341427
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193002
(cherry picked from commit a1f212d6aaa14d5f795beeabdb8b7b8a79578c33)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6997
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ASCII Data String in EDID Monitor Descriptor (3.10.3) is "Stored as ASCII,
code page #437" and may contain special characters like '-'. The isalnum check
should be removed.
Also, the "Monitor Name" (0xfc) does not need to always end with 0Ah, so the
name_descriptor_terminated should be replaced by has_valid_string_termination.
Change-Id: I12a670237e12577fc971c0fbd9b2a61c82040ad3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193001
(cherry picked from commit 671f82fd5963e32e72d3886aa242cb3e8519f226)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6996
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When parsing "extensions", we should skip the first EDID (main) block and start
from offset 128 (EDID may have only main block, so an EDID without any
extension is fine) because the header format for main block and extensions are
different.
Without this we will see "Unknown extension block" on all EDIDs, and seeing an
error (1) return value for EDIDs without extension.
Also, after the first "unknown" error is fixed, we can now collect all return
values from parse_extension, and return an error when any of the extensions are
wrong (not just last one).
Change-Id: I0ee029ac8ec6800687cd7749e23989399e721109
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193011
(cherry picked from commit fdf0cc2e9573c19b550fa2b5e4e06337b114f864)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6995
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This enables S3 Suspend / Resume support for MinnowMax board
using Intel's Bay Trail FSP
Tested resume from Power Button and Magic Packet.
Change-Id: I021122a68c05f2e725cabb8f3946249afe802bbe
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6972
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
This adds S3 Suspend / Resume support to Intel's Bay Trail FSP
It is based on the "src/soc/intel/baytrail/romstage/romstage.c"
implementation.
Change-Id: If0011068eb7290d1b764c5c4b12c17375fb69008
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6937
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
The W25Q128FW spi part is programatically equivalent
to the other W25Q128 parts except it operates at 1.8V.
Just add a new entry with the appropriate ID.
Tested on a modified MinnowMax Board.
Change-Id: Id6a426418a7f785a9d959b02a9e3d2ffc421804f
Signed-off-by: Mohan D'Costa <mohan@ndr.co.jp>
Reviewed-on: http://review.coreboot.org/6971
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
In case we get an invalid thermal reading, let's run the fan
at full speed rather than at low speed. This might impact the
user experiance slightly in cases where the bad reading does
not happen while the system is hot, but it will increase stability
in the cases where the system is actually overheating.
Also, set the critical temperature below tjmax, because otherwise
thermal shutdown by the OS will never be triggered.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Iab262f1f17a5dff875c596d9e8d50e4e50ee90f9
Reviewed-on: https://chromium-review.googlesource.com/188556
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 721fc2361ea9c6fea75409be57726294ce840f03)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6962
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch fixes the remaining few bugs in our shiny new cache iteration
by set/way/level algorithm to actually make it work: It makes it start
from cache level 0 (previously it would always start at LoC and be
"done" instantly), fixes up the two shifts that isolate the set bits at
the end (which didn't seem to account for the fact that the first shift
affects the second), and throws an S bit on that last shift so that it
actually affects the conditionals after it.
In addition, also moves the next_level block to the top so that we can
share (and thus eliminate) some code at initialization, and turns the
whole thing into a thrice-instantiated macro to create functions that
fit our existing interface.
Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183879
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 6d94f8330191c316fe093ddb5288329453da8a4b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6932
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch pulls in NetBSD's full cache flushing algorithm for ARM, to
replace our old, slow and slightly overzealous C-only implementation.
It's a beautiful piece of code that manages to run on only caller-saved
registers (meaning it doesn't need to write to memory) in a very tight
loop, and it's BSD-licensed to boot (which we need for libpayload).
Unfortunately it's also not quite correct, but I can fix that. Pulling
the original in a separate commit to make it more obvious what changes
are mine.
Change-Id: I7a71c9e570866a6e25f756cb09ae2b6445048d83
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183878
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4698467320613d7ddc39714f40aacbc990af9399)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6931
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Fix up the following commit by enabling the MTRR's before enabling caching.
7756fe7 x86: Minimize work done with the caches disabled in mtrr functions.
Also fix two typos in comments.
Change-Id: If751b815f9dab781fc38c898cf692f0940c57695
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6969
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The products having shipped, and living in their own branch,
we might as well enable native graphics since:
1. it works
2. it removes a blob and the only good blob is a dead blob
3. it's faster
4. when we have problems, we can diagnose them more easily
5. when we get to newer kernels the boot time will magically get faster
as the driver realizes graphics is running. Where else do you get a 3-4 second
speedup for free?
Change-Id: Iad937320e7f46b1de7ab00dace04115a7f182ed1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181225
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 7b567d87a9fcf6736e90e730bd052e4465d57bdf)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6912
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The name snow goes by in many places in chromeos is daisy. Snow is technically
a variant of daisy and should really be called daisy_snow, but for historical
reasons the daisy board with no variant was used instead. To make it easier to
work with within chromeos, this change renames the snow board to daisy.
Change-Id: I569b31bf417db55be91832f15271bea4bc30f163
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/183553
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 13f24d967251c18dce2a00bcea915f448c4c6aa7)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6929
Tested-by: build bot (Jenkins)
The code in src/cpu/x86/mtrr/mtrr.c disables caching in a few places when
changing mtrr settings. While I can't find anything that says that's actually
required, I can believe it's necessary. With that said, other code around the
wrmsr instructions which actually modify the settings should be able to run
with caching enabled with no ill effects.
This is particularly true for two calls to printk, one in the fixed mtrr code
and one in the variable, which could result in an arbitrary amount of work
being done without caching. When changing the implementation of the cbmem
console, these two printks caused a significant regression in boot performance
on link of about 70ms which is about 10% of total firmware boot time. When the
window where the cache is disabled is minimized, both this and the new
implementation were about 30ms faster than the original boot time.
For the variable MTRRs, we now store what we want to set the MSRs to and then
write them all at once at the end of commit_var_mtrrs(). This way we don't
have some set and some not, but we still minimize the time we spend with the
caches disabled.
Change-Id: I5139b262bd2d13f79afd88e2e2c0f514fb3e27c9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187811
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 31529d6d965676c6cedeb62137eabc26819956fc)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6952
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The nyan_big mainboard is very similar to nyan, but will be different in a few
ways. For instance, the BCT will be different, and the GPIOs may need to be
configured slightly differently.
This change also adds prefixes to the kconfig variables in "choice" blocks
for both boards since having multiple instances of choice blocks with the same
options confuses kconfig even if all of the instances have mutually exclusive
dependencies.
Change-Id: I290a32e47fc118bd4b86d543df617ad324325dbc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/183532
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d1a453fe1aa68b3d12936dd48cc6c94b54f81579)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6927
Tested-by: build bot (Jenkins)
This is a fix up for recent patch:
c505837 arm: Have the linker garbage-collect unused functions and variables
I missed adding --gc-sections to a couple of the ramstage lines.
Change-Id: I81178eb99fddbd99c603c79ba506db51af975b27
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6956
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit 0092c999 (i945: Support text mode gfx init) [1] broke building
the Lenovo X60 with native graphics initialization by selecting
`CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT`.
CC northbridge/intel/i945/gma.ramstage.o
src/northbridge/intel/i945/gma.c: In function 'intel_gma_init':
src/northbridge/intel/i945/gma.c:398:2: error: implicit declaration of function 'vga_textmode_init' [-Werror=implicit-function-declaration]
Selecting the Kconfig variable VGA makes the declaration of the
function `vga_textmode_init()` to be included by the preprocessor.
[1] http://review.coreboot.org/6723
Change-Id: Iecbb2898193078b8738425cea13cb7e6da508cab
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6947
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934)
This patch is essentially a squash of aarch64 changes made by
these patches:
d955885 coreboot: Rename coreboot_ram stage to ramstage
a492761 cbmem console: Locate the preram console with a symbol instead of a sect
96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3
3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry
ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage
25fd2e9 aarch64: Remove CAR definitions from early_variables.h
65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM
9484873 aarch64: Change default exception level to EL2
7a152c3 aarch64: Fix formatting of exception registers dump
6946464 aarch64: Implement basic exception handling
c732a9d aarch64/foundation-armv8: Basic bootblock implementation
3bc412c aarch64: Comment out some parts of code to allow build
ab5be71 Add initial aarch64 support
The ramstage support is the only portion that has been tested
on actual hardware. Bootblock and romstage support may require
modifications to run on hardware.
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6915
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Commit 75c83870 (azalia: Shrink boilerplate) [1] removed the header
file `hda_verb.h`. This header is still included in the mainboard’s
`gma.c`, causing the following build error, when native graphics
initialization is enabled.
CC mainboard/google/falco/gma.ramstage.o
src/mainboard/google/falco/gma.c:34:22: fatal error: hda_verb.h: No such file or directory
This was not caught, as native graphics initialization is not enabled
for the build tests.
It turns out that the array `mainboard_cim_verb_data` is not used in
`src/mainboard/intel/wtm2/hda_verb.h`, so fix the problem by removing
the inclusion.
[1] http://review.coreboot.org/6840
Change-Id: I91e4f00a3030bdef0278102df2783258389bca13
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6946
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit 75c83870 (azalia: Shrink boilerplate) [1] removed the header
file `hda_verb.h`. This header is still included in the mainboard’s
`i915.c`, causing the following build error, when native graphics
initialization is enabled.
CC mainboard/intel/wtm2/i915.ramstage.o
src/mainboard/intel/wtm2/i915.c:34:22: fatal error: hda_verb.h: No such file or directory
This was not caught, as native graphics initialization is not enabled
for the build tests.
It turns out that the array `mainboard_cim_verb_data` is not used in
`src/mainboard/intel/wtm2/hda_verb.h`, so fix the problem by removing
the inclusion.
[1] http://review.coreboot.org/6840
Change-Id: Ic902581c6809a1069e169cc874678146a24d75f3
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6945
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
