We define AGESA_LEGACY as an implementation of mainboard
that has its romstage main completely under mainboard/
directory. We have learnt from other platforms this approach
has several downsides when it comes to making platform-wide
improvements.
We start by creating per-family romstage.c file, which
boards will gradually take into use by removing the
AGESA_LEGACY Kconfig option we here apply to all of them.
BUG=none
BRANCH=none
TEST=none
Change-Id: I3ff98b2ee71ee55883efe83372494d2181785388
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 967d94d626
Original-Change-Id: Id01931e185a023039a60af16a678de9966db8d65
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18619
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/462938
This is a cosmetic change.
BUG=none
BRANCH=none
TEST=none
Change-Id: I4536ce41bad5c02a10d008b52df66819b0910bd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 50db9c99be
Original-Change-Id: Iea4dd97e9d83594447427abd9f844e507b805192
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18960
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/462935
Some Chrome OS boards previously didn't have a hardcoded vboot
configuration (e.g. STARTS_IN_BOOTBLOCK/_ROMSTAGE, SEPARATE_VERSTAGE,
etc.) selected from their SoC and mainboard Kconfig files, and instead
relied on the Chrome OS build system to pass in those options
separately. Since there is usually only one "best" vboot configuration
for a certain board and there is often board or SoC code specifically
written with that configuration in mind (e.g. memlayout), these options
should not be adjustable in menuconfig and instead always get selected
by board and SoC Makefiles (as opposed to some external build system).
(Removing MAINBOARD_HAS_CHROMEOS from Urara because vboot support for
Pistachio/MIPS was never finished. Trying to enable even post-romstage
vboot leads to weird compiler errors that I don't want to track down
now. Let's stop pretending this board has working Chrome OS support
because it never did.)
Change-Id: Ie50b79b1bb1acd10ed64332eaa763f0a6cb9ea17
Original-Change-Id: Ibddf413568630f2e5d6e286b9eca6378d7170104
Original-Reviewed-on: https://review.coreboot.org/19022
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: 1210b41283
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462007
Currently the `break` further down is called unconditionally as the
brackets for the body of the if statement are missing. Add those.
BUG=none
BRANCH=none
TEST=none
Change-Id: I738178ea9f4f92fad237cfec23acad6af17995dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b45bbb253f
Original-Change-Id: I34917a9877dcc882d880dedea689e1d72fe52888
Original-Found-by: Coverity (CID 1372941: Control flow issues (UNREACHABLE))
Original-Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-on: https://review.coreboot.org/18971
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459504
Replace the use of the old device_t definition inside
northbridge/via/vx900.
BUG=none
BRANCH=none
TEST=none
Change-Id: Iaf6a189371992a2f6d391802c1bb714d29baf8ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 823f7bb962
Original-Change-Id: I04292a6b698a42a5c582eddcef7cf5a235e1a464
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/17317
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459659
It makes no sense to read SPDs if the system will reset anyway.
BUG=none
BRANCH=none
TEST=none
Change-Id: Icc0587de64d04063c9203535a773ec1967604b23
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bb5e77c478
Original-Change-Id: Id2ad9b04860b3e4939a149eef6b619a496179ff8
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/17661
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/458348
This reuses some of gm45 code to set up the panel.
Panel start and stop delays and pwm frequency can now be set in
devicetree.
Linux does not make the difference between 945gm and gm45
for panel delays, so it is safe to assume the semantics of those
registers are the same.
The core display clock is computed according to "Mobile Intel 945
Express Chipset Family" Datasheet.
This selects Legacy backlight mode since most targets have some smm
code that rely on this.
This sets the same backlight frequency as vendor bios on Thinkpad X60
and T60.
A default of 180Hz is selected for the PWM frequency if it is not
defined in the devicetree, this might be annoying for displays that
are LED backlit, but is a safe value for CCFL backlit displays.
BUG=none
BRANCH=none
TEST=none
Change-Id: I86445ab53cb83bc5183fb998ca03e00b4746a33f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e079000dc
Original-Change-Id: I1c47b68eecc19624ee534598c22da183bc89425d
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18141
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/457362
Decode DDR2 SPD similar to DDR3 SPD decoder to ease
readability, reduce code complexity and reduce size of
maintainable code.
Rename dimm_is_registered to spd_dimm_is_registered_ddr3 to avoid
compilation errors.
BUG=none
BRANCH=none
TEST=none
Change-Id: I2580a164627a0348da02aad6dbbe5311c442fe35
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6e53ae6f5c
Original-Change-Id: I741f0e61ab23e3999ae9e31f57228ba034c2509e
Original-Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Original-Reviewed-on: https://review.coreboot.org/18273
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/452895
A problem around CAR teardown time may result with missing
training results at the time we want to save them.
Record this in the logs for debugging purposes, it will
not be possible to use S3 suspend if this happens.
BUG=none
BRANCH=none
TEST=none
Change-Id: I1be67747db636b92ddc7c38d2d851ce81b7b359d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 86690eb0a1
Original-Change-Id: Id2ba8facbd5d90fe3ed9c6900628309c226c2454
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18534
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-on: https://chromium-review.googlesource.com/452464
No board with binaryPI currently supports HAVE_ACPI_RESUME. For
platforms with PSP the approach is also very different from what
we previously had here.
Furthermore, s3_resume.[ch] files under cpu/amd/pi do not
distinguish between NonVolatile and Volatile buffers of S3 storage.
This means the Volatile buffer that is maintained and available in
CBMEM is unnecessarily copied to SPI flash. This has been fixed on
open-source AGESA directory, so development of S3 suspend support
with binaryPI is better continued with that.
Unfortunately there are further complications and indications that
open-source AGESA may have always had a low-memory corruption
issue. This has to be investigated separately before restoring
or claiming S3 is supported on binaryPI.
BUG=none
BRANCH=none
TEST=none
Change-Id: Iaa3b5135ab114cd1e0dcd540ed8df3adee235dcf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 97a4b3edf0
Original-Change-Id: I81585fff7aae7bcdd55e5e95bc373e0adef43ef0
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18501
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-on: https://chromium-review.googlesource.com/451433
The file is used for fam15.
BUG=none
BRANCH=none
TEST=none
Change-Id: I52a113c24020e70ae237a97661ced1310c6f6185
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3444a9d716
Original-Change-Id: I7cdf238a8f7be4bf79546bcfc3c9d05bd8986e3e
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18635
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-on: https://chromium-review.googlesource.com/451431
Definitions are not part of ACPI S3 feature, nor do
they require any AGESA headers so move them to a
better location.
BUG=none
BRANCH=none
TEST=none
Change-Id: Icb4e2a24f724cf12b9891e9a73a5683972155994
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: da74041b2b
Original-Change-Id: I9269e9d65463463d9b8280936cf90ef76711ed4f
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18616
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-on: https://chromium-review.googlesource.com/451430
One very long line has to be wrapped to be shorter than 80 characters to
satisfy the lint scripts.
Note, that this gets rid of the brackets ().
BUG=none
BRANCH=none
TEST=none
Change-Id: I096cf6151a68e30a9b438d4b5526d72f0faacd94
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3329262eca
Original-Change-Id: Ie98eff360ebc5b68ce496edc15eb2d9fddcac868
Original-Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Original-Reviewed-on: https://review.coreboot.org/18556
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-by: Philippe Mathieu-Daud <philippe.mathieu.daude@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/451358
These definitions do not require AGESA.h include,
and we will eventually remove agesawrapper.h files.
BUG=none
BRANCH=none
TEST=none
Change-Id: If0e0310f276c5d72fac69f959a935f0d4ac7aa76
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d610c5823c
Original-Change-Id: I1b5b78409828aaf2616e177bb54a054960c3869f
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18588
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/451271
As we drive both channels with the same speed,
chan0dll and chan1dll are the same.
BUG=none
BRANCH=none
TEST=none
Change-Id: I64c2fe3d14c3f174448863ac37ac8ba21f09a369
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 44a3066015
Original-Change-Id: I7253ea9ea66396c536c82d63c67fecb041681707
Original-Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Original-Reviewed-on: https://review.coreboot.org/18472
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/450238
AGESA AmdInitEarly() reconfigures the lapic timer in a way that
conflicts with lapic/apic_timer.
This results in an endless loop when printk() is called after
AmdInitEarly() and before the apic_timer is initialized.
This patch forces a reconfiguration of the timer after
AmdInitEarly() is called.
Codepath of the endless loop:
printk()->
(...)->
uart_tx_byte->
uart8250_mem_tx_byte->
udelay()->
start = lapic_read(LAPIC_TMCCT);
do {
value = lapic_read(LAPIC_TMCCT);
} while ((start - value) < ticks);
[lapic_read returns the same value after AmdInitEarly()]
BUG=none
BRANCH=none
TEST=none
Change-Id: I32003d5fc62bcd2a54a91dc536d0e43315642c28
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b2bb6ad2a7
Original-Change-Id: I1a08789c89401b2bf6d11846ad7c376bfc68801b
Original-Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/17924
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/450237
This reverts commit fec8872c9d.
The commit introduced a regression which is causing MC4 failures
when 8 RDIMMs are populated in a configuration with a single CPU
package. Using just 4 RDIMMs, the failure does not occur.
After reverting the commit, I tested configurations with
1 CPU (8x8=64GB) and 2 CPU packages (16x8=128GB) using an
Opteron 6276. The MC4 failures did not occur anymore.
BUG=none
BRANCH=none
TEST=none
Change-Id: I0a508bff03899c8b7bd7429bce653a7bea94bef0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 610d1c67b2
Original-Change-Id: Ic6c9de84c38f772919597950ba540a3b5de68a65
Original-Signed-off-by: Daniel Kulesz <daniel.ina1@googlemail.com>
Original-Reviewed-on: https://review.coreboot.org/18369
Original-Tested-by: build bot (Jenkins)
Original-Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Original-Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://chromium-review.googlesource.com/449827
This fixes a warning that the new toolchain generates.
BUG=none
BRANCH=none
TEST=none
Change-Id: I110558801c33c2d82d56b8fd0a65b10f0e161605
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 37e30aa624
Original-Change-Id: Idf46026729a474323e74a5cf7a156bf5bc8cf026
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/18485
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446840
This fixes warnings that the new toolchain generates.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ie91f31785d2f3a78b96147b4f5a41e16b8d1142f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a6b1b258d2
Original-Change-Id: I83d2c4c4651a89b443121312a5f36adfc1e4bc48
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/18308
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446389
This is more consistent with newer Intel targets.
BUG=none
BRANCH=none
TEST=none
Change-Id: If00a2a24cb0d9f85913fb60ef87048a2feac844c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b29e0b70f8
Original-Change-Id: I52ee8d3f0c330a03bd6c18eed08e578dd6ae284b
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18371
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/445832
Adds the necessary plumbing for acpi_device_path() to find the LPC
bridge on the AMD Family14 northbridge with an SB800 southbridge.
This is necessary for TPM support since the acpi path to the LPC bridge
(_SB.PCI0.ISAB) doesn't match the built-in default in tpm.c
(_SB.PCI0.LPCB).
BUG=none
BRANCH=none
TEST=none
Change-Id: I707dcace91005120df4361e8bad749b2f165a308
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d8a2c1fb17
Original-Change-Id: I1ba5865d3531d8a4f41399802d58aacdf95fc604
Original-Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Original-Reviewed-on: https://review.coreboot.org/18402
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/446379
Add a test in case we have a DIMM2 not populated but DIMM3 is.
BUG=none
BRANCH=none
TEST=none
Change-Id: I80508fd652795593aef7e202891b494d60d4d6a9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75da1fb2ba
Original-Change-Id: I14f82afe03884740570838e7b2771233356c518d
Original-Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Original-Reviewed-on: https://review.coreboot.org/18386
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/445150
It rewrites the results of receive enable stored in the upper nvram
region, to avoid running receive enable again.
Some debug info is also printed about the self-refresh registers.
(Not enforcing a reset here, since 0 does not necessarily mean it's
not in self-refresh).
BUG=none
BRANCH=none
TEST=none
Change-Id: Ie8a85069cc613706c1405e150bece11bc6ba43c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ef7e98a2ac
Original-Change-Id: Ib54bc5c7b0fed6d975ffc31f037b5179d9e5600b
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/17998
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445144
Previously the raminit failed on hot reset and to work around this
issue it unconditionally did a cold reset.
This has the following issues:
* it's slow;
* when the OS issues a hot reset some disk drives expect their 5V
power supply to remain on, which gets cut off by a cold reset,
causing data corruption.
To fix this some steps in raminit must be ommited on the reset path.
This includes receive enable calibration.
To achieve this it stores receive enable results in RTC nvram for them
to be rewritten on the resume path.
Note: The same thing needs to be done on the S3 resume path.
Calling a hot reset after raminit "outb(0x6, 0cf9)" works.
BUG=none
BRANCH=none
TEST=none
Change-Id: I7abad55524ecea8bbd828aba6dd3ce7708f1a7bd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 97e13d84c3
Original-Change-Id: I6601dd90aebd071a0de7cec070487b0f9845bc30
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18009
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/445143
Those are the result from tracing what linux or the option rom do
but are not needed here.
TESTED on Thinkpad X60.
BUG=none
BRANCH=none
TEST=none
Change-Id: I4aa3ebf50bc772ff0baf0b6c685022ea40750234
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Id: d81078d944
Original-Change-Id: I4297a78c4ab6a19ef6161778c993fc3f3fb08c7e
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18294
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/443675
Void pointer arithmetics are forbidden in standard C but GCC has
an extension that allows it.
BUG=none
BRANCH=none
TEST=none
Change-Id: Id10d81e0663007c10a9a139cc437dd94be654212
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85cfddb4b4
Original-Change-Id: I43029b2ab2f7709b8e1ba85eb05c31341b8ac16f
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18293
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/441809
It's an attempt to consolidate the access code, even if there are still
multiple implementations in the code.
BUG=none
BRANCH=none
TEST=none
Change-Id: Icccf8c3113c0491ffc31d1ff04177b2116df8b17
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e3c59e258
Original-Change-Id: I4b2b9cbc24a445f8fa4e0148f52fd15950535240
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18265
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441807
Since it checks for DDR3 style checksums, it's a more appropriate name.
Also make its configuration local for a future code move.
BUG=none
BRANCH=none
TEST=none
Change-Id: I863c33342228fa73b60c31fd86d493774de1a6fd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2e08b59cdc
Original-Change-Id: I417ae165579618d9215b8ca5f0500ff9a61af42f
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18264
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/441806
The selection of the SSC reference frequency for LVDS was based on a
completely unrelated clock.
The `ssc_freq` flag should be set when the SSC reference runs at a
different frequency than the general display reference clock (DREF).
For most platforms, there is no choice, i.e. for i945 and gm45 the SSC
reference always differs from the display reference clock (i945: 66Mhz
SSC vs. 48MHz DREF; gm45: 100MHz SSC vs. 96Mhz DREF), for Nehalem and
newer, it's the same frequency for SSC/non-SSC (120MHz). The only,
currently supported platform with a choice seems to be Pineview, where
the alternative is 100MHz vs. the default 96MHz.
BUG=none
BRANCH=none
TEST=none
Change-Id: I869be7519523453cd776fdc8c4cdc4dc0db03ad2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 561bebfbaa
Original-Change-Id: I7791754bd366c9fe6832c32eccef4657ba5f309b
Original-Signed-off-by: Nico Huber <nico.huber@secunet.com>
Original-Reviewed-on: https://review.coreboot.org/18186
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/438055
Ubuntus default compiler flags for GCC [1][2] include `-Wformat
-Wformat-security`, causing errors similar like the one below.
```
CC romstage/northbridge/amd/amdht/ht_wrapper.o
src/northbridge/amd/amdht/ht_wrapper.c: In function 'AMD_CB_EventNotify':
src/northbridge/amd/amdht/ht_wrapper.c:124:4: error: format not a string literal and no format arguments [-Werror=format-security]
printk(log_level, event_class_string_decodes[evtClass]);
^
[]
```
Fix that, by explicitly using a format string.
TEST=Built and booted on ASUS KGPE-D16.
[1] https://stackoverflow.com/questions/17260409/fprintf-error-format-not-a-string-literal-and-no-format-arguments-werror-for
"fprintf, error: format not a string literal and no format arguments [-Werror=format-security"
[2] I tested with gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609.
Change-Id: Iff829bf83e1ead8537fbe5d7c5c6376bdd77f323
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f6776fa62c
Original-Change-Id: Iabe60deeffa441146eab31dac4416846ce95c32a
Original-Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Original-Reviewed-on: https://review.coreboot.org/18208
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/433880
The results were obtained by comparing the MCHBAR registers of vendor bios
with coreboot at the same dram timings.
This fixes 2 issues:
* 1333MHz fsb CPUs were limited to 667MHz ddr2 speeds, because with
800MHz raminit failed;
* 1067MHz fsb CPUs did not boot when second dimm slot was populated.
TESTED on ga-g41m-es2l on 800, 1067 and 1333MHz CPUs with
DDR2 667 and 800MHz dimms.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ia83222824b338692fbcfe67318da1ca7173f46a7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Id: eee4f6b224
Original-Change-Id: I70f554f97b44947c2c78713b4d73a47c06d7ba60
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18022
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/431292
Commit-Ready: Duncan Laurie <dlaurie@google.com>
Tested-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The orphaned Tab_TrefT_k causes a failure to build due to
an unused variable warning on GCC 6. Remove this variable.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ib66ec10a6babbc59814ed51d244af2ef75306b96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 17b66c3846
Original-Change-Id: Ida680a6a3bc2b135755dd582da8c6edb8956b6ff
Original-Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Original-Reviewed-on: https://review.coreboot.org/18094
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Original-Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/428253
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Logic inside mct_EnableDimmEccEn_D uses an unintialized variable as
a register address under certain conditions. Refactor mct_EnableDimmEccEn_D
to use the explicit address of the register in all cases.
BUG=none
BRANCH=none
TEST=none
Change-Id: If0a31097c60af1fa050b6794ed5d631a7aa4c0d7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 590a3e1f6c
Original-Found-by: Coverity Scan #1347337
Original-Change-Id: I6bc50d0524ea255aa97c7071ec4813f6a3e9c2b8
Original-Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Original-Reviewed-on: https://review.coreboot.org/18079
Original-Tested-by: build bot (Jenkins)
Original-Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/428249
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
