These settings are specific to the SteppeEagle SOC and should
be made in its northbridge code rather than the CPU code.
Change-Id: I1a231f95225e1414b0cbc026a2a7b7797bd91fca
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8254
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
They seem to have been copy-pasted during the backport from sandybridge.
Change-Id: I2277bb90e6da2676b31eb2665b7c15f074e3d4bf
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8295
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
coverity isn't too happy with ccache, and given the current setup
it also isn't too useful.
Change-Id: I420fdd7350dff29296d7101569cb183afe1f92d6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8478
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This tells abuild that it can in fact build arm64
images.
Change-Id: I47695372053513ca039e118776aa904ea0afa21d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8474
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
It's not very useful to try to link a host tool into
the bootblock image.
Change-Id: Id3b6496c061d41184fbb516d56746855b455b0c3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8473
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
So don't treat them as such. Fixes interactions with
class initialization (eg. verstage) on lint.
Change-Id: I8b5f2a56e73ba934590c45494e6a49f93c42096f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8472
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Note that the limit is not set in the devicetree.cb which use native
sandybridge raminit, as it is not needed. When that isn't set, it's
automatically set to zero, and when we find that, we automatically
return the default limit. Thus behavior isn't changed for any board.
Change-Id: I447399eea71355612b654710a56f3a0077c2f7f9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8476
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We can successfully bring up systems if timC calibration fails, as has
been demonstrated with google/butterfly. As a result, do not die(),
but simply print a message and continue in the hope that we may be
able to boot.
Change-Id: I49ec80324f63b2d45ae8f61c5c26454acb9c232f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8475
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Builds with cbootimage.
BUG=None
BRANCH=None
TEST=build test
Original-Change-Id: I796f171031bacf17106878d4a554e8f1cbfe93f8
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/203145
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 4778ae4d08a25306407f0fd2fe47976d63463f9d)
Increase the bootblock area for the larger BCT that is generated by
the coreboot version of the cbootimage tool.
Change-Id: I42b8208504bf4936a9fa14f820d665590f6a3754
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8413
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Changes might be required for .bct files as we get to know more.
Pulling in files from mainboard nyan for now
BUG=None
BRANCH=None
TEST=Compiles successfully for rush
Change-Id: Iaf81a384af0469c77940cf7309ba68018110b5eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/203144
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit d3633f8cf8c01a07b54ceef2dd7bf7a64afd7c76)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8412
Reviewed-by: Aaron Durbin <adurbin@google.com>
This patch is to perform software triggered RAM re-repair in
the warm boot path.
"RAM" actually refers to the CPU cache here (yeah, I know, but that's
how the manuals call it). This is some magic hardware thing that must be
done every time after applying power to the main CPU cores or their
cache may have random failures in some very rare cases.
Also, note that this file isn't built in coreboot proper, but is a
companion binary for kernel. It resides here for safe keeping.
BUG=chrome-os-partner:30430
BRANCH=nyan
TEST=run suspend_stress_test on nyan.
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Change-Id: I540f8afbffa323d1e378cb6ba6a20be4afd08339
Original-Reviewed-on: https://chromium-review.googlesource.com/207422
Original-Tested-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Original-Commit-Queue: Yen Lin <yelin@nvidia.com>
(cherry picked from commit f06c413c42819f8f75d9b0fecde02b82583f1d2a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I151ce943ce8623e46cc55f890bbd6fc641cc2b98
Reviewed-on: http://review.coreboot.org/8416
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is to perform software triggered RAM re-repair in
the cold boot path.
"RAM" actually refers to the CPU cache here (yeah, I know, but that's
how the manuals call it). This is some magic hardware thing that must be
done every time after applying power to the main CPU cores or their
cache may have random failures in some very rare cases.
BUG=chrome-os-partner:30430
BRANCH=nyan
TEST=run cold reboot test on nyan.
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Change-Id: I87869431e80e7bc66948a7f67f35e5b907993765
Original-Reviewed-on: https://chromium-review.googlesource.com/207362
Original-Tested-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yen Lin <yelin@nvidia.com>
(cherry picked from commit d999f5ecc31d90c8dce1dd91533bc34ffd3c03f2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iaee1d7f9fa8856f26d7ead70eaeeff9d80dbb181
Reviewed-on: http://review.coreboot.org/8415
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Based on TRM, cpu clock enabling and reset vector setting should
all be done properly before ungating cpu power partition. Otherwise,
with current code, a race condition could occur where cpu starts but
reset vector has not been set.
BUG=chrome-os-partner:30064
BRANCH=none
TEST=run nyan_big reboot test. No issue is experienced.
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Change-Id: I571e128693bb2763ee673bd183b8cf60921dc475
Original-Reviewed-on: https://chromium-review.googlesource.com/206682
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
(cherry picked from commit 106480ff32406c899a24544fdfab858db5afd1d9)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3da6018dd68e4c15d2c58db566a9745b0b26c365
Reviewed-on: http://review.coreboot.org/8414
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All code must agree on PCI enumeration for the CK804 device,
define these only once. The definition in enable_usbdebug.c was
different and was assumed incorrect.
Change-Id: I7d25c145afbad41db81a6b9b4f3956ad50fcb9f2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8339
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This reverts commit b871687991.
Use of #ifndef here makes it error-prone and hides errors.
Change-Id: I13a999250c80adedb6b3fd4963a862ff106750f0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8338
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This patch allows the user to set a maximum HT link frequency in
NVRAM, paralleling a similar option available in the proprietary
BIOS on some mainboards.
Change-Id: Iba3789262eefa52421e76533cbf14d9da2ef1de8
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8462
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing code generated invalid ACPI processor objects
if the core number was greater than 9. The first invalid
object instance was autocorrected by Linux, but subsequent
instances conflicted with each other, leading to a failure
to boot if more than 10 CPU cores were installed.
The modified code will function with up to 99 cores.
Change-Id: I62dc0eb61ae2e2b7f7dcf30e9c7de09cd901a81c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8422
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
All settable memory controller options are now controlled by NVRAM,
making the Kconfig options irrelevant.
Change-Id: I9b2c8798d830e5c41bb9a108514e60d784d2ebc5
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8452
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
K10 processors cannot operate at full memory speeds when more than a
certain number of DIMMs are installed on a specific channel. The
allowed DIMM numbers and speeds are listed in the BKDG; this patch
implements the appropriate frequency reduction to ensure stability.
Change-Id: I8ac5b508915e423d262ad36c49de1fe696df2ecd
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8435
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
These values were originally hard-coded in the AMD MCT wrapper.
Change-Id: I12056d38d5348e70a44c192385e22e715e207792
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8454
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In specific configurations, such as homogeneous supercomputing systems,
changeable NVRAM parameters are more of a liability than a useful tool.
This patch allows a coreboot image to be compiled that will always set
the NVRAM parameters to their default values, reducing maintainance
overhead on large clusters.
Change-Id: Ic03e34211d4a58cd60740f2d9a6b50e11fe85822
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8446
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This fixes errors of the form:
error: 'Dct0MemSize' may be used uninitialized in this function
Change-Id: Ifc853aea9050994f5641c57a081aa0667331c995
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8455
Tested-by: build bot (Jenkins)
TEST: Boot with corrupted CMOS and make sure console level defaults
to SPEW, instead of 0, and that cbmem console is not empty.
Change-Id: I8ab2423e99bbe116f52ad27f4b20427d8557f6ff
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8379
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch allows the following memory controller settings to be overridden in NVRAM:
Memory frequency limit
ECC enable
ECC scrub rate
Change-Id: Ibfde3d888b0f81a29a14af2d142171510b87655e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8438
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Currently the coreboot console log contains messages in the following
form.
Show all devs...Before device enumeration.
[…]
Show all devs...After init.
Add a space after the ellipse, so it’s better readable and it does not
look like a newline is missing.
Show all devs... Before device enumeration.
[…]
Show all devs... After init.
Change-Id: Ifa2a37b8d60c433c219df7533a79fced03b6271a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8424
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the flags used by the Nvidia makefile and use HOSTCC
to build cbootimage. Note that adding -g makes the BCT
very large, so leave that flag out.
Change-Id: I4431efffdfdcbd030665b26f5b799352e38d1f95
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8411
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On x86, change the type of the address parameter in
read8()/read16/read32()/write8()/write16()/write32() to be a
pointer, instead of unsigned long.
Change-Id: Ic26dd8a72d82828b69be3c04944710681b7bd330
Signed-off-by: Kevin Paul Herbert <kph@meraki.net>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7784
Tested-by: build bot (Jenkins)
The default linking behavior of ramstage was changed in commit
* 8f99378 ARMv7/Exynos: Fix memory location assumptions
However, that commit failed to address the issue of maintaining
linking behavior on non-Exynos chips. As a result we ended up
linking ramstage at address 0, which is outside of SDRAM.
Explicitly link ramstage at SDRAM base for A10. This patch does not
address the issue on other chips that were broken by commit 8f99378.
Change-Id: I90fa41d3eabf110b5ab24c31b78ac6d0474e4083
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8443
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
PCIe root ports on devices 0:15.0 to 0:15.3 should at first all
appear visible in hardware. The real configuration will be done by
vendorcode once we call sb_Before_Pci_Init().
Change-Id: I01a46c630aa6d55a94af45da6b78c97df7553e4f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8387
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This has nothing to do with SATA controller. We only need to
fill the table with defaults before we parse devicetree for
changes to device configuration.
Change-Id: Ic4b28b5992ec9bfdf252f61b1c86b0162243cc95
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8386
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
If devicetree.cb has GPP port off, really disable it before even
trying to do link training.
Change-Id: I810945da28d86768e88249dc4d29a50ad9f9959b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8385
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
A set of pins can be configured for GPIO or (parallel) PCI bridge use.
When requested configuration is 0:14.4 enabled, register programming
must be done before attempting to enumerate devices behind the bridge.
When requested configuration is 0:14.4 disabled, we must not even
temporarily enable pins for PCI use to avoid spurious GPIO state changes.
As our PCI subsystem currently does not configure visible PCI bridges
that are marked disabled, we cannot mark 0:14.4 disabled just yet but
need to handle pcengines/apu1 as a special case.
Drop related dead code.
Change-Id: I8644ebae43b33121ef2a7ed30f745299716ce0df
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8329
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Kyösti Mälkki