On one particular TV the TV was holding SDA low when it came up. It
would release the SDA when the SCL went low the first time.
Unfortunately the HDMI i2c port wouldn't transmit until the SDA was
released.
Let's detect this case and insert a bogus clock pulse to try to get the
other side to release SDA.
It's unclear why the kernel doesn't have this problem.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia TV works now
Change-Id: Ic9d27eb69bdc9c5fb11a68258e0c755cdc8b79d7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 356ee7503f04e741a41be37ad573b588067b7114
Original-Change-Id: I4b6361877e0576cc4ea2f643f073f1aab660e434
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309258
Original-Reviewed-by: Agnes Cheng <agnescheng@google.com>
Original-Commit-Queue: Agnes Cheng <agnescheng@google.com>
Original-Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Original-Tested-by: Agnes Cheng <agnescheng@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309546
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12451
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch enables GPP_B5 as ACPI_SCI for wake.
It also defines touchpad wake device in ACPI with GPE0_DW0_05 for _PRW.
BUG=none
BRANCH=none
TEST=emerge-lars coreboot
Change-Id: I2b65f6a37783ecdbdbc32ebe613243e042c865e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ec5b629f920984564f12f2c09458ed300d031f69
Original-Change-Id: I9bd2b3595ae833fa5d07d97a7cda4a29041be837
Original-Signed-off-by: David Wu <David_Wu@quantatw.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/311890
Original-Commit-Ready: David Wu <david_wu@quantatw.com>
Original-Tested-by: David Wu <david_wu@quantatw.com>
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/12449
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Use the keyboard backlight to provide indication that the system is
booting. This is useful for determining that a system is in S0 and
is running BIOS code.
BUG=chrome-os-partner:47435
BRANCH=none
TEST=boot on chell and see keyboard backlight come on early
Change-Id: I43e699bcc2f34998d3d6ce33ce72c7b04b55c146
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a3a0147b6de681365a9c995175076d5f397016fb
Original-Change-Id: I2441c28431e71b13b70e6533e175d29ccfd8d7e9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312358
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12448
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The GPIO for USBA_1_ILIM_SEL_L should be low to enable 2A charging
from the Type-A port.
BUG=chrome-os-partner:47172
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I1bbcdd467684e7c1372c8ca862d498fb6cbb966c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c8a8fbed6d0fd7aea0a41db2bde104fe7a05cabe
Original-Change-Id: I3b18cbb204cfa19e50f34ea9533018e286342513
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312451
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12447
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
For the rails controllable by the host processor through
gpios turn them off in the sleep paths. The result is that
S3 and S5 will turn off those rails.
BUG=chrome-os-partner:47228
BRANCH=None
TEST=Built for chell.
Change-Id: I5843f13be43a6ec143600585a5a0c47563e533dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ddd5860dc0cfee68ec2f77f4931665740bede08c
Original-Change-Id: Ife0e2fb11373dd129e20b914b45cd5b56c3493f7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312321
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/12446
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
For the rails controllable by the host processor through
gpios turn them off in the sleep paths. The result is that
S3 and S5 will turn off those rails.
BUG=chrome-os-partner:47228
BRANCH=None
TEST=Built and booted glados. Suspended and resumed.
Change-Id: I6d45683b64ca5f7c3c47e11f95951bd2d9abf31e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ed432e2b5535da6f872a53b76886d983f00b4e8e
Original-Change-Id: I94d7e0b00bf7e7da8dc59f299e41b72e8fcb64f4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312320
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/12445
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
By calling cbmem_recovery() with `0`, we rewrote the cbmem table even
on the resume path. By that, we lost the OS' resume vector and ended up
loading the payload.
Change-Id: Ic24a12d4143d6924321b1d01f07a467c58c4e9ea
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/12420
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix regression introduced by:
3660c0fc65
"northbridge/intel/sandybridge: Enable PEG clock-gating on demand"
Issue observed:
GNU/Linux kernel crashes in earlyinit on systems without PEG devices.
The crash occurs on every boot in different functions.
There's no problem on systems with PEG enabled.
Test system:
* Lenovo T530
* Intel Core i5-3320M CPU
* Fedora GNU/Linux 4.1
* PEG disabled in devicetree
Problem description:
Tests shows that modifing PEG chicken bit or device enable bits
after setting BIOS_RESET_CPL causes random crashes in GNU/Linux.
Problem solution:
Disable PEG devices before setting BIOS_RESET_CPL.
Final testing results:
No more random kernel crashes.
Change-Id: I4a967c2d00d7d1e4426cf5abdd5f616c21557da7
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/12112
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Issue observed:
Coreboot stops at: "Not enough MTRRs available!"
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* ATI Radeon HD4780
Problem description:
In case the IGD does not claim VGA decode, the code path taken results
in an integer overflow as uma_memory_base isn't initialized.
The MTRR assignment will fail, because of invalid memory regions.
Problem solution:
Properly initialize uma_memory_base to prevent possible integer overflow.
Final testing results:
The system boots again with IGD not claiming VGA decode.
Change-Id: I025be23b1defb6155469a3eee66569e49a695e7f
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11918
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Issue observed:
Intel raminit works in about 50% of all test-cases on lenovo x220.
Problem solution:
Prefer a smaller valid value over the measured one for
initial timB timings.
Final testing result:
Tests on x220 shows that the issue was resolved.
The test system booted successfully ten times in a row.
Tests on Gigabyte GA-B75M-D3H revealed no regressions.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMM: "Crucial 2GB 256Mx64 CT2566aBA160BJ"
Change-Id: I1a115a45d5febf351d89721ece79eaf43f7ee8a0
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11248
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
This patch removes the old arm64/stage_entry.S code that was too
specific to the Tegra SoC boot flow, and replaces it with code that
hides the peculiarities of switching to a different CPU/arch in ramstage
in the Tegra SoC directories.
BRANCH=None
BUG=None
TEST=Built Ryu and Smaug. !!!UNTESTED!!!
Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12078
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch expands the existing ENV_<stage> macros in <rules.h> with a
set of ENV_<arch> macros which can be used to detect which architecture
the current compilation unit is built for. These are more consistent
than compiler-defined macros (like '#ifdef __arm__') and will make it
easier to write small, architecture-dependent differences in common code
(where we currently often use IS_ENABLED(CONFIG_ARCH_...), which is
technically incorrect in a world where every stage can run on a
different architecture, and merely kinda happened to work out for now).
Also remove a vestigal <arch/rules.h> from ARM64 which was no longer
used, and genericise ARM subarchitecture Makefiles a little to make
things like __COREBOOT_ARM_ARCH__ available from all file types
(including .ld).
BUG=None
TEST=Compiled Falco, Blaze, Jerry and Smaug.
Change-Id: Id51aeb290b5c215c653e42a51919d0838e28621f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12433
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Without BOOTBLOCK_CONSOLE any call to die() fails due to die() symbol
not being defined at link time. die() is not is dependent on the
console backend, and can function without it (the prink gets no-oped).
Change-Id: I6cecafb576c3b1e901f3927c777f6282174fb259
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/12356
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The microcode for Bay Trail that's in the blobs repo is for the
M and D chip variants only. The fsp_baytrail directory is for
Bay Trail I chip variants, and will not boot if the M/D microcode
is used. The microcode for the I variant is supplied as part
of the Bay Trail FSP package.
Change-Id: I5493deb1626dc3cf037053e13e092f5a1143a13a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The existing arm64 architecture code has been developed for the Tegra132
and Tegra210 SoCs, which only start their ARM64 cores in ramstage. It
interweaves the stage entry point with code that initializes a CPU (and
should not be run again if that CPU already ran a previous stage). It
also still contains some vestiges of SMP/secmon support (such as setting
up stacks in the BSS instead of using the stage-peristent one from
memlayout).
This patch splits those functions apart and makes the code layout
similar to how things work on ARM32. The default stage_entry() symbol is
a no-op wrapper that just calls main() for the current stage, for the
normal case where a stage ran on the same core as the last one. It can
be overridden by SoC code to support special cases like Tegra.
The CPU initialization code is split out into armv8/cpu.S (similar to
what arm_init_caches() does for ARM32) and called by the default
bootblock entry code. SoCs where a CPU starts up in a later stage can
call the same code from a stage_entry() override instead.
The Tegra132 and Tegra210 code is not touched by this patch to make it
easier to review and validate. A follow-up patch will bring those SoCs
in line with the model.
BRANCH=None
BUG=None
TEST=Booted Oak with a single mmu_init()/mmu_enable(). Built Ryu and
Smaug.
Change-Id: I28302a6ace47e8ab7a736e089f64922cef1a2f93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12077
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The existing MCT support code did not perform any of the requisite
configuration to support registered or x4 DIMMs. Add the needed
configuration per the BKDG for Family 15h.
Change-Id: I9ee0bb7346aa35f564fe535cdd337ec7f6148f2b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12019
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Sufficient support has been added to allow booting with registered
DIMMs on the KGPE-D16 in certain slots. ECC support needs additional
work; the ECC data lanes appear to cause boot failures in some slots.
Change-Id: Ieaf4cbf351908e5a89760be49a6667dc55dbc575
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12017
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Load microcode to APs when performing baytrail_init_cpus. The updated
fsp1_0 driver calls TempRamInit API with a dummy microcode, so FSP
will not handle the microcode load.
Change-Id: I7b7c0f43da0d149048ae5a8fd547828f42de04fd
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/12095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Load microcode to BSP in bootblock so later on the FSP TempRamInit call
can be success. The updated fsp1_0 driver calls TempRamInit API with a
dummy microcode, so FSP will not handle the microcode load. If BSP is
not loaded a microcode before calling TempRamInit API, the call will
fail with the error No Valid Microcode Was Found.
Change-Id: I1fbe68e14e5a24d8f2da70603cd2f03675b9ca81
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/11896
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Pass in dummy microcode when calling FSP TempRamInit API. FSP will not
do the microcode load and leave the work to coreboot.
Ensure that BSP has been loaded a microcode before calling TempRamInit
API, otherwise FSP will return error that No Valid Microcode Was Found.
Change has been verified on fsp_baytrail and will be applied to rangeley.
Change-Id: I8247c0503c8eb3d1c8eaa059632fb3a11c9daae9
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/11895
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Load microcode to APs when performing model_406dx_init. The updated
fsp1_0 driver calls TempRamInit API with a dummy microcode, so FSP
will not handle the microcode load.
Change-Id: Ib75f860a34c84bf13c0c6c31ebed13e5787f365e
Signed-off-by: David Guckian <david.guckian@intel.com>
Reviewed-on: http://review.coreboot.org/12436
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Load microcode to BSP in bootblock so later on the FSP TempRamInit call
will return with success. The updated fsp1_0 driver calls TempRamInit
API with dummy microcode, so FSP will not handle the microcode load. If
BSP is not loaded with microcode before calling TempRamInit API, the
call will fail with error No Valid Microcode Was Found.
Change-Id: I9c55acaf3353a759bb0119f0a5402a704ffb2c4a
Signed-off-by: David Guckian <david.guckian@intel.com>
Reviewed-on: http://review.coreboot.org/12367
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: York Yang <york.yang@intel.com>
The current code did not define the number of DIMM slots on the
mainboard, which lead to incorrect configuration values and
occassional training failure.
Add preliminary support for DIMM slot count configuration.
Change-Id: I488511d6262ffa8207c442d133314aed0f75acfb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12016
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On some multi-socket AMD platforms there are too many cores for all
APs to start up without stack collisions with either each other or
the BSP. On such platforms a larger amount of CAR memory is also
available.
Allow the maximum DCACHE size to be increased via a mainboard-
specific Kconfig flag.
Change-Id: I72ae8f7abeb9a83b57505469922818f9ec5bdf3f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12015
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
CAR space on certain platforms is nearly full. This prevents the
addition of necessary RAM initialization features such as x4 DIMM
support. As the DIMM SPD cache uses a sizeable amount of CAR RAM,
reducing it would free up a significant amount of CAR RAM.
DDR3-based AMD platforms only support up to 3 physical DIMMs on
each channel (6 per node). Reduce the maximum number of DIMMs
on a node from 8 to 6 accordingly.
Change-Id: I38def86da76fc622785318c825670209b2ac9017
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12107
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On the ASUS KGPE-D16 it was noted that the pin straps did not properly
configure the lane director hardware, causing link training failure
on NIC B. Forcing coreboot to always reconfigure the lane director
on startup resolves this problem.
Change-Id: I5b78cef84960e0f42cc3e0406a7031d12d21f3ad
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12014
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In the course of adding full Family 15h MCT support some Family
15h specific settings were inadvertently applied to Family 10h
processors.
Only apply Family15h specific settings to Family 15h processors.
Change-Id: I5dcb333d3a5a49318fe7bddd4c386642205c343e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12013
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When both DCTs of a node are in use the DRAM clocks should be skewed
with respect to one another in order to reduce cross-channel interference.
Set the clock skew bit according to the BKDG recommendations.
Change-Id: Ibcce54fc53b79beba2f790994bcf87cc0354213a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12011
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing code did not set Rtt timing parameters when registered
DIMMs were used with Family 15h processors. Set the Rtt values
according to the BKDG recommendations.
Change-Id: I80cd7f8aec12951611d802f33e5e167a41dd532e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12010
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
AMD Opteron processors contain a very fragile phy phase detection circuit.
Additionally, the algorithm given in the BKDG does not function as intended;
this was verified both on real hardware via execution trace and on paper
with values read back from multiple CPUs and DIMMs.
As a result, the phy training algorithm given in the BKDG has been
replaced with a phy training algorithm developed at Raptor Engineering.
This particular patch is the first part of that algorithm; the code
is updated in future patches but this should exist in the historical
record in case something breaks down in the later sections of code.
Change-Id: Ic7a19d24954f47c922126e3da7be1f7e85f7396f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12007
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
AMD's automatic phy phase detection hardware is very fragile and often
produces incorrect results. Attempt to recover from obvious phase
locking errors by retrying phy training on the failing link.
Change-Id: Ia2c3022534c9ad44714eef6e118869f054bd9f6b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12006
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing MCT code did not properly set up the On Die Termination
(ODT) or timing values for registered DIMMs. Use the BKDG recommended
values when registered DIMMs are installed.
Change-Id: Ia9ee770d9f9c22e18c12e38b5bb4a7bae0a99062
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12005
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There were numerous issues surrounding AMD ECC initialization on
Family 15h processors due to the incomplete derivation from Family
10h MCT code. Bring the Family 15h ECC initialization and supporting
setup code in line with the BKDG recommendations.
Change-Id: I7f009b655f8500aeb22981f7020f1db74cdd6925
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12003
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing ECC initialization algorithm contained several bugs on both
Family 10h and Family 15h processors, including activation of ECC scrub
before DRAM setup was completed, in violation of both BKDG and errata
recommendations.
Change-Id: I09a8ea83024186b7ece7d78a4bef1201ab34ff8a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12002
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
It's not deprecated if it's still in active use. The code layout is just
"funny" (and could warrant a chipset-side cleanup, but not today)
Change-Id: I5f7776ceba0134f20364a0c4a1ca51382e9877e2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12429
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Since there are no longer any newisys mainboards, remove the directory
and Kconfig files. This removes the Kconfig warning:
mainboard/newisys/Kconfig:3:warning: config symbol defined without type
Change-Id: Icb2e782173166a26fa261f6cfb81b665a846931e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12423
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When using FMAP regions (with option -r) that were generated with a
master header (as done by cbfstool copy, eg. in Chrome OS' build
system), there were differences in interpretation of the master header's
fields.
Normalize for that by not sanity-checking the master header's size field
(there are enough other tests) and by dealing with region offsets
properly.
BUG=chromium:445938
BRANCH=tot
TEST=`cbfstool /build/veyron_minnie/firmware/image.dev.bin print -r
FW_MAIN_A` shows that region's directory (instead of claiming that
there's no CBFS at all, or showing an empty directory).
Change-Id: Ia840c823739d4ca144a7f861573d6d1b4113d799
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e5364d291f45e4705e83c0331e128e35ab226d3
Original-Change-Id: Ie28edbf55ec56b7c78160000290ef3c57fda0f0e
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/312210
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12416
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
ZhengShunQian