| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Id404bdab1f2361f1e7d20f7ee72111971863dddf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17736
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ic22beaa47476d8c600e4081fc5ad7bc171e0f903
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17735
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: If6b36ebef49dd2733d272f990bb7c6623d4ab1b1
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16785
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Idef587d8261784e916e8d50f4336cbcfca39b9b0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16730
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Replace the use of the old device_t definition inside
mainboard/asus/*.
Change-Id: I5ddfba2102854adcc9bbfd75f7acbe76f0152b72
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16438
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Since commit 3bfd7cc (drivers/pc80: Rework normal / fallback selector
code) the reboot counter stored in `reboot_bits` isn't reset on a reboot
with `boot_option = 1` any more. Hence, with SKIP_MAX_REBOOT_CNT_CLEAR
enabled, later stages (e.g. payload, OS) have to clear the counter too,
when they want to switch to normal boot. So change the bits to (h)ex
instead of (r)eserved.
To clarify their meaning, rename `reboot_bits` to `reboot_counter`. Also
remove all occurences of the obsolete `last_boot` bit that have sneaked
in again since 24391321 (mainboard: Remove last_boot NVRAM option).
Change-Id: Ib3fc38115ce951b75374e0d1347798b23db7243c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/16157
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Ia1f24d328a065a54975adde067df36c5751bff2d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15987
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I7930d5cded290f2605d0c92a9c465a3f0c1291a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15974
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The last_boot NVRAM option was deprecated and removed in
commit 3bfd7cc6. Remove the last_boot option from all
affected mainboards to eliminate user confusion.
Change-Id: I7e201b9cf21dfe5dda156785bad078524098626d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12316
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
|
|
On server boards with a recovery jumper, having the fallback path
less sensitive to power fluctuations or BMC issues makes sense.
Increase the maximum number of boot attempts before automatic
fallback to 10 on these boards.
Change-Id: Iabe0b0cbf332686db8e9380a8b65a1477173599c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12320
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Several ramstage files were inadvertently using Family 10h-specfic
structures, causing unstable operation. Use the K8-specific
structures instead.
Change-Id: I64066dfdca83557393499b77726051e25b814381
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12290
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The existing KFSN4-DRE support hung during ramstage while initializing
AP #3 if a second CPU package was installed. After analyzing the
Sun Ultra 40 M2 support code it became apparent that the K8 code
cannot function correctly if sequential RAM training is disabled,
and that there were a few other missing calls. This patch adds
the missing calls, adjust the CAR space to an appropriate level, and
explicitly defines the link numbers and connections in devicetree.cb
TEST: Booted ASUS KFSN4-DRE with 2x Opteron 8222 installed.
Change-Id: I96178b7367b0c13de5c9d5d90d032fb0c53639c2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12285
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This is a clone of the original Family 10h-compatible ASUS
KFSN4-DRE board, modified for basic K8 support to allow for
future K8 Socket F Opteron testing.
TEST: Booted KFSN4-DRE with 1 Opteron 8222 processor
KNOWN ISSUES:
* Second CPU package fails to initialize AP
This prevents use of a secondary CPU package
* Second memory channel of at least CPU package #0
does not function (crash at CAR handoff)
Change-Id: I591725babe685fa50a0d7473b17005fbd258056e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12212
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
