Age | Commit message (Collapse) | Author |
|
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 ().
Change-Id: Ie98eff360ebc5b68ce496edc15eb2d9fddcac868
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/18556
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
|
|
These definitions do not require AGESA.h include,
and we will eventually remove agesawrapper.h files.
Change-Id: I1b5b78409828aaf2616e177bb54a054960c3869f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/18588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
As we drive both channels with the same speed,
chan0dll and chan1dll are the same.
Change-Id: I7253ea9ea66396c536c82d63c67fecb041681707
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/18472
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins)
|
|
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()]
Change-Id: I1a08789c89401b2bf6d11846ad7c376bfc68801b
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/17924
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This reverts commit fec8872c9dee4411ba1a89fc8ec833a700b476c6.
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.
Change-Id: Ic6c9de84c38f772919597950ba540a3b5de68a65
Signed-off-by: Daniel Kulesz <daniel.ina1@googlemail.com>
Reviewed-on: https://review.coreboot.org/18369
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
|
|
Change-Id: I304467353bb9989f0d7e0ad7d1b632081f66b1af
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/18482
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
This fixes a warning that the new toolchain generates.
Change-Id: Idf46026729a474323e74a5cf7a156bf5bc8cf026
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/18485
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This fixes warnings that the new toolchain generates.
Change-Id: I83d2c4c4651a89b443121312a5f36adfc1e4bc48
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/18308
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix up the whitespace issues introduced in commit 39bfc6cb
(nb/i945/raminit.c: Fix dll timings on 945GC).
Change-Id: I3a4152866226401bc51c7fb1752aab541a4c72b0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/18465
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
This is more consistent with newer Intel targets.
Change-Id: I52ee8d3f0c330a03bd6c18eed08e578dd6ae284b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18371
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Remove unused definitions, prototypes and macros moslty copied from gm45.
Change-Id: I076e204885baec3d40f165785cf4ae4adc9154c5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18370
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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).
Change-Id: I1ba5865d3531d8a4f41399802d58aacdf95fc604
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: https://review.coreboot.org/18402
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Values based on vendor bios.
TESTED on ga-945gcm-s2l with 667MHz ddr2.
Change-Id: I2160f0ac73776b20e2cc1ff5bf77ebe98d2c2672
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/17197
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins)
|
|
Add a test in case we have a DIMM2 not populated but DIMM3 is.
Change-Id: I14f82afe03884740570838e7b2771233356c518d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/18386
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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).
Change-Id: Ib54bc5c7b0fed6d975ffc31f037b5179d9e5600b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17998
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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.
Change-Id: I6601dd90aebd071a0de7cec070487b0f9845bc30
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18009
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Those are the result from tracing what linux or the option rom do
but are not needed here.
TESTED on Thinkpad X60.
Change-Id: I4297a78c4ab6a19ef6161778c993fc3f3fb08c7e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18294
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Void pointer arithmetics are forbidden in standard C but GCC has
an extension that allows it.
Change-Id: I43029b2ab2f7709b8e1ba85eb05c31341b8ac16f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18293
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
It's an attempt to consolidate the access code, even if there are still
multiple implementations in the code.
Change-Id: I4b2b9cbc24a445f8fa4e0148f52fd15950535240
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18265
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Since it checks for DDR3 style checksums, it's a more appropriate name.
Also make its configuration local for a future code move.
Change-Id: I417ae165579618d9215b8ca5f0500ff9a61af42f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18264
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This also selects RELOCATABLE_RAMSTAGE and
CACHE_RELOCATABLE_RAMSTAGE_OUTSIDE_CBMEM by default on Haswell.
Change-Id: I50b9ee8bbfb3611fccfd1cfde58c6c9f46b189ca
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18232
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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.
Change-Id: I7791754bd366c9fe6832c32eccef4657ba5f309b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18186
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Hide the IGD to make sure ramstage doesn't detect it.
Change-Id: If389016f3bb0c4c2fd0b826914997a87a9137201
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/18194
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Ubuntu’s 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: Iabe60deeffa441146eab31dac4416846ce95c32a
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/18208
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ia7fa2c290e540ff779cf8dc16147db5a248021e2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18142
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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.
Change-Id: I70f554f97b44947c2c78713b4d73a47c06d7ba60
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18022
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ie1c360ac29eb30af6f4b5447add467f3c13ba211
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18180
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
max_cdd_we_delta should be signed to allow for negative CDD.
Found-by: Coverity Scan #1347355
Change-Id: Iaccd1021680296d169c26c25e339f83fbd7cc065
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18162
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The values of highest_rank_count were undefined on DDR2 systems.
Explcitly define these values on DDR2 platforms.
Found-by: Coverity Scan #1347338
Change-Id: Iad7bb00db97b2816fcc44fb5941bd14373451da2
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18078
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The orphaned Tab_TrefT_k causes a failure to build due to
an unused variable warning on GCC 6. Remove this variable.
Change-Id: Ida680a6a3bc2b135755dd582da8c6edb8956b6ff
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18094
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
An unintended sign extension warning was thrown by Coverity.
Explicitly state the length of the constant multiplier.
Found-by: Coverity Scan #1347342
Change-Id: Icd42eec13be04fc5fd2ffc85320cbadafc852148
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18077
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
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.
Found-by: Coverity Scan #1347337
Change-Id: I6bc50d0524ea255aa97c7071ec4813f6a3e9c2b8
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18079
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ib86600b687c7002646ca82d5fa52121b6eafcd60
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18087
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Malloced resources were not freed in failure branches during
S3 parameter save. Clean up Coverity warnings by freeing
resources in failure branches.
Found-by: Coverity Scan #1347344
Change-Id: I5f119874e52ef2090ca1579db170a49a2a6a0a2a
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18074
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The existing DRAM clock speed to configuration value logic contained
an error resulting in a theoretical out of bounds read. While this
would not be hit on real hardware, it was prudent to clean up the
logic to avoid the associated Coverity warning.
Found-by: Coverity Scan #1347353
Change-Id: Ic3de3074f51d52be112a2d6f2d68e35dc881dd2e
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18073
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The existing code inadvertently calculated the maximum read
latency for nonexistent channel 2 instead of for channels
0 and 1 as intended. Fix the calls to the maximum read latency
training function.
Found-by: Coverity Scan #1347354
Change-Id: If34b204ac73cd20859102cc3b2f40bc99c2ce471
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18072
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
The critical delay delta was incorrectly specified as an
unsigned short. Use a signed short instead.
Found-by: Coverity Scan #1347355
Change-Id: I37d769afb8c8af85a0375ae459e9d4ab0adcca74
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18071
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
The existing logic to set up CsMux45 used an incorrect mask
and comparison value due to a copy + paste editing error.
Use the correct mask and comparison value for the last two
values.
Found-by: Coverity Scan #1347385
Change-Id: Ic08a52977df90b9952e434e71cd12dbc6d7e1443
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18070
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The existing code waiting for northbridge P-state transitions
contained a logical error preventing correct operation. Fix
the logical error and force coreboot to wait for the P-state
transitions per the BKDG.
Found-by: Coverity Scan #1347388
Change-Id: I35f498c836db1439734abe684354c18c8e160368
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18069
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
The code to set the igd frequencies is written with the mobile version
of the 945 chipset in mind and seems to cause cause strange igd
related problems on the desktop versions.
Some possible problems are:
* on 800MHz fsb CPUs the igd sometimes has artifacts on the screen;
* on 800MHz fsb CPU memtest results vary a lot;
* since a commit 45e11aa0a5 "Add/Combine Broadwell Chromebooks using
variant board scheme" that does not affect this northbridge, the
display shows garbage as soon as Linux (4.8) modesets the display.
A fix is to hardcode the core display and render clocks to their
maximum, potentially also improving graphical performance.
Vendor bios on all boards in coreboot with this northbridge have the
same value in this PCI config address.
TESTED on P5GC-MX (display works fine again in Linux) and
user reports of it making GA-945GCM-S2L run more stable.
Change-Id: I8b046edbc952631d9b79023e3d385160ff682c24
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17981
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
On AMD DDR3 platforms, the upper DQMask was incorrectly
calculated, leading to undefined behaviour and possible
DRAM training faults. Use the correct calculation for
the upper DQMask.
Found-by: Coverity Scan #1347394 #1347393
Change-Id: If3190eb7c30f1f00d6fd8b751bc1761c9d119782
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18068
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Several members of DCTStatStruc are designed to persist across resets of
all other members. Move the persistent members into a substructure in
order to simplify the reset logic and avoid compiler warnings / UB.
Change-Id: I1139b7b3b167d33d99619338d42fcd26e2581a5d
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/18058
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Some PCI peripherals, such as FPGA accelerators, require a great amount
of memory mapped IO. This patch allows the user to select at build time
the bottom IO to leave enough space for such devices.
We cannot calculate this value at runtime because it has to be set
before the PCI devices are enumerated.
Change-Id: Ic590e8aa8b91ff89877cbff6afd10614d33dcf8d
Credit-to: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/17980
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Nothing from that header is used or even declared since
CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT is not selected on Intel
hardware.
Change-Id: I9101eb6ffa6664a2ab45bc0b247279c916266537
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18044
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
|
|
This is more consistent with newer Intel targets.
This a static struct so it is initialized to 0 by default.
To make it more readable:
* only setting to GPIO mode is made explicit;
* only pins in GPIO mode are either set to input or output since this
is ignored in native mode;
* only output pins are set high or low, since this is read-only on
input;
* blink is only operational on output pins, non-blink is not set
explicitly;
* invert is only operational on input pins, non-invert is not set
explicitly.
Change-Id: I05f9c52dee78b7120b225982c040e3dcc8ee3e4e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17639
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Previously, all romstages for this northbridge family
would compile via 1 single C file with everything
included into the romstage.c file (!)
This patch separates the build into separate .o modules
and links them accordingly.
Currently compiles and links all fam10 roms without
breaking other roms.
Both DDR2 and DDR3 have been completed
TESTED on REACTS: passes all boot tests for 2 boards
ASUS KGPE-D16
ASUS KFSN4-DRE
Some extra changes were required to make it compile
otherwise there were unused functions in included "c" files.
This is because I needed to exchange CIMX
for the native southbridge routines. See in particular:
advansus/a785e-i
asus/m5a88-v
avalue/eax-785e
A followup patch may be required to fix the above boards.
See FIXME, XXX tags
Change-Id: Id0f9849578fd0f8b1eab83aed910902c27354426
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/17625
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
|
|
Values based on vendor bios and suggested by Arthur Heymans for FSB1067.
FSB1067:
The ratio 1067/800 is proportional to the ratio of EPBAR32(0x2c) bits:
0x1a / 0x14 ~ 1067/800
EPVC1IST:
The ratio is also proportional to FSB ratios: 0x9c / 0xf0 ~ 533/800.
Change-Id: Ib90e8ea1b82f2fcc3b5c199cace32a7f0aff4b5c
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/17198
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I55e2d99b3f9929703f34d268f4490f3c5c2c766f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17915
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Required fix to have rules.h as default include.
Change-Id: I6ce2d4e13de5139a84c709b5836ecd41c0abc836
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17747
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Having same memory region set as both WRPROT and WRBACK
using MTRRs is undefined behaviour. This could happen if
we allow DCACHE_RAM_BASE to be located within CBFS in SPI
flash memory and XIP romstage is at the same location.
As SPI master by default decodes all of top 16MiB below
4GiB, initial cache-as-ram line fills may have actually
read from SPI flash even in the case DCACHE_RAM_BASE was
below the nominal 4GiB - ROM_SIZE.
There are no reasons to have this as board-specific setting.
Change-Id: I2cce80731ede2e7f78197d9b0c77c7e9957a81b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17806
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Currently only there is only one eaglelake board in coreboot
(ga-g41m-es2l) featuring a G41 variant northbridge.
Adding boards with a different variant (Q43, Q45, G43, G45, B43) will
require this change for graphic initialisation.
Change-Id: Ida32c563a99576b66685dfdadf9a534fd6e197dc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17900
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Add custom files for Sandybridge and IvyBridge functions.
Move only the minimal required functions into separate files.
Both files' functions are going to call raminit_common functions.
No functionality is changed.
Sandybridge code path tested on Lenovo T420.
Change-Id: I1b1dfbd0857b59d3ae4392b73c033ee7a5aed243
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17605
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This is a follow-on patch to commit 10141c30 -
(nb/intel/gm45: Use LAPIC udelay instead of custom version)
which removed the custom udelay from everywhere except SMM.
This patch removes it from SMM as well, and gets rid of the
gm45/delay.c file.
Change-Id: I7970bb5205f4aa10b38172ab5b9f8bcd6766c4e7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17330
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Instead of hardcoding pci_mmio_size in the raminit code,
this makes it a parameter in the devicetree.
A safe minimum of 768M is also defined since using anything
less causes problems (if 4G of ram is used).
Change-Id: If004c861464162d5dbbc61836a3a205d1619dfd5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16856
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Except fo nehalem, K8, f10 and f15 (non-AGESA) romstage ramstack
is placed in CBMEM and ramstage loader takes care of tiny backup.
Change-Id: I8477944f48ed2493d0a5e436a4088eb9fc3d59c5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17358
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Don't use scratchpad registers when we have romstage_handoff
to pass S3 resume flag. Also fixes console log from reporting
early in ramstage "Normal boot" while on S3 resume path.
Change-Id: I2f1f05ef4fc640face3d9dc92d12cfe4ba852566
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17676
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I2085fc3a17d32cfbdab9ec0b7afbc01031e75b47
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17785
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Don't use scratchpad registers when we have romstage_handoff
to pass S3 resume flag. Scratchpad register was read too
late in ramstage so acpi_is_wakeup_s3() did not evaluate
correctly.
This fixes low memory corruption at 0x1000-0x102c and the lack
of coreboot tables (util/cbmem not working) after S3 resume.
This also fixes console log from reporting early in ramstage
"Normal boot" while on "S3 resume" path.
Change-Id: I2922a15a90d2f8272c3482579bdd96f8f33e9705
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17675
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Don't use scratchpad registers when we have romstage_handoff
to pass S3 resume flag. Also fixes console log from reporting
early in ramstage "Normal boot" while on S3 resume path.
Change-Id: I4e2eabc59ff87b7ed40cfc9885bbe0256fe4a695
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17674
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Adapt implementation from skylake to prepare for removal of
HIGH_MEMORY_SAVE and moving on to RELOCATABLE_RAMSTAGE.
With this change, CBMEM region is set early-on as WRBACK
with MTRRs and romstage ram stack is moved to CBMEM.
Change-Id: Idee5072fd499aa3815b0d78f54308c273e756fd1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15791
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Force modest 4 MiB alignment to help with MTRR assignment.
Change-Id: I49a7d1288bc079da1b8bd52150ddcfcfe2e51179
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17780
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Adapt implementation from skylake.
Change-Id: Ica3134a2261d3e84c714264cf75557322f9ef5db
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17673
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
We have kconfig.h auto-included and it pulls config.h too.
Change-Id: I665a0a168b0d4d3b8f3a27203827b542769988da
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17655
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This makes CHIPSEC happy. We don't enable PAVP, but it shouldn't hurt
to lock it nevertheless.
Change-Id: I9428f0b6e8868832eb79f7aea24cbc7961c2aa8f
Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Reviewed-on: https://review.coreboot.org/17352
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Device is of type CPU_CLUSTER, while pci_dev_set_resources()
expects PCI_DOMAIN.
Change-Id: Ib1add47d71071abb6e9c28e3a85dd0b671741b71
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17697
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Resource is actually stored even before read_resources, but
that's where we currently log this resource.
For Intel, use PCI config register offset as the resource
index, while AMD side uses MSR address.
Change-Id: I6eeef1883c5d1ee5bbcebd1731c0e356af3fd781
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17696
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Id727270bff9e0288747d178c00f3d747fe223b0f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17695
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Also remove separate MMCONF_SUPPORT_DEFAULT flag.
Change-Id: Idf1accdb93843a8fe2ee9c09fb984968652476e0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17694
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Resource allocator and 64-bit PCI BARs will need it and
PCI use is not really restricted to x86.
Change-Id: Ie97f0f73380118f43ec6271aed5617d62a4f5532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17733
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
I liked the style of code in pci_mmio_cfg.h more, and used those to
replace the ones in io.h.
Change-Id: Ib5e6a451866c95d1edb9060c7f94070830b90e92
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17689
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The code originates from times before __SIMPLE_DEVICE__ was
introduced. To keep behaviour unchanged, use explicit PCI
IO operations here.
Change-Id: I44851633115f9aee4c308fd3711571a4b14c5f2f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17720
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
Change-Id: I943e354af0403e61263f1c780f02c7b463b3fe11
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17529
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It gets selected from CPU_AMD_MODEL10XXX.
Change-Id: Iffab43edc1152b07ba2af6273d4b5eb94afe33ba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17692
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Untested.
Change-Id: I61ab1e5279c995f933971332673aa4ca0150e80c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17544
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Boards with this chipset do not have any reference of
MMCONF_BASE_ADDRESS being written to chipset registers.
Either board support is already broken or FSP takes
care of this early and Kconfig lacks the notice that
this parameter must match with the chosen FSP binary.
CPU bootblock associated with this chipset uses
exclusive PCI IO access already.
Untested.
Change-Id: I07d20d81266ff6aaa6384d20a806d52fd4568e08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17547
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Split raminit.c into smaller parts. Move all functions that will
be used by chip-specific code into raminit_common.c.
The chip-specific changes includes new configuration values
for IvyBridge and 100Mhz reference clock support, including new
frequencies.
No functionality is changed.
Tested on Lenovo T420.
Change-Id: If7bb5949f4b771430f3dba1b754ad241a7e8426b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ie1c28b73bd2d34070173838d341cc6b8f65f50ef
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/17686
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I9b952e32dc661f5c1fa96b037b415693d8777b04
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17685
Tested-by: build bot (Jenkins)
Reviewed-by: Damien Zammit <damien@zamaudio.com>
|
|
The same pattern was being used throughout the code base
for initializing the romstage handoff structure. Provide
a helper function to initialize the structure with the S3
resume state then utilize it at all the existing call sites.
Change-Id: I1e9d588ab6b9ace67757387dbb5963ae31ceb252
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17646
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: Id6ec25706b52441259e7dc1582f9a4ce8b154083
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17534
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Vendorcode always does PCI MMCONF access once it is
enabled via MSR.
In coreboot proper, we don't give opportunity to make
pci_read/write calls before PCI MMCONF is enabled via MSR.
This happens early in romstage amd_initmmio() for all cores.
Change-Id: If31bc0a67b480bcc1d955632f413f5cdeec51a54
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Following commit did not move this selection to northbridge:
bac0fad Remove explicit select MMCONF_SUPPORT
Change-Id: I5f3c429dfd160eb439f396db2baf0ecf280022fd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17653
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I4288193c022cc0963b926b4b43834c222e41bb0d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16953
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Building an image for the Lenovo X60 on Debian 8.5 (jessie) with GCC 4.9.2,
compilation fails with the error below.
```
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
[…]
$ make # lenovo/x60 with native graphics initialization
[…]
CC ramstage/northbridge/intel/i945/gma.o
src/northbridge/intel/i945/gma.c: In function 'probe_edid':
src/northbridge/intel/i945/gma.c:570:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < 8; i++) {
^
src/northbridge/intel/i945/gma.c:570:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
Makefile:316: recipe for target 'build/ramstage/northbridge/intel/i945/gma.o' failed
make: *** [build/ramstage/northbridge/intel/i945/gma.o] Error 1
```
Fix this by declaring the count variable outside the 'for' loop.
Change-Id: Icf69337ee46c86bafc4e1320fd99f8f8f5155bfe
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/17623
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The code won't allow anything beyond CL11 due to short
CAS Latency mask and a bug in mr0 which had the wrong
bit set for CL > 11.
Increase the CAS bitmask, fix the mr0 reg to allow CAS Latencies
from CL 5 to CL 18.
Use defines instead of hardcoding min and max CAS latencies.
Tested on X220 with two 1866 MHz, CL13 memories
Tested-By: Nicola Corna <nicola@corna.info>
Change-Id: I576ee20a923fd63d360a6a8e86c675dd069d53d6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17502
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
This allows to set the backlight PWM frequency and the
duty cycle in the devicetree instead of using a plain BLC_PWM_CTL
value.
Change-Id: I4d9a555ac7ea5605712c1fcda994a6fcabf9acf3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17597
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Fix-up for 696abfc
nb/intel/x4x: Fix and deflate `dimm_config` in raminit
It didn't fix the channel-number shifting issue as intended.
The channel index is either 0 or 1. DIMMs are counted from 0
to 3 where 0..1 covers channel 0, and 2..3 covers channel 1.
Since we have two DIMMs per channel, we have to multiply the
channel index by 2 (or shift it left by 1) to get the index
of the first DIMM in the channel. Finally, to get the offset
of a DIMM in the channel we take its index modulo 2 (again,
the number of DIMMs per channel).
Change-Id: I2784b0cb655bfe823bf5fa48b722623dfca1ddc3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17612
Tested-by: build bot (Jenkins)
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
We kept this value at it's default on the native graphics init path.
Maybe the Video BIOS path, too, I don't know if the VBIOS sets it.
The panel power sequencer uses the core display clock (CDCLK). It's
based on the HPLLVCO and a frequency selection we made during raminit.
The value written is the (actual divisor/2)-1 for a 100us timer.
v2: Fix unaligned mmio access inherited from Linux.
v3: Use MCHBAR8() instead. Also, the unaligned access might have
worked after all.
Change-Id: I877d229865981fb0f96c864bc79e404f6743fd05
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17619
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Some methods like discover_402x assume an clear state.
Should fix fallback attempt raminit failures.
Change-Id: I7a6fe044c17f5e0dbfa0e9b9d2aed0c3b6ae3972
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17471
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
By shifting the `chan` right instead of left, values were always taken
from the DIMMs of the first channel. The diff-stat also looks like an
improvement.
Change-Id: I605eb4f9b04520c51eea9995a2d4a1f050f02ecc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17587
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Damien Zammit <damien@zamaudio.com>
|
|
If smbus_read_byte returned an error when reading the DIMM size,
this value would be used as an offset into an array.
Check for the error, and set the DIMM size to 0 if there's
a problem.
Addresses coverity issue 1229658 - Negative array index read
Signed-off-by: Martin Roth <martinroth@google.com>
Change-Id: I6461a0fae819dd9261adbb411c4bba07520d076d
Reviewed-on: https://review.coreboot.org/17485
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I1ceea759a40d740503bde725ad6d72fab4aa7971
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/17006
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
RW flag was added to spi_slave structure to get around a requirement on
some AMD flash controllers that need to group together all spi volatile
operations (write/erase). This rw flag is not a property or attribute of
the SPI slave or controller. Thus, instead of saving it in spi_slave
structure, clean up the SPI flash driver interface. This allows
chipsets/mainboards (that require volatile operations to be grouped) to
indicate beginning and end of such grouped operations.
New user APIs are added to allow users to perform probe, read, write,
erase, volatile group begin and end operations. Callbacks defined in
spi_flash structure are expected to be used only by the SPI flash
driver. Any chipset that requires grouping of volatile operations can
select the newly added Kconfig option SPI_FLASH_HAS_VOLATILE_GROUP and
define callbacks for chipset_volatile_group_{begin,end}.
spi_claim_bus/spi_release_bus calls have been removed from the SPI flash
chip drivers which end up calling do_spi_flash_cmd since it already has
required calls for claiming and releasing SPI bus before performing a
read/write operation.
BUG=None
BRANCH=None
TEST=Compiles successfully.
Change-Id: Idfc052e82ec15b6c9fa874cee7a61bd06e923fbf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17462
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Time spent in printk() is highly unpredictable, depending of the
enabled consoles. If only CBMEM console is enabled, debugstring
is repeated tens of times, consuming preram_cbmem_console storage.
Change-Id: I2b0d9bd11c294d988a0eb84b90e77d5cc7f1f848
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17516
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Make MMCONF_SUPPORT selected with MMCONF_SUPPORT_DEFAULT.
Platforms that remain to have explicit MMCONF_SUPPORT are
ones that should be converted.
Change-Id: Iba8824f46842607fb1508aa7d057f8cbf1cd6397
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17527
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Note: Platforms have no MMCONF_SUPPORT_DEFAULT.
Change-Id: I8a02ea78957fca23b1cf161a00d5e3edda73d683
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17543
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I4a8297397d878e38516c8df19dd311c7ef19ec06
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17478
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
When MRC cache is available, first read only the SPD unique
identifier bytes required to detect possible DIMM replacement.
As this is 11 vs 256 bytes with slow SMBus operations, we save
about 70ms for every installed DIMM on normal boot path.
In the DIMM replacement case this adds some 10ms per installed DIMM
as some SPD gets read twice, but we are on slow RAM training boot path
anyways.
Change-Id: I294a56e7b7562c3dea322c644b21a15abb033870
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17491
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
For S3 resume path SPD is only used for DIMM replacement detection.
As this detection already fails in the case of removal/insertion of
same DIMM, we can rely on cbmem_recovery() failure alone to force
system reset in case someone accidentally does DIMM replacements while
system is suspend-to-ram stage.
Skipping DIMM replacement detection allows skipping slow SPD loading,
thus reducing S3 resume path time by 80ms for every installed DIMM.
Change-Id: I4f2838c05f172d3cb351b027c9b8dd6543ab5944
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17490
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|