| Age | Commit message (Collapse) | Author |
|---|
|
In case we are going to use this in future designs.
BUG=none
TEST=none
BRANCH=none
Change-Id: I750addf10e4fe6f8240f8c8262253f8af7027e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55844
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3515
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
src/lib/cbmem.c is for the static cbmem.
Thanks to adurbin for the Makefile.inc pointer and code on #coreboot IRC channel on freenode:
<adurbin> no. if you have CONFIG_DYNAMIC_CBMEM then cbmem.c shouldn't be compiled
[...]
<adurbin> +ifeq ($(CONFIG_EARLY_CBMEM_INIT),y)
<adurbin> +ifneq ($(CONFIG_DYNAMIC_CBMEM),y) romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c
<adurbin> +endif
<adurbin> +endif
Without that fix we have:
src/lib/cbmem.c:58:43: error: no previous prototype for 'get_cbmem_toc' [-Werror=missing-prototypes]
src/lib/cbmem.c:76:6: error: no previous prototype for 'cbmem_init' [-Werror=missing-prototypes]
src/lib/cbmem.c:107:5: error: no previous prototype for 'cbmem_reinit' [-Werror=missing-prototypes]
This commit was tested on qemu-i440fx with the following commit:
qemu-i440fx: Make it compile with CONFIG_DYNAMIC_CBMEM
( http://review.coreboot.org/#/c/3504/ ).
Change-Id: I98636aad4bb4b954f3ed3957df67c77f3615964a
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3503
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: Ib6f7cfac5acf3f8170508547d1584af90273e8c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3471
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
Change-Id: I2e3fd58404c48e863a3a1b255337fb397086651b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3506
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I74de250c69a57109362be1b2f00c0b4aa24a64e8
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3473
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Location is hard-coded right now, which isn't optimal.
It must be chip erase block aligned, which might fail on some flash chips
(it's 64k aligned which should work for most cases).
Change-Id: I6fe0607948c5fab04b9ed565a93e00b96bf44986
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3497
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Collect early timestamps in T60's romstage like some newer boards do.
This should also work on X60s (and other ICH7 based systems with
EARLY_CBMEM_INIT).
Change-Id: I3b2872dd7423f3379ff3b68ad999523ec35fc08e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3499
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Upgrade the ICH7 bootblock to store an initial timestamp like we do it
since Sandy Brigde. I've checked the datasheets for the used scratchpad
registers and grepped for their usage. I'm pretty sure that they aren't
used on any ICH7 based board (for anything before the usual S3-resume
indication).
Change-Id: I28a9b90d3e6f6401a8114ecd240554a5dddc0eb5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Ditch unused fb*.h files.
Rename init.c (name is _way_ to generic) to bochs.c.
Add proper bochs dispi interface detection and mode setup.
Hook up coreboot framebuffer table initialization.
Change-Id: I7154b1593902e7d42606b64819217872eee10683
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3500
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
src/lib/edid.c:1177: error: ‘y’ may be used uninitialized in this function
Warning is bogus, but seems my gcc (4.4.7 as shipped by RHEL-6)
isn't clever enougth to figure this on its own. So help a bit
by explicitly initializing the variable.
Change-Id: Ia9f966c9c0a6bd92a9f41f1a4a3c8e49f258be37
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3501
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The SPI logical device on the W83627DHG uses the second i/o port
register pair but not the first one. So we have to also set `io1`
(the second io_info struct) and not `io0` in the pnp_info structure.
Setting the PNP_IO1 flag without a mask in `io1` caused coreboot to
hang in pnp_enable_devices() until commit aeead274 which added a
check for an unset mask.
Change-Id: I027d279b4641fecd88afb14d40fbe1c0bfbf81bb
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3391
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: I8371764e3f2d16a3a776beb1c064f461b20a4262
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3496
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I was unable to find documentation that said what mode numbers correspond
to what functionality, so I translated over what U-Boot does.
Change-Id: I34fab0f024fa2322d6bb66106aed75224e67354d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3489
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
All 3 boards with AGESA_HUDSON had HAVE_HARD_RESET with the reset.c
file already placed under southbridge/.
All 15 boards with CIMX_SBx00 had HAVE_HARD_RESET with functionally
identical reset.c file under mainboard/. Move those files under
respective southbridge/.
Change-Id: Icfda51527ee62e578067a7fc9dcf60bc9860b269
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3486
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Confusingly, romstage compiled in different copy of soft_reset()
than ramstage. Use source in reset.c for both.
Change-Id: I2e4b6d1b89c859c7cf5d9e9c8f7748b43d369775
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3487
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The chip component is unconditionally selected for the mainboard
so these uses are superfluous.
Change-Id: I84b053ab47f7b1f68e88d968cf305e24bc95f4da
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3485
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
CONFIG_HUDSON_XHCI_ENABLE will control the XHCI flags in the
amd/parmer and asus/f2a85-m mainboards. The XHCI ports on
amd/thatcher are not wired to USB jacks so always disable the flags.
This was tested on amd/parmer using a USB 3.0 thumbdrive.
Change-Id: I596b040fec30882d8d4dee34ab9f866dc1f8896b
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3465
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To have USB 3.0 support the XHCI controller needs to be enabled
and the xhci.bin firmware needs to be added to CBFS.
Change-Id: I0b641b30b67163b7dc73ee7ae67efe678e11c000
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3464
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
After removing the enter()/exit() functions for configuration mode,
most wrappers for our standard PnP functions just call the underlying
default implementation.
Remove those with a little cocci:
@ op_match @
identifier op;
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
type device_t;
identifier dev;
@@
static void op(device_t dev) { pnp_op(dev); }
@@
identifier op_match.op;
@@
-op(...) {...}
/* Three rules to match the alignment, hmmp... */
@@
identifier op_match.op, op_match.pnp_op;
identifier ops;
@@
struct device_operations ops = {
- .set_resources = op,
+ .set_resources = pnp_op,
};
@@
identifier op_match.op, op_match.pnp_op;
identifier ops;
@@
struct device_operations ops = {
- .enable_resources = op,
+ .enable_resources = pnp_op,
};
@@
identifier op_match.op, op_match.pnp_op;
identifier ops;
@@
struct device_operations ops = {
- .enable = op,
+ .enable = pnp_op,
};
Change-Id: Idc0e52c7e3600a01f3b6a4e17763557b271b481e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3483
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Find all the (ramstage) implementations of enter()/exit() functions
for the configuration state, register and call them through the new
struct pnp_mode_ops. As our standard PnP functions are aware of the
pnp_mode_ops, it's not necessary to call enter()/exit() around them
anymore.
Patch generated with the cocci below. It's not perfect. The movement
of the enter()/exit() calls is somehow fragile. So I checked the
remaining calls for sense, and changed some empty lines. Also a
duplicate insertion of pnp_conf_mode_ops had to be removed.
/* Try to find enter and exit functions by their outb() structure and
their usage around calls to our standard pnp functions: */
@ enter_match @
identifier enter;
identifier dev;
type device_t;
@@
void enter(device_t dev)
{
<...
outb(..., dev->path.pnp.port);
...>
}
@ exit_match @
identifier exit;
identifier dev;
type device_t;
@@
void exit(device_t dev)
{
<...
outb(..., dev->path.pnp.port);
...>
}
@ pnp_match @
identifier op;
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
identifier enter_match.enter, exit_match.exit;
type device_t;
identifier dev;
@@
void op(device_t dev)
{
...
enter(dev);
...
pnp_op(dev);
...
exit(dev);
...
}
/* Now add enter/exit to a pnp_mode_ops structure: */
@ depends on pnp_match @
identifier enter_match.enter;
identifier exit_match.exit;
identifier ops;
@@
+static const struct pnp_mode_ops pnp_conf_mode_ops = {
+ .enter_conf_mode = enter,
+ .exit_conf_mode = exit,
+};
+
struct device_operations ops = {
...,
+ .ops_pnp_mode = &pnp_conf_mode_ops,
};
/* Match against the new structure as we change the code and the above
matches might not work anymore: */
@ mode_match @
identifier enter, exit, ops;
@@
struct pnp_mode_ops ops = {
.enter_conf_mode = enter,
.exit_conf_mode = exit,
};
/* Replace enter()/enter() calls with new standard calls (e.g.
pnp_enter_conf_mode()): */
@@
identifier mode_match.enter;
expression e;
@@
-enter(e)
+pnp_enter_conf_mode(e)
@@
identifier mode_match.exit;
expression e;
@@
-exit(e)
+pnp_exit_conf_mode(e)
/* If there are calls to standard PnP functions, (re)move the
enter()/exit() calls around them: */
@@
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
expression e;
@@
-pnp_enter_conf_mode(e);
pnp_op(e);
+pnp_enter_conf_mode(e);
...
pnp_exit_conf_mode(e);
@@
identifier pnp_op =~ "^pnp_((alt_|)enable|(set|enable)_resources)$";
expression e;
@@
pnp_enter_conf_mode(e);
...
+pnp_exit_conf_mode(e);
pnp_op(e);
-pnp_exit_conf_mode(e);
@@
expression e;
@@
-pnp_enter_conf_mode(e);
-pnp_exit_conf_mode(e);
Change-Id: I5c04b0c6a8f01a30bc25fe195797c02e75b6c276
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3482
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Many super i/o chips only answer to PnP requests if they are in a
configuration state (sometimes also called ext func mode). To cope with
that, the code of many chips implements its own version of our default
PnP functions like pnp_set_resource(), pnp_enable_resource() etc.
To avoid this code duplication, this patch extends our PnP device
interface with optional functions to enter and exit configuration mode.
Change-Id: I9b7662a0db70ede93276764fa15020f251eb46bd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3481
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current default implementation of pnp_enable() only disables devices
- if set so in the devicetree - but does not enable them. Enablement takes
place in pnp_enable_resources(). Yet, many PnP chips implement their own
version of pnp_enable() which also enables devices if set in the devicetree.
It's arguable, if enabling those devices makes sense, before they get
resources assigned. Maybe we can't write the resource registers if not,
who knows? The least we can do is providing a common implementation for
this behavior, and get rid of some code duplication.
Used the following cocci:
@@
expression e;
@@
+pnp_alt_enable(e);
-pnp_set_logical_device(e);
(
-pnp_set_enable(e, !!e->enabled);
|
-(e->enabled) ? pnp_set_enable(e, 1) : pnp_set_enable(e, 0);
|
-if (e->enabled) { pnp_set_enable(e, 1); }
-else { pnp_set_enable(e, 0); }
)
Change-Id: I8d695e8fcd3cf8b847b1aa99326b51a554700bc4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3480
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
They were hard-coded to be copied from 3rdparty/ which isn't always
the right choice.
Since the defaults stay the same, this should be compatible.
Change-Id: If2173bef86ad1fcf2335e13472ea8ca41eb41f3d
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3453
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Most PnP drivers align the initialization of their `device_operations`
with spaces. Unify this, so next autogenerated patches always match the
alignment.
Change-Id: I3f6baef6c8bb294c136354754125ea88c07a61a1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3479
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I0d499027ffb175638cba0a9830d6ec2041a139db
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3488
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add support for the new q35 chipset emulation
added in qemu 1.4.
Change-Id: Iabfaa1310dc7b54c9d224635addebdfafe1fbfaf
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3430
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ic83f55d01b29b43028e3b363749d64b927db5489
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3492
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
So the pci allocation code knows where memory is and doesn't
try map pci devices there. We also don't have to check for
overlaps between pci hole and memory then.
Change-Id: I5eaea0e4d21210719685860fa1f16ca7b2137cde
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3491
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
memory reference
An uninitialized RAM value was used to select an MSR because a $ was forgotten
in front of `CPU_DM_CONFIG0`. It should be the constant value 0x1800, corresponding
to CPU_DM_CONFIG0 MSR defined in `src/include/cpu/amd/lxdef.h`.
Change-Id: Id53ca98b06cc4a9b55916fd8db23904f98008d45
Signed-off-by: Christopher Kilgour <techie@whiterocker.com>
Reviewed-on: http://review.coreboot.org/3478
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
The original lines had contradicting comment and code.
This change follows the code and sets MASTER bit too.
Change-Id: Id2886bfc107612530f0e9747e5d49a9740fb8532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3466
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Prepare tree for adding q35 support:
Move emulation/qemu-x86 to emulation/qemu-i440fx.
Rename some stuff to include 'i440fx'.
Change-Id: Ib8c58175c5734cfcda1b22404ef52c09d38f0462
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3429
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
With this patch, output on usbdebug also includes the section of
MTRR setups for every CPU. This makes usbdebug output almost identical
with that of serial port and CBMEM console.
Tested with model_206ax. Also tested previously on model_f2x which does
not have these disable/enable calls in model_f2x_init() without detected issues.
Change-Id: Idfd0e93439907b17255633658195d698feab3895
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3423
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
IDs were leftovers from bd82x6x.
Change-Id: I4ab6062929d346d7f000ce8c0b8c97490bb2b154
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3463
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
This patch provides the correct SD controller timings for
the Family16 device. It also will remove the SD controller
from PCI space when device 0:14.7 is set to off in devicetree.
This was tested on a AMD Parmer board and a AMD G-series SOC
reference board. The settings were found in the AMD
Hudson2 RRG and family16 BKGD.
Change-Id: I6d7e7997ddc39802ab75dc8a211ed29f028c0471
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3348
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In function OemAgesaSaveMtrr of 'src/cpu/amd/agesa/s3_resume.c',
there are many code like this:
msr_data = rdmsr(0x258);
flash->write(flash, nvram_pos, 4, &msr_data.lo);
nvram_pos += 4;
flash->write(flash, nvram_pos, 4, &msr_data.hi);
nvram_pos += 4;
Add a function write_mtrr to do this.
Change-Id: Id6464e637db1758b07ac2d79d3be1375a8d49651
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3410
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This issue can be reproduced in Linux by the following steps:
1) use pm-suspend to suspend.
2) use USB keyboard to wake up.
3) use pm-suspend to suspend. FAIL To SUSPEND.
The cause of this issue is:
USB devices use bit 11(0x0b) of GP0_STS represents S3 wake up event,
but this bit is not clear after wake up. So OS thinks there is a
wake up signal and wake up immediately.
In this patch, I add AcpiGpe0Blk using MMIO access and write 1
on bit 11. Write 1 to clear as spec says.
I have tested on Thatcher
The same change was done for AMD Parmer in commit »AMD Parmer:
fix issue 'S3 fails to suspend after wake up from USB keyboard'
(03901124) [1].
[1] http://review.coreboot.org/#/c/3347/
(Change-Id: Iec3078bf29de99683e7cd3ef4e178fbeb4dc09c1)
Change-Id: Iaef39237497ef896d0f186e8f5522222c0ce6cb7
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3374
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I21182eae1d389790c330f27e6a830d91c3ee4eb6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3433
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I7ecc394b1e5bc0b8b85a8afac22efc0befe2d36a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3395
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit 0210119b4b95e84f954cfd6dc11aafbc187421af
Change-Id: I5be3f2a54394c592650a0dcd671e4a72ae796cb2
Reviewed-on: http://review.coreboot.org/3443
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: If56f2cacc5f1b2ef9c7b6aea508d458a43dd1309
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3397
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Until ME boots (which takes seconds on X201) the reported temperature
is 128 °C which triggers Linux overheat alarm which shuts down.
Pretend temperature is 40°C until ME boots.
Change-Id: Ia49fa03c6eb27f539a23711f2c8ebfde72b1dc18
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3404
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On X201 to enable EHCI debug you need to go through EC if USB power is
disabled so we need to inclue ec.c.
Change-Id: I8f8b7de639ecaebceaa53cd338136befaeec8214
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3405
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Enable UMTS on Lenovo X60 and X201.
Enable radios if no options are available.
Enable dock on Lenovo X201.
Based on my X201 branch.
Change-Id: I6e8d3bbd6a6b1a8e59473dd5cc8125a1583d75df
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a struct for referencing UART registers. The layout is quite
strange on this chip, as the entire register space can take on three
different meanings depending on the line control settings (in the LCR
register) And to make things more confusing, some offsets reference
different registers depending on if a read or a write operation is
used.
Change-Id: Ie62af9c0e0edafd01b81686a0fe5c5c1d4fa06c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This ancient board with Intel e7505 invalidates cache while it does HW
scrubbing for ECC in romstage. This breaks usbdebug console and prevents
system from booting.
If both EARLY_CONSOLE and USBDEBUG are selected, skip ECC scrubbing under
these rare conditions to boot system.
Change-Id: I6cb43bf69af54119f4a582dcaf498dd941d4c62d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3385
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In case with EARLY_CONSOLE, this printk is called before any other
console is configured to transmit data. This outputs garbage on
CONSOLE_SERIAL as baudrate is not yet programmed.
For case without EARLY_CONSOLE, the order in which different console
drivers initialize is obscure. Might sometimes work properly.
Change-Id: I3792161e0a6dc17e17262048cc9136044dd69dc5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3384
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Add comment how one can debug the usbdebug hardware init.
Do not send printk's to usbdebug console when one is debugging
the usbdebug console initialisation itself.
Change-Id: I21a285cb31cf64e853bc626f8b6a617bc5a8be19
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3382
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Setting IRQ delivery to FSB got lost in the rebase process
for commit e6143531.
I captured following error on dmesg and this patch fixes it for
i82801dx.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 2) ...
....... failed.
...trying to set up timer as Virtual Wire IRQ...
..... works.
Change-Id: I0768976cc6b0deab213ad9bd4771e0f278de634c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3371
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Mapping is as follows: bit 15 corresponds to GPIO15 ... bit 0 corresponds to
GPIO0.
Change-Id: I661ce56d9373887270ba3c0518892fbbe6d9de7c
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/3436
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Currently in Intel BD82x6x southbridge’s `Makefile.inc` the
file `usb_debug.c` is added twice to the build.
This was introduced in
commit 4063ede3fb571110c3e65c321049cc2687cc54fa
Author: Ronald G. Minnich <rminnich@google.com>
Date: Mon Feb 4 20:31:51 2013 -0800
bd82x6x: Fix compiling with USB debug port support
Reviewed-on: http://review.coreboot.org/2784
but was unneeded because it had been already added in
the following commit.
commit 4141993536039e0d45caeacb745a89d388f0724b
Author: Sven Schnelle <svens@stackframe.org>
Date: Sat Jul 28 08:52:44 2012 +0200
bd82x6x: Fix CONFIG_USBDEBUG
Reviewed-on: http://review.coreboot.org/1376
Therefore basically revert that hunk.
There is no policy on how to order these additions, so leave
it to a possible separate commit, unifying this.
Kyösti Mälkki suspects that these additions were meant for
the Intel Lynx Point [1].
[1] http://review.coreboot.org/#/c/3424/
Change-Id: Iaa8de6fcc0d6f3a0a92a28fcb603d7777aa8b24c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3425
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fix obvious mistake in cycle that displays GPI status
I hope i found all duplicates of it.
Change-Id: Ic21ff3ecab85953463e5c23daf808dd5edc82ff8
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/3435
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current method will treat hex values as 0 and would calculate the wrong
size. This change switches back to an earlier method which used shell syntax
to add the offset and size.
Change-Id: I9fb2d9b323f113cc56a5ad2e38b47d2d22084f08
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3432
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is loosely based on Christoph Grenz' ACPI code for the W83627HF
and makes use of the PnP super i/o ACPI framework.
Change-Id: I5e1cd09b83c0041f440562d2a1b73e4560589cb7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3288
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
I'm trying to make writing ACPI code for super i/o devices more
comfortable.
pnp.asl hosts some general cpp macros.
The other four files are to be included in dsdt trees. They are
controlled by cpp macros which should be defined/undefined before
inclusion.
Work was inspired by Christoph Grenz' ACPI code for the W83627HF.
Change-Id: Idb55332ba9bc788c98964d30a450e0d734cf28ec
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3286
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The bootblock and ROM stages are the only ones that are really required to be
loaded in the quite limited on chip RAM during startup. Rather than load the
whole image which requires everything to be small, load just the bootblock and
the ROM stage, allowing the rest of the image to be arbitrarily large. Loading
a minimal amount of stuff should also improve boot performance a little bit.
Change-Id: I2fede63b8d3d8f0d880e4a692ae423021f8232b6
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3421
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Now that the ROM size is decoupled from the size of the on chip RAM,
it's size is now only constrained by the size of the medium it's loaded
from and the memory it's being loaded into, probably GBs in both cases.
Making it 4MB is a reasonable compromise between giving the payload lots
of breathing room and wasting space on the source medium which won't be
used.
Change-Id: I80932e0d4ce2dad02c3879345382e7d6ba44503a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3422
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Until we get serial working, this is a good way to show that coreboot is
running. It can be removed once we have better methods.
Change-Id: I62d25e52aa88a97aba4c959538d680b67a0bbbb2
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I2dd693b300085493baa65bb652df8d6cce80b63b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3431
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
EPIA-M850 can now boot linux. For a list of issues, see:
http://www.coreboot.org/VIA_EPIA-M850
That's all folks.
Change-Id: I7624944dbc05fbf3019897a116954d71dfda0031
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1228
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is the minimal code needed to get past ramstage, load SeaBIOS, jump
to GRUB2, and boot linux (or load memtest). See individual source files for
the status of each individual component.
Change-Id: Ib7d5d7593c945f18af2c2fc5e0ae689ba66131a2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3419
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The VX900 can be connected to either DDR2 or DDR3. On my board, it is
DDR3, hence why there is no and will be no DDR2 code from my side.
This is the raminit for DDR3 dimms for the VX900. I like the term
"raminit" better than "memory training". This is a device, not a dog.
What works and what doesn't is documented in the code. It does not
make sense to hide that information in a commit message.
Change-Id: Ib2ebc10e6d4d22d0a937fe9e895c17ce79153c88
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3417
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In some cases, we want a ram_check that does not die and does not
clobber the terminal with useless output that slows us down a lot.
Usage examples include Checking if the RAM is up at the start of
raminit, or checking if each rank is accessible as it is being
initialized.
As with all other ram_checks, this is more of a "Is my DRAM properly
configured?" test, which is exactly what we want for something to use
during memory initialization.
Change-Id: I95d8d9a2ce1e29c74ef97b90aba0773f88ae832c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3416
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add support for VX900 early initialization up until, but not including
raminit. Add the basic infrastructure, add a romstrap table, and
functionality to configure the CPU bus and SMBus.
This code is necessary and sufficient to prepare us for raminit.
Change-Id: Icc9c41e4927b589f17416836f87a6a5843b24aa7
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3372
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a common implementation of SMBus functionality for early chipsets. Note
however, that existing via chipsets are not ported to this code. Porting
will require hardware testing to make sure everything is fine.
This code is used in the VIA VX900 branch.
Change-Id: If5ad8cd0942ac02d358a0139967e7d85d395660f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/144
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Loading on an OMAP SOC requires that the first sector of the image have a
configuration header, and, when not an execute in place image, an additional
header which describes how big the image is and where it should be loaded.
This change adds some infrastructure to statically build that header using C
code, and to paste the header onto the front of coreboot.rom in a new top
level target file called MLO.
The configuration header we're using is as inert as possible, in line with
what U-Boot is doing. I think it could be used to give additional
configuration parameters to the built-in ROM on the SOC, but we don't need to
do that, and there didn't seem to be any actual documentation how to do that.
Because the header is built from C and is defined per CPU, it would be
possible to include extra settings in other CPUs if desired.
Adding a new top level build target is a bit disruptive, but should be
contained to the am335x directory and not interfere with other mainboards.
Change-Id: I06d346a4050c20963b3c7c6e8a152070bf2d145a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On ARM, there's frequently some firmware built into the SOC which runs
first and which loads other firmware like Coreboot from some other
media. To prevent the bootblock from having to know how to find and load
the ROM stage from what may be a complicated source (sd card,
netbooting, etc.), we can put the ROM stage immediately after the
bootblock and ensure that they're both loaded at the same time.
This change adjusts the Makefile.inc for ARM so that the ROM stage is put
into the image before any other files so that we know it comes first.
This changes the behavior of the CONFIG_UPDATE_IMAGE config option used
by abuild, although it's not entirely clear whether that's still used.
Change-Id: I832386243788156db5f5abbc9760a4e2026cf2cd
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3420
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
Keep in mind that we can _NOT_ read back the current state
of the LEDS as some crazy FPGA designer wanted it that way.
Change-Id: I5cd1ac598072318b3234d1ec35a79271655b46ac
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3271
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
fam15 vendorcode (src/vendorcode/amd/agesa/f15tn) was licensed under the
AMD software license agreement. Change this license to 3-clause BSD.
Change-Id: I7cab09bb58ef7cd24602628e2278672d577214a2
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
If EARLY_CONSOLE is not selected, the PCI function for EHCI
host controller must be configured in ramstage instead.
Change-Id: I20f7569f79484c744bc413450bfa139052f3580f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3383
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Without that commit, with CONFIG_PCI_OPTION_ROM_RUN_YABEL,
The VGA option rom doesn't init the right display:
it initializes the external display, where we have
a black scren(with backlight on).
This commit is based on the code of mainboard.c in
src/mainboard/roda/rk886ex.
Change-Id: I8457aaf0503e0efdf0fcba9ff5e8a07ac04c5ca6
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3265
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I7bc99761c7047e64b4e29c307ad779cec49c17c8
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3306
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
First copy over from SeaBIOS git repo, then adapt for coreboot:
Disable cpu/pci hotplug bits. Disable dynamic pci window.
Both depend on stuff in the SSDT tables created by SeaBIOS.
Bits are left in, but deactivated via #if 0, so it's easier
to see the differences when diffing the coreboot tables with
the SeaBIOS tables.
Adapt dsdt DefinitionBlock.
Enable acpi table generation in acpi_tables.c.
With this patch linux boots successfully with ACPI enabled.
It's not bug-free though. Missing cpu detection leads to
funky messages like this one:
weird, boot CPU (#0) not listed by the BIOS.
and SMP most likely wouldn't work either.
Change-Id: Ic3803a6f1ef6d54c11cc4ca3844d3032a374ae6b
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3342
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Port most of the functions found in ec/acpi/ec.c to ACPI Source Language
(ASL). These functions are used to control embedded controllers with the
standard ACPI interface (mostly through i/o ports 0x62 / 0x66).
The following methods are implemented and tested against the power
managements channels of a ITE IT8516E embedded controller:
* WAIT_EC_SC Wait for a bit in the EC_SC register
* SEND_EC_COMMAND Send one command byte to the EC_SC register
* SEND_EC_DATA Send one data byte to the EC_DATA register
* RECV_EC_DATA Read one byte of data from the EC_DATA register
* EC_READ Read one byte from ec memory (through cmd 0x80)
* EC_WRITE Write one byte to ec memory (through cmd 0x81)
To use the provided methods, one should include `ec/acpi/ec.asl` in the
EC device code. Prior doing so, two macros should be defined to identify
the used i/o ports:
* EC_SC_IO I/o address of the EC_SC register
* EC_DATA_IO I/o address of the EC_DATA register
Change-Id: I8c6706075fb4980329c228e5b830d5f4e9b188dd
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3285
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The DDI connector table and the PCIe Port List lookup table are
copied onto HEAP. This copy is not needed since these are lookup
tables used to define the platform configuration.
Change-Id: If4760f80e08faa8da4fd11337a3812f89cf805f9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add CONST modifiers to read-only pass-by-reference function
parameters in AGESA. This allows the use of "const" modifiers
on the declaration of lookup tables that are pass-by-reference.
These will be used to identify tables that are copied onto the
HEAP but don't need to be.
Change-Id: Ie1187a427804fddf47b935a110ad23931a3447a9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add boot cpu to the device tree. Figure the number of CPUs installed
(using the qemu firmware config interface) and add cpu devices for them,
so they show up in all generated BIOS tables correctly. This gets SMP
going.
Change-Id: I0e99f98942d8ca90150b27fc13c1c7e926a1a644
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds a qemu x86 cpu chip. It has no initialization function
as this isn't needed on virtual hardware. A virtual machine can have
pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu
-cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu
which is (almost) identical to the one on the host machine. So I've
added X86_VENDOR_ANY as wildcard match for the cpu_table.
Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This driver communicates with the IT8516e on the Kontron KTQM77.
Since we don't know if the firmware and protocol are standard for
the chip or customized to the board, call it kontron/it8516e.
Change-Id: I7382172c6d865d60106c929124444821a07a5184
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Idf804ed29a67bad732df19e6981f74c8d0c354b5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ica3afbf8277cb025251da7af181f8de0d0036b45
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3389
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When I've first written this macro in 2011, the correct define for
verbose SMBus message was CONFIG_DEBUG_SMBUS_SETUP. This has since
been changed to CONFIG_DEBUG_SMBUS. I didn't catch that, and this made
the printsmbus macro always evaluate to an empty statement.
Use the proper CONFIG_DEBUG_SMBUS define. This makes printsmbus
functional again.
Change-Id: Iaf03354b179cc4a061e0b65f5b746af10f5d2b88
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3379
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
Needed to make 'register "gpo" = ...' work.
While being at it add comments saying which device is which.
Change-Id: I911d5e4a7b6c7abf4ad73e863ab201e9e55ee0d4
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3346
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ie0507475f33d029d6e8ce59f138e0e7da5156d4f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3339
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The qemu debugcon port returns 0xe9 on reads in case the device is
present. Use that for detection and write console output to the
port only in case the device is actually present.
Change-Id: I41aabcf11845d24004e4f795dfd799822fd14646
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3338
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ibcc0a94638c022a76cd3c2e3387af6e1ab757ccb
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3337
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
qemu has a special device to pass configuration information
from qemu to the firmware. This patch adds initial support
the interface, namely some infrastructure, detection code and
a function to query the number of CPUs.
Change-Id: I43ff5f4fbf12334a91422aa38f514a82a1d5219e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit eed28f97b375a9469a2872996c19eb102647052e.
For whatever reason, the dependencies were lost in Gerrit and the
commit [1] was submitted without its dependencies. As a result
buidling the ASUS F2A85-M fails now [2] and therefore commits
based on this commit fail to pass the buid tests by Jenkins.
[…]
Created CBFS image (capacity = 8387656 bytes)
LINK cbfs/fallback/romstage_null.debug
CC cbfs/fallback/coreboot_ram.debug
coreboot-builds/asus_f2a85-m/generated/coreboot_ram.o:(.data+0x16b9c): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/coreboot_ram.debug] Error 1
make: *** Waiting for unfinished jobs....
coreboot-builds/asus_f2a85-m/mainboard/asus/f2a85-m/buildOpts.romstage.o:(.data+0x3d8): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
[…]
Therefore revert the commit to get the tree working again and
submit this patch with its dependencies again.
[1] http://review.coreboot.org/#/c/3317/
[2] http://qa.coreboot.org/job/coreboot-gerrit/6618/testReport/junit/(root)/board/i386_asus_f2a85_m/
Change-Id: I911755884da09eb0a0651b8db07ee2a32e6eaaaa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Do the setup for all PCI slots, not only the third.
Also remove the bogus message, as slot 3 may carry
any device, not only NICs.
This makes IRQ setup simliar to SeaBIOS.
SeaBIOS assignments (with patch for logging added,
and a bunch of pci devices for testing purposes):
PCI IRQ [piix]: bdf=00:01.3 pin=1 line=10
PCI IRQ [piix]: bdf=00:03.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:04.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:05.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:06.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.1 pin=2 line=10
PCI IRQ [piix]: bdf=00:1d.2 pin=3 line=11
PCI IRQ [piix]: bdf=00:1d.7 pin=4 line=11
Coreboot assignments without this patch:
Assigning IRQ 11 to 0:3.0
Coreboot assignments with this patch:
Assigning IRQ 10 to 0:1.3
Assigning IRQ 11 to 0:3.0
Assigning IRQ 11 to 0:4.0
Assigning IRQ 10 to 0:5.0
Assigning IRQ 10 to 0:6.0
Assigning IRQ 10 to 0:1d.0
Assigning IRQ 10 to 0:1d.1
Assigning IRQ 11 to 0:1d.2
Assigning IRQ 11 to 0:1d.7
Change-Id: Ie96be39185f2f1cbde3c9fc50e29faff59c28493
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3334
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
X86EMU_DEBUG_TIMING is needed for producing i915tool
compatible output. So add its dependencies to the
i945’s Kconfig in order to be able to use X86EMU_DEBUG_TIMINGS,
which depends on HAVE_MONOTONIC_TIMER which
LAPIC_MONOTONIC_TIMER provides/selects.
Note that UDELAY_LAPIC is already selected by the Intel CPU.
Change-Id: Ie834ebc92e527eb186a92b39341ebd0a08889fb0
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3356
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Activate the IOMMU support for the Asus F2A85-M.
Add the device to `devicetree.cb`.
$ pci -s 0.2
[…]
00:00.2 IOMMU: Advanced Micro Devices [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit
$ dmesg
[…]
[ 0.000000] ACPI: IVRS 00000000bf144e10 00070 (v02 AMD AMDIOMMU 00000001 AMD 00000000)
[ 0.000000] ACPI: SSDT 00000000bf144e80 0051F (v02 AMD ALIB 00000001 MSFT 04000000)
[ 0.000000] ACPI: SSDT 00000000bf1453a0 006B2 (v01 AMD POWERNOW 00000001 AMD 00000001)
[ 0.000000] ACPI: SSDT 00000000bf145a52 00045 (v02 CORE COREBOOT 0000002A CORE 0000002A)
[…]
[ 0.465114] [Firmware Bug]: ACPI: no secondary bus range in _CRS
[…]
[ 0.567330] pci 0000:00:00.0: >[1022:1410] type 00 class 0x060000
[ 0.567364] pci 0000:00:00.2: >[1022:1419] type 00 class 0x080600
[ 0.567427] pci 0000:00:01.0: >[1002:9993] type 00 class 0x03000
[…]
[ 0.597731] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.597899] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PIBR._PRT]
[ 0.597933] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR0._PRT]
[ 0.597972] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR1._PRT]
[ 0.598073] pci0000:00: >Requesting ACPI _OSC control (0x1d)
[ 0.603808] pci0000:00: >ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[ 0.612397] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 0.620508] Freeing initrd memory: 14876k freed
[…]
[ 0.882674] pci 0000:00:01.0: >Boot video device
[ 0.882876] PCI: CLS 64 bytes, default 64
[ 0.897088] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 extended features: PreF PPR GT IA
[ 0.905816] pci 0000:00:00.2: >irq 40 for MSI/MSI-X
[ 0.917457] AMD-Vi: Lazy IO/TLB flushing enabled
[ 0.922076] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.928500] software IO TLB [mem 0xbb13d000-0xbf13cfff] (64MB) mapped at [ffff8800bb13d000-ffff8800bf13cfff]
[ 0.938535] LVT offset 0 assigned for vector 0x400
[ 0.943338] perf: AMD IBS detected (0x000000ff)
[ 0.948037] audit: initializing netlink socket (disabled)
[ 0.953432] type=2000 audit(1369659616.800:1): initialized
[ 0.977011] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[…]
[ 7.881938] radeon 0000:00:01.0: >VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 7.881941] radeon 0000:00:01.0: >GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[…]
[ 7.885516] radeon 0000:00:01.0: >irq 48 for MSI/MSI-X
[ 7.885525] radeon 0000:00:01.0: >radeon: using MSI.
[…]
[ 8.276775] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae000 flags=0x0010]
[ 8.287363] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc00 flags=0x0010]
[ 8.297945] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae200 flags=0x0010]
[ 8.308527] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae080 flags=0x0010]
[ 8.319109] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae240 flags=0x0010]
[ 8.329694] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001accc0 flags=0x0010]
[ 8.340276] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace80 flags=0x0010]
[ 8.350858] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd80 flags=0x0010]
[ 8.361441] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae280 flags=0x0010]
[ 8.372022] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae180 flags=0x0010]
[ 8.382605] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace00 flags=0x0010]
[ 8.393188] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acdc0 flags=0x0010]
[ 8.403770] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace40 flags=0x0010]
[ 8.414353] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae1c0 flags=0x0010]
[ 8.424936] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc40 flags=0x0010]
[ 8.435518] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc80 flags=0x0010]
[ 8.446100] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae2c0 flags=0x0010]
[ 8.456684] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae300 flags=0x0010]
[ 8.467265] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae340 flags=0x0010]
[ 8.477849] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae380 flags=0x0010]
[ 8.488431] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae3c0 flags=0x0010]
[ 8.499013] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae0c0 flags=0x0010]
[ 8.509596] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acec0 flags=0x0010]
[ 8.520179] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd00 flags=0x0010]
[ 8.530761] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad000 flags=0x0010]
[ 8.541343] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae400 flags=0x0010]
[ 8.551925] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae440 flags=0x0010]
[ 8.562509] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf00 flags=0x0010]
[ 8.573090] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae480 flags=0x0010]
[ 8.583675] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae100 flags=0x0010]
[ 8.594257] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae4c0 flags=0x0010]
[…]
[ 8.604840] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf40 flags=0x0010]
[ 8.615421] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd40 flags=0x0010]
[ 8.626004] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad140 flags=0x0010]
[ 8.636587] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad040 flags=0x0010]
[ 8.647169] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad080 flags=0x0010]
[ 8.657751] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae500 flags=0x0010]
[ 8.668335] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad100 flags=0x0010]
[ 8.678917] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad0c0 flags=0x0010]
[ 8.689499] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf80 flags=0x0010]
[ 8.700080] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acfc0 flags=0x0010]
[ 8.710664] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae140 flags=0x0010]
[ 8.721246] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae040 flags=0x0010]
[ 8.731828] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad180 flags=0x0010]
[ 8.742412] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae540 flags=0x0010]
[ 8.752995] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad280 flags=0x0010]
[ 8.763577] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad340 flags=0x0010]
[ 8.774160] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad200 flags=0x0010]
[ 8.784741] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad300 flags=0x0010]
[ 8.795324] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae5c0 flags=0x0010]
[ 8.805906] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae640 flags=0x0010]
[ 8.816490] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad2c0 flags=0x0010]
[ 8.827072] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad1c0 flags=0x0010]
[ 8.837655] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad240 flags=0x0010]
[ 8.848238] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae580 flags=0x0010]
[ 8.858819] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae600 flags=0x0010]
[ 8.869402] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad3c0 flags=0x0010]
[ 8.879985] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad380 flags=0x0010]
[ 8.890568] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae7c0 flags=0x0010]
[ 8.901151] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae740 flags=0x0010]
[ 8.911732] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae6c0 flags=0x0010]
[ 8.922316] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae780 flags=0x0010]
[ 8.932897] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae700 flags=0x0010]
[ 8.943480] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae680 flags=0x0010]
[ 8.963011] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[ 8.963165] radeon 0000:00:01.0: >WB enabled
[…]
It is not known, what the implications of the `IO_PAGE_FAULT` are.
Change-Id: Ic5fde609322a5fdeb1a48052c403847197752a4b
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch was made by listenning to what Ron Minnich told
me to do on #coreboot IRC channel on Freenode with my
adaptations on top.
i915tool is at https://code.google.com/p/i915tool/ ,
the one in coreboot is outdated.
Change-Id: I13cd684f4c290114836fbd7babd461153e8d6124
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3277
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer
since it was defined in sandybridge. It is really
more of an x86 thing however, and we now have
three systems that can use it.
I considered making this more general, since it technically
can apply to PTE-based systems like ARM, and maybe we should.
But the 'WRCOMB' moniker is usually closely tied to the x86.
Change-Id: I3eb6eb2113843643348a5e18e78c53d113899ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3349
Tested-by: build bot (Jenkins)
|
|
After removing power and the CMOS Battery, putting it back
and booting coreboot we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
baud_rate = 115200
debug_level = Spew
hyper_threading = Enable
nmi = Enable
boot_devices = ''
boot_default = 0x40
cmos_defaults_loaded = Yes
lpt = Enable
volume = 0xff
tft_brightness = 0xbf
first_battery = Primary
bluetooth = Enable
The code for handling the invalid CMOS space in mainboard.c
is now useless and so it was removed.
Change-Id: Ic57a14eeeea861aa034cb0884795b0152757bf5b
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3335
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
After removing power and the CMOS Battery, putting it back
and booting coreboot we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
ECC_memory = Enable
baud_rate = 115200
hw_scrubber = Enable
interleave_chip_selects = Enable
max_mem_clock = 400Mhz
multi_core = Enable
power_on_after_fail = Disable
debug_level = Spew
boot_first = HDD
boot_second = Fallback_Floppy
boot_third = Fallback_Network
boot_index = 0xf
boot_countdown = 0xc
slow_cpu = off
nmi = Enable
iommu = Enable
nvramtool: Can not read coreboot parameter user_data because layout info specifies CMOS area that is too wide.
nvramtool: Warning: Coreboot CMOS checksum is bad.
Change-Id: Idea03b9bc75c5c34c7ce521ce5e5a1c1bb6dfa96
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3324
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
After Booting the BIOS, flashing coreboot
and booting coreboot with that patch we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
ECC_memory = Disable
baud_rate = 115200
power_on_after_fail = Disable
debug_level = Spew
boot_first = HDD
boot_second = Fallback_Floppy
boot_third = Fallback_Network
boot_index = 0xf
boot_countdown = 0x7f
nvramtool: Warning: Coreboot CMOS checksum is bad.
Change-Id: Ia87b09003d859f6dee7c09aa963df002c1d02688
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3323
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: I4a75326fef0a10a6290cdd4b1b93d9af8e3ab23d
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3268
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
Early SMBUS code with similar functionality is duplicated for all
southbridges. Add a generic SMBus API (function declarations) designed to
unify the early SMBus structure.
This patch only adds the API. It does not implement any hardware-specific
bits.
Change-Id: I0861b7a3f098115182ae6de9f016dd671c500bad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/143
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
MRS commands are used to tell the DRAM chip what timing and what
termination and drive strength to use, along with other parameters.
The MRS commands are defined by the DDR3 specification [1]. This
makes MRS commands hardware-independent.
MRS command creation is duplicated in various shapes and forms in any
chipset that does DDR3. This is an effort to create a generic MRS API
that can be used with any chipset.
This is used in the VX900 branch.
[1] www.jedec.org/sites/default/files/docs/JESD79-3E.pdf
Change-Id: Ia8bb593e3e28a5923a866042327243d798c3b793
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3354
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
While we had support for updating microcode on the VIA Nano CPUs for a
while now, we never included the actual microcode. Unlike, Intel and
AMD CPUs, VIA microcode is not available for download, and was
extracted from the vendor BIOS. It was not included in coreboot since
we never had explicit permission to do so. I have just received
confirmation from VIA that we can distribute the microcode.
Change-Id: I4c15b090cd2713cfe5dc6b50db777ff89dbc0f19
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3357
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I249c63646267ebe8dd8e06980aa6367a16fe7297
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3370
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
