| Age | Commit message (Collapse) | Author |
|---|
|
Split the Persimmon DSDT into common code areas.
For example, split the Southbridge specific code into
the Southbridge directory and CPU specific code into
the CPU directory. Also adding the superio.asl file
to the Persimmon DSDT tree. This file is empty for
the moment but will be necessary in the future. I have
also emptied the thermal.asl file in the mainboard
directory because it does not seem to perform as
intended (fan control does not change when it is
brought back into the code base) and it has been
inside a '#if 0' statement for a long time. Removing
it until it is decided that it is actually necessary.
This change was verified in three different ways:
1. Visual comparison of the compiled DSDT pulled from the
Persimmon after booting into Linux using the ACPI tools
acpidump, acpixtract, and iasl. The comparison was done
between the DSDT before and after doing the split work.
This test is somewhat difficult considering the expanse
of the changes. Blocks of code have been moved, and
others changed.
2. Linux logs were dumped before and after the DSDT split.
Logs dumped and compared include dmesg and lspci -tv.
Neither log changed significantly between the two compare
points.
3. The test suite FWTS was run on the Coreboot build both
before and after doing the DSDT split with the command
'sudo fwts -b -P -u'. The flag -b specifies all batch jobs,
-P specifies all power tests, and -u specifies utilities.
Interactive jobs were not run as most of them consist of
laptop checks. Again, there were no significant changes
between the two endpoints.
These tests lead me to believe that there was no change in
the functionality of the ACPI tables apart from what is
known and expected.
This patch is the first of a series of patches to split the DSDT.
The ASRock patch was merged before this one and breaks the ASROCK
E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/).
Please be aware of this dependency when pulling these patches.
Other patches that depend on this patch are
'AMD Fam14: Split out the AMD Fam14 DSDT'
(http://review.coreboot.org/#/c/3051/)
and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC'
(http://review.coreboot.org/#/c/3052/)
Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3048
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Reading commit »libpayload: New AHCI, ATA and ATAPI drivers«
(1f6bd94f) [1], the spelling error was found and is now fixed.
[1] http://review.coreboot.org/1622
Change-Id: Id418bcb99c1a9a400a49fc04078e465bd0908074
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3071
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We need these to be inputs so they can be read when populating the coreboot
tables. It seems like a good idea to do this early to ensure that the input
gate capacitance has had a chance to charge, and if we decide to use
actually use that information during the ROM stage to do earlier RW
firmware selection.
It is not guarded by a ChromeOS config variable because those lines are
always intended to be input GPIOs, regardless of whether we're running
ChromeOS or not.
Change-Id: Id76008931b5081253737c6676980a1bdb476ac09
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3067
Tested-by: build bot (Jenkins)
|
|
Change-Id: I34097f878291367b28962048190e11ccaacfc514
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3066
Tested-by: build bot (Jenkins)
|
|
It's better to recognize aborts when they occur than to mask them to
discover them later without knowing where they actually came from.
Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3065
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This is the same split as was done on the Persimmon.
Change-Id: I25bd63f23417b7926232f07eaaa7917170af9d60
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Properly use the chip settings when configuring the CPU,
at this point being purely graphics.
Change-Id: I9bc2d32c1037653837937b314e4041abc0024835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3054
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add basic edp support to the ramstage. Not working.
Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
|
|
This does basic re-factoring to fit the driver into coreboot.
Change-Id: Id5f8c12a73ec37ddd545d50b3e8e9b3012657db1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3061
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This imports TPS65090 PMIC from u-boot and adds/updates Makefiles
and Kconfig files. The follow-up patch will re-factor the code.
Change-Id: Ic9e43b9665ddf7f55feae8fa17fbf3d2d5f4756d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3060
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is a simpler device tree that is also more correct,
and has graphics settings as well.
Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3053
Tested-by: build bot (Jenkins)
|
|
Basic cleanup, this code still does not work.
Change-Id: I84ed9f08fd04cd8eb74cd860e0775d8c602f42d6
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3049
Tested-by: build bot (Jenkins)
|
|
This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.
This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.
Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
In such cases the safe versions of readl() and writel() should be
used anyway.
Note: This also fixes two dubious casts as to avoid breaking
compilation.
Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.
- i2c_read() and i2c_write() functions updated to take bus number
as an argument.
- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
i2c_write(). If a chip needs special handling we should take care
of it elsewhere, not in every low-level i2c driver.
- All the confusing bus config functions eliminated. No more
i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
is handled automatically when the caller does a transaction and
specifies the desired bus number.
- i2c_probe() eliminated. We're not a command-line utility.
- Let the compiler place static variables automatically. We don't need
any of this fancy manual data placement.
- Remove dead code while we're at it. This stuff was ported early on
and much of it was left commented out in case we needed it. Some
also includes nested macros which caused gcc to complain.
- Clean up #includes (no more common.h, woohoo!), replace debug() with
printk().
Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:
- We only need to expose i2c_read() and i2c_write() in our public API.
Everything else is board/chip-dependent and should remain hidden
away.
- i2c_read and i2c_write functions will take bus number as an arg
and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
error and end up cluttering the code since the user needs to save
the old bus number, set the new one, do the read/write, and restore
the old value (3 added steps to do a simple transaction).
- Stop setting default values for board-specific things like SPD
and RTC bus numbers (as if we always have an SPD or RTC on I2C).
- Death to all the trivial inline wrappers. And in case there was any
doubt, we really don't care about the MPC8xx. Though if we did then
we would not pollute the public API with its idiosyncrasies.
Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Originally developed by LiPPERT and after the acquisition marketed as
'LiPPERT by ADLINK', the plan is now to streamline both boards into the
ADLINK naming scheme. But AFAIK a few have already been sold and as of
this writing the website still advertises the old names. And in any case
the veteran LX products will continue to be sold by ADLINK under their
original names.
So create CONFIG_VENDOR_ADLINK, currently only telling users to look under
LiPPERT (however any future boards will be added here).
Further add an explanation to CONFIG_VENDOR_LIPPERT, and in the Mainboard
model selection show both names.
Change-Id: Iaafa88533ef4cce33243293c3d55754e7e93d003
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3046
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Current code outputs the whole cbmemc buffer even if only part of
it is really used. Fix it to output only the used part and notify
the user if the buffer was too small for the required data.
Change-Id: I68c1970cf84d49b2d7d6007dae0679d7a7a0cb99
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2991
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:
commit aa3f7ba36ebe3a933aa664f826382f60b31e86f1
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Thu Mar 28 16:51:45 2013 -0700
cbfstool: Replace C++ code with C code
Reviewed-on: http://review.coreboot.org/3010
In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.
Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
read_option was unified between ramstage and romstage a while ago.
However, it seems some invocations were not fixed accordingly.
This patch switches uart8250mem.c to use the new scheme.
Change-Id: I03cef4f6ee9188a6412c61d7ed34fbaff808a32b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3033
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
With CONFIG_DEBUG_COVERAGE enabled, the build currently fails with
src/lib/gcov-glue.c: In function 'fseek':
src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format]
src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format]
Change-Id: Iddaa601748c210d9dad06ae9dab2a3deaa635b2c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3032
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This change modifies the code in libpayload that scans the PCI hierarchy for
USB controllers. Previously, if a devices primary function (function 0) was a
bridge, then none of the other functions, if any, would be looked at. If one
of the other functions was a bridge, that wouldn't be handled either. The new
version looks at each function that's present no matter what, and if it
discovers that it's a bridge it scans the other side.
Change-Id: I37f269a4fe505fd32d9594e2daf17ddd78609c15
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2517
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This adds condition codes when using the msr instruction. Although
described as "optional" in the Cortex-A series programmer's guide,
our experience with using the msr instruction in the payload suggests
that the condition code is not optional and that this only worked
in coreboot (and u-boot) because the processor comes up in SVC32 mode.
(credit to Gabe Black for finding this, I'm only uploading the patch)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0aa4715ae415e1ccc5719b7b55adcd527cc1597b
Reviewed-on: http://review.coreboot.org/3037
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This adds a missing address-of operator. This was a subtle bug that
didn't seem to cause problems at first since the serial console
appeared to work. However it caused an imprecise external abort which
became apparent later on when aborts were unmasked in the kernel via
the CPSR_A bit.
(credit goes to Gabe Black for finding this)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I80a33b147d92d559fa8fefbe7d5642235deb9aea
Reviewed-on: http://review.coreboot.org/3038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I6a119b1f362f481914377e8d14c713159f895130
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3030
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Display hardware is part of this SOC, and we need to be able
to set certain variables in devicetree.cb. This chip file
contains the initial things we think we need to set.
Change-Id: I16f2d4228c87116dbeb53a3c9f3f359a6444f552
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3031
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Explicitly call out the effects of hyperthreads running the
MTRR code and its impact on the enablement of ROM caching.
Change-Id: I14b8f3fdc112340b8f483f2e554c5680576a8a7c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3018
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This fixes at least one warning on my machine where "llx" is replaced by PRIx64.
Change-Id: Iee3e5027d327d4d5f8e6d8b2d53d051f74bfc354
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3024
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This was a first pass at display port support, we have
realized that it was ultimately a bad path. The display
hardware is intimately tied into a specific cpu and
mainboard combination, and the code has to be elsewhere.
The devicetree formatting is ugly, but it matters not:
it's changing soon.
Change-Id: Iddce54f9e7219a7569315565fac65afbbe0edd29
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3029
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Cppcheck [1], a static code analysis tool, warns about the
following.
$ cppcheck --version
Cppcheck 1.59
$ cppcheck --enable=all .
[…]
Checking cpu.c...
[cpu.c:951]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[cpu.c:962]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[…]
And indeed, `core` is an unsigned integer and `man 3 printf` tells
the following about conversion specifiers.
d, i The int argument is converted to signed decimal notation. […]
o, u, x, X
The unsigned int argument is converted to unsigned octal (o), unsigned decimal (u), or unsigned hexadecimal (x and X)
notation.
So use `u` and Cppcheck does not complain anymore.
[1] http://cppcheck.sourceforge.net/
Change-Id: If8dd8d0efe75fcb4af2502ae5100e3f2062649e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3026
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
directory line
Nico Huber spotted [1], that commit (4d6ab4e2) [1] updating
superiotools’s `README` with the Git command line
superiotool: Update README with Git repository URL and directory location
missed, that after `git clone` one sitll has to change into
the cloned directory.
So prepend the path with `coreboot/` to fix that. The same error
happened in the commit (e1ea5151) for libpayload [2]
libpayload: Update README with Git repository URL and directory location
and is fixed in this patch too.
[1] http://review.coreboot.org/#/c/3019/
[2] http://review.coreboot.org/2228
Change-Id: Ib6e8b678af6276556a40ccfd52ae35ca7e674455
Reported-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3021
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
When building inteltool under x86-32, the following warnings are
shown.
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
Nico Huber commented the following [1].
I don't see those warnings because I build for x86-64. I guess
they could be fixed by casting to `ptrdiff_t` (from stddef.h)
instead of `uint64_t`.
And indeed, using `ptrdiff_t` fixes the warning. But as Stefan
Reinauer commented in [2], `intptr_t` is more appropriate as this
is just a pointer and no pointer difference.
So `intptr_t` is taken, which fixes these issues warned about too.
These warnings were introduced in commit »inteltool: Add support for
dumping AMB registers« (4b7b320f) [3].
[1] http://review.coreboot.org/#/c/2996/1//COMMIT_MSG
[2] http://review.coreboot.org/#/c/3002/1/util/inteltool/amb.c
[3] http://review.coreboot.org/525
Change-Id: I2ea1a31dc1e3db129e767d6a9e0433fd75a77d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3002
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
|
|
Based on comments in cpu/x86/msr.h for wrmsr/rdmsr, and for symmetry,
I have added __attribute__((always_inline)) for these.
Change-Id: Ia0a34c15241f9fbc8c78763386028ddcbe6690b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2898
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I36d980cea5ca9cc67262dba809441091757e1fb5
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3019
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This was there since the beginning
commit d24d6993b6d7bcf7977d74d081e718e1b076d1b0
Author: arch import user (historical) <svn@openbios.org>
Date: Wed Jul 6 17:06:46 2005 +0000
Revision: linuxbios@linuxbios.org--devel/freebios--devel--2.0--patch-26
Creator: Hamish Guthrie <hamish@prodigi.ch>
Added AMD GX1 northbridge and cs5530 Southbridge
but blindly copied from Intel 440 BX and is not used anywhere.
Thanks to Idwer Vollering for spotting this.
Change-Id: I38b3d3feb25966c3aa382994d323e59c3f3c9e6c
Reported-by: Idwer Vollering
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3020
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
|
|
src/southbridge/intel/lynxpoint/pmutil.c was committed with two
things that needed fixing.
Change-Id: Ib83343a75840aa29847b607b0275971eb8140f12
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3003
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
`broadcom_init()`"
Commit 5d741567 added a prototype to broadcom.c to fix a warning. This part
is fine.
It also changed mainboard.c to #include broadcom.c. But broadcom.c is
already in Makefile.inc, now building will fail because the linker gets
broadcom_init() twice.
Undo the change to mainboard.c but keep the change to broadcom.c.
Change-Id: Ieccc098f477ffacccf4174056998034a220a9744
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3012
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
If ROM caching is selected the sandybridge chipset code will
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I3a57ba8753678146527ebf9547f5fbbd4f441f43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If ROM caching is selected the haswell CPU initialization code
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I75424bb75174bfeca001468c3272e6375e925122
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3016
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The MP code on haswell was mirroring the BSPs MTRRs. In addition it
was cleaning up the ROM cache so that the MTRR register values were
the same once the OS was booted. Since the hyperthread sibling of
the BSP was going through this path the ROM cache was getting torn
down once the hyperthread was brought up.
That said, there was no differnce in observed boot time keeping the
ROM cache enabled.
Change-Id: I2a59988fcfeea9291202c961636ea761c2538837
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3008
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The haswell code was using the old assumption of which MTRR
was used for the ROM cache. Now that there is an API for doing
this use it as the old assumption is no longer valid.
Change-Id: I59ef897becfc9834d36d28840da6dc4f1145b0c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3007
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Introduced in commit »intel microcode: split up microcode loading
stages« (98ffb426) [1].
[1] http://review.coreboot.org/2778
Change-Id: I626508b10f3998b43aaabd49853090b36f5d3eb0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2992
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
Adding a pxe rom manually is inconvenient.
With this patch, PXE ROM can be added automatically by selecting PXE_ROM in Kconfig.
I have tested this patch on AMD Parmer and Thatcher with iPXE.
iPXE would be a boot device in Seabios when pressing F12.
iPXE works well with coreboot and Seabios.
Change-Id: I2c4fc73fd9ae6c979f0af2290d410935f600e2c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3013
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Now that the ASRock E350M1 builds without any warnings, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: Idfecfb1434158969334a4b37972b5fc6fd76e72a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3014
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
When buidling inteltool with GCC, the following warning is printed.
$ make
[…]
gcc -O2 -g -Wall -W -c -o memory.o memory.c
memory.c: In function ‘print_mchbar’:
memory.c:287:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
[…]
This was introduced in commit »inteltool: Add support for H65 Express
chipset« (c7fc4422) [1].
Address this warning, by using `%llx` instead of `%lx`.
[1] http://review.coreboot.org/1258
Change-Id: I4f714edce7e8b405e1a7a417d02fa498322c88a8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2994
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
|
|
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.
Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The help text says --machine, but the code
actually checked for --arch. Fix it!
Change-Id: Ib9bbf758b82ef070550348e897419513495f154b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3009
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
When building the ASRock E350M1, the following warnings are shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/buildOpts.romstage.o
In file included from src/mainboard/asrock/e350m1/buildOpts.c:294:0:
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:6: warning: "DDR1333_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:40: warning: "DDR1866_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:5: warning: "TIMING_MODE_AUTO" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:31: warning: "TIMING_MODE_SPECIFIC" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:5: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:33: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:5: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:28: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
[…]
Adding the corresponding defines as done for AMD Persimmon in
commit d7a696d0f229abccc95ff411f28d91b9b796ab74
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
addresses the warnings.
Change-Id: Id311b2dacdba5f2e6b4d834e43db0310213a35f9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2962
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Introduced in »libpayload: New CBFS to support multiple firmware
media sources.« (d01d0368) [1].
[1] http://review.coreboot.org/2191
Change-Id: I9feb9ab49825744cd00d6392a526f7af0ed053d1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2997
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
|
|
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds configuration of SerialIO devices in the Lynxpoint-LP
chipset. This includes DMA, I2C, SPI, UART, and SDIO controllers.
There is assorted magic setup necessary for the devices and
while it is similar for each device there are subtle differences
in some register settings.
These devices must be put into "ACPI Mode" in order to take
advantage of S0ix. When in ACPI mode the allocated PCI BARs
must be passed to ACPI so it can be relayed to the OS. When
the devices are in ACPI mode BAR0+BAR1 is saved into ACPI NVS
and then updated and returned when the OS calls _CRS.
Note that is is not entirely complete yet. We need to update
the IASL compiler in our build environment to support ACPI 5.0
in order to be able to pass the FixedDMA entries to the kernel.
There are also no ACPI methods defined yet to do D0->D3->D0
transitions for actually entering/exiting S0ix states.
This is hard to test right now because our kernel does not support
any of these devices in ACPI mode. I was able to build and test
the upstream bleeding-edge branch of the linux-pm git tree. With
that tree I was able to enumerate and load the driver for the
DesignWare I2C driver and attempt to probe the I2C bus -- although
there are no devices attatched.
I am also able to see the resources from ACPI in /proc/iomem get
reserved properly in the kernel.
Change-Id: Ie311addd6a25f3b7edf3388fe68c1cd691a0a500
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2971
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This enables all of the SerialIO devices and sets the flag
to put them in ACPI mode.
Change-Id: I7436c47d26028e95bbefafc320854c7cc34a4d44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2972
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This bit offset is incorrect and should only be set based
on another bit in a different register.
Change-Id: I6037534236e3a4a5d15e15011ed9b5040b435eaf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2973
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I did not check what was once after the 'and'.
Change-Id: I9f3f725bec281a94abdb2eeb692a96fecdebcc0c
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/2999
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The TPM code wasn't previously honoring MOCK_TPM=1. Because of this,
boards with TPMs that didn't handle S3 resume properly would cause a
hard reset. Allow one to build with MOCK_TPM=1 on the command line so
that S3 can still work.
Change-Id: I9adf06647de285c0b0a3203d8897be90d7783a1e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2976
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The new enable_pm1() function was doing 2 things wrong:
1. It was doing a RMW of the pm1 register. This means we were
keeping around the enables from the OS during S3 resume. This
is bad in the face of the RTC alarm waking us up because it would
cause an infinite stream of SMIs.
2. The register size of PM1_EN is 16-bits. However, the previous
implementation was accessing it as a 32-bit register.
The PM1 enables should only be set to what we expect to handle in the
firmware before the OS changes to ACPI mode.
Change-Id: Ib1d3caf6c84a1670d9456ed159420c6cb64f555e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2978
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Building libpayload with the PDCurses backend the following warning
is shown.
/src/coreboot/payloads/libpayload(master) $ make clean
/src/coreboot/payloads/libpayload(master) $ make
[…]
CC curses/pdcurses-backend/pdcscrn.libcurses.o
curses/pdcurses-backend/pdcscrn.c: In function 'PDC_scr_open':
curses/pdcurses-backend/pdcscrn.c:75:5: warning: "CONFIG_SPEAKER" is not defined [-Wundef]
[…]
The GCC documentation states [1]
In some contexts this shortcut is undesirable. The -Wundef option
causes GCC to warn whenever it encounters an identifier which is
not a macro in an ‘#if’.
and therefore use `#ifdef` [2] to silence this warning. No functional
change is done, as `CONFIG_SPEAKER` is assigned the value `Y` when
defined.
There was some discussion going on the list [3], but my points in there
turned out to be incorrect.
[1] http://gcc.gnu.org/onlinedocs/cpp/If.html
[2] http://gcc.gnu.org/onlinedocs/cpp/Ifdef.html
[3] http://www.coreboot.org/pipermail/coreboot/2013-March/075561.html
Change-Id: I8e9c9b5d01985b21ad05018986d614cf9bf2b439
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2934
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
|
|
Previously southbridge_smm_init() was provided that did both
the clearing of the SMM state and enabling SMIs. This is
troublesome in how haswell machines bring up the APs. The BSP
enters SMM once to determine if parallel SMM relocation is possible.
If it is possible the BSP releases the APs to do SMM relocation.
Normally, after the APs complete the SMM relocation, the BSP would then
re-enter the relocation handler to relocate its own SMM space.
However, because SMIs were previously enabled it is possible for an SMI
event to occur before the APs are complete or have entered the
relocation handler. This is bad because the BSP will turn off parallel
SMM save state. Additionally, this is a problem because the relocation
handler is not written to handle regular SMIs which can cause an
SMI storm which effectively looks like a hung machine. Correct these
issues by turning on SMIs after all the SMM relocation has occurred.
Change-Id: Id4f07553b110b9664d51d2e670a14e6617591500
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Allow to override the variables `CC`, `INSTALL`, `PREFIX`,
`CFLAGS` and `LDFLAGS`. Though append `-lpci -lz` to `LDFLAGS`.
This way for example a different compiler can easily be used.
CC=clang make
As a side note, Clang in contrast to GCC does *not* issue the
following warnings.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
These are only shown under 32-bit and not 64-bit
$ uname -m
i686
and are going to be fixed in a separate patch.
Change-Id: Id75dea081ecb35390f283520a7e5dce520f4c98d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2996
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds default values for the GPIO setup on Intel's Cougar Point and
Panther Point platform controller hubs (PCH). Values are taken from [1] and
[2], respectively. I've tested this with an H77 PCH. See below for the
output.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
$ ./inteltool -G
CPU: Processor Type: 0, Family 6, Model 3a, Stepping 9
Northbridge: 8086:0150 (unknown)
Southbridge: 8086:1e4a (H77)
========== GPIO DIFFS ===========
GPIOBASE = 0x0500 (IO)
gpiobase+0x0000: 0xb96ba1fb (GPIO_USE_SEL)
gpiobase+0x0000: 0xb96ba1ff (GPIO_USE_SEL) DEFAULT
gpiobase+0x0000: 0x00000004 (GPIO_USE_SEL) DIFF
gpiobase+0x0004: 0x06ff6efb (GP_IO_SEL)
gpiobase+0x0004: 0xeeff6eff (GP_IO_SEL) DEFAULT
gpiobase+0x0004: 0xe8000004 (GP_IO_SEL) DIFF
gpiobase+0x000c: 0xe1f17f7e (GP_LVL)
gpiobase+0x000c: 0x02fe0100 (GP_LVL) DEFAULT
gpiobase+0x000c: 0xe30f7e7e (GP_LVL) DIFF
gpiobase+0x002c: 0x00002000 (GPI_INV)
gpiobase+0x002c: 0x00000000 (GPI_INV) DEFAULT
gpiobase+0x002c: 0x00002000 (GPI_INV) DIFF
gpiobase+0x0030: 0x0aff70ff (GPIO_USE_SEL2)
gpiobase+0x0030: 0x020300ff (GPIO_USE_SEL2) DEFAULT
gpiobase+0x0030: 0x08fc7000 (GPIO_USE_SEL2) DIFF
gpiobase+0x0034: 0x15038ff2 (GP_IO_SEL2)
gpiobase+0x0034: 0x1f57fff4 (GP_IO_SEL2) DEFAULT
gpiobase+0x0034: 0x0a547006 (GP_IO_SEL2) DIFF
gpiobase+0x0038: 0xb65e7f4f (GP_LVL2)
gpiobase+0x0038: 0xa4aa0007 (GP_LVL2) DEFAULT
gpiobase+0x0038: 0x12f47f48 (GP_LVL2) DIFF
gpiobase+0x0040: 0x000001f3 (GPIO_USE_SEL3)
gpiobase+0x0040: 0x00000130 (GPIO_USE_SEL3) DEFAULT
gpiobase+0x0040: 0x000000c3 (GPIO_USE_SEL3) DIFF
gpiobase+0x0044: 0x00000ef3 (GPIO_SEL3)
gpiobase+0x0044: 0x00000ff0 (GPIO_SEL3) DEFAULT
gpiobase+0x0044: 0x00000103 (GPIO_SEL3) DIFF
gpiobase+0x0048: 0x00000dfc (GPIO_LVL3)
gpiobase+0x0048: 0x000000c0 (GPIO_LVL3) DEFAULT
gpiobase+0x0048: 0x00000d3c (GPIO_LVL3) DIFF
gpiobase+0x0060: 0x00000000 (GP_RST_SEL1)
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DEFAULT
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DIFF
$ ./inteltool -gG
CPU: Processor Type: 0, Family 6, Model 3a, Stepping 9
Northbridge: 8086:0150 (unknown)
Southbridge: 8086:1e4a (H77)
============= GPIOS =============
GPIOBASE = 0x0500 (IO)
gpiobase+0x0000: 0xb96ba1fb (GPIO_USE_SEL)
gpiobase+0x0000: 0xb96ba1ff (GPIO_USE_SEL) DEFAULT
gpiobase+0x0000: 0x00000004 (GPIO_USE_SEL) DIFF
gpiobase+0x0004: 0x06ff6efb (GP_IO_SEL)
gpiobase+0x0004: 0xeeff6eff (GP_IO_SEL) DEFAULT
gpiobase+0x0004: 0xe8000004 (GP_IO_SEL) DIFF
gpiobase+0x0008: 0x00000000 (RESERVED)
gpiobase+0x000c: 0xe1f17f7e (GP_LVL)
gpiobase+0x000c: 0x02fe0100 (GP_LVL) DEFAULT
gpiobase+0x000c: 0xe30f7e7e (GP_LVL) DIFF
gpiobase+0x0010: 0x00000000 (RESERVED)
gpiobase+0x0014: 0x00000000 (RESERVED)
gpiobase+0x0018: 0x00040000 (GPO_BLINK)
gpiobase+0x001c: 0x00000000 (GP_SER_BLINK)
gpiobase+0x0020: 0x00080000 (GP_SB_CMDSTS)
gpiobase+0x0024: 0x00000000 (GP_SB_DATA)
gpiobase+0x0028: 0x0000 (GPI_NMI_EN)
gpiobase+0x002a: 0x0000 (GPI_NMI_STS)
gpiobase+0x002c: 0x00002000 (GPI_INV)
gpiobase+0x002c: 0x00000000 (GPI_INV) DEFAULT
gpiobase+0x002c: 0x00002000 (GPI_INV) DIFF
gpiobase+0x0030: 0x0aff70ff (GPIO_USE_SEL2)
gpiobase+0x0030: 0x020300ff (GPIO_USE_SEL2) DEFAULT
gpiobase+0x0030: 0x08fc7000 (GPIO_USE_SEL2) DIFF
gpiobase+0x0034: 0x15038ff2 (GP_IO_SEL2)
gpiobase+0x0034: 0x1f57fff4 (GP_IO_SEL2) DEFAULT
gpiobase+0x0034: 0x0a547006 (GP_IO_SEL2) DIFF
gpiobase+0x0038: 0xb65e7f4f (GP_LVL2)
gpiobase+0x0038: 0xa4aa0007 (GP_LVL2) DEFAULT
gpiobase+0x0038: 0x12f47f48 (GP_LVL2) DIFF
gpiobase+0x003c: 0x00000000 (RESERVED)
gpiobase+0x0040: 0x000001f3 (GPIO_USE_SEL3)
gpiobase+0x0040: 0x00000130 (GPIO_USE_SEL3) DEFAULT
gpiobase+0x0040: 0x000000c3 (GPIO_USE_SEL3) DIFF
gpiobase+0x0044: 0x00000ef3 (GPIO_SEL3)
gpiobase+0x0044: 0x00000ff0 (GPIO_SEL3) DEFAULT
gpiobase+0x0044: 0x00000103 (GPIO_SEL3) DIFF
gpiobase+0x0048: 0x00000dfc (GPIO_LVL3)
gpiobase+0x0048: 0x000000c0 (GPIO_LVL3) DEFAULT
gpiobase+0x0048: 0x00000d3c (GPIO_LVL3) DIFF
gpiobase+0x004c: 0x00000000 (RESERVED)
gpiobase+0x0050: 0x00000000 (RESERVED)
gpiobase+0x0054: 0x00000000 (RESERVED)
gpiobase+0x0058: 0x00000000 (RESERVED)
gpiobase+0x005c: 0x00000000 (RESERVED)
gpiobase+0x0060: 0x00000000 (GP_RST_SEL1)
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DEFAULT
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DIFF
gpiobase+0x0064: 0x00000000 (GP_RST_SEL2)
gpiobase+0x0068: 0x00000000 (GP_RST_SEL3)
gpiobase+0x006c: 0x00000000 (RESERVED)
gpiobase+0x0070: 0x00000000 (RESERVED)
gpiobase+0x0074: 0x00000000 (RESERVED)
gpiobase+0x0078: 0x00000000 (RESERVED)
gpiobase+0x007c: 0x00000000 (RESERVED)
Change-Id: If99cf8d5c93e34ad28f52080fff64e01c220eb27
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3001
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds an option -G, --gpio-diffs to inteltool, which shows GPIO settings
that differ from platform defaults. For differing registers, the current,
the default, and an xor of the default and the current value is printed. A
follow-up commit will add defaults for the Cougar/Panther Point platform
controller hubs. If you specify both, -g and -G on the command line, all
GPIO registers will be printed interleaved with the diff.
Here's a preview:
$ ./inteltool -G
CPU: Processor Type: 0, Family 6, Model 3a, Stepping 9
Northbridge: 8086:0150 (unknown)
Southbridge: 8086:1e4a (H77)
========== GPIO DIFFS ===========
GPIOBASE = 0x0500 (IO)
gpiobase+0x0000: 0xb96ba1fb (GPIO_USE_SEL)
gpiobase+0x0000: 0xb96ba1ff (GPIO_USE_SEL) DEFAULT
gpiobase+0x0000: 0x00000004 (GPIO_USE_SEL) DIFF
gpiobase+0x0004: 0x06ff6efb (GP_IO_SEL)
gpiobase+0x0004: 0xeeff6eff (GP_IO_SEL) DEFAULT
gpiobase+0x0004: 0xe8000004 (GP_IO_SEL) DIFF
gpiobase+0x000c: 0xe1f17f7e (GP_LVL)
gpiobase+0x000c: 0x02fe0100 (GP_LVL) DEFAULT
gpiobase+0x000c: 0xe30f7e7e (GP_LVL) DIFF
gpiobase+0x002c: 0x00002000 (GPI_INV)
gpiobase+0x002c: 0x00000000 (GPI_INV) DEFAULT
gpiobase+0x002c: 0x00002000 (GPI_INV) DIFF
gpiobase+0x0030: 0x0aff70ff (GPIO_USE_SEL2)
gpiobase+0x0030: 0x020300ff (GPIO_USE_SEL2) DEFAULT
gpiobase+0x0030: 0x08fc7000 (GPIO_USE_SEL2) DIFF
gpiobase+0x0034: 0x15038ff2 (GP_IO_SEL2)
gpiobase+0x0034: 0x1f57fff4 (GP_IO_SEL2) DEFAULT
gpiobase+0x0034: 0x0a547006 (GP_IO_SEL2) DIFF
gpiobase+0x0038: 0xb65e7f4f (GP_LVL2)
gpiobase+0x0038: 0xa4aa0007 (GP_LVL2) DEFAULT
gpiobase+0x0038: 0x12f47f48 (GP_LVL2) DIFF
gpiobase+0x0040: 0x000001f3 (GPIO_USE_SEL3)
gpiobase+0x0040: 0x00000130 (GPIO_USE_SEL3) DEFAULT
gpiobase+0x0040: 0x000000c3 (GPIO_USE_SEL3) DIFF
gpiobase+0x0044: 0x00000ef3 (GPIO_SEL3)
gpiobase+0x0044: 0x00000ff0 (GPIO_SEL3) DEFAULT
gpiobase+0x0044: 0x00000103 (GPIO_SEL3) DIFF
gpiobase+0x0048: 0x00000dfc (GPIO_LVL3)
gpiobase+0x0048: 0x000000c0 (GPIO_LVL3) DEFAULT
gpiobase+0x0048: 0x00000d3c (GPIO_LVL3) DIFF
gpiobase+0x0060: 0x00000000 (GP_RST_SEL1)
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DEFAULT
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DIFF
$ ./inteltool -gG
CPU: Processor Type: 0, Family 6, Model 3a, Stepping 9
Northbridge: 8086:0150 (unknown)
Southbridge: 8086:1e4a (H77)
============= GPIOS =============
GPIOBASE = 0x0500 (IO)
gpiobase+0x0000: 0xb96ba1fb (GPIO_USE_SEL)
gpiobase+0x0000: 0xb96ba1ff (GPIO_USE_SEL) DEFAULT
gpiobase+0x0000: 0x00000004 (GPIO_USE_SEL) DIFF
gpiobase+0x0004: 0x06ff6efb (GP_IO_SEL)
gpiobase+0x0004: 0xeeff6eff (GP_IO_SEL) DEFAULT
gpiobase+0x0004: 0xe8000004 (GP_IO_SEL) DIFF
gpiobase+0x0008: 0x00000000 (RESERVED)
gpiobase+0x000c: 0xe1f17f7e (GP_LVL)
gpiobase+0x000c: 0x02fe0100 (GP_LVL) DEFAULT
gpiobase+0x000c: 0xe30f7e7e (GP_LVL) DIFF
gpiobase+0x0010: 0x00000000 (RESERVED)
gpiobase+0x0014: 0x00000000 (RESERVED)
gpiobase+0x0018: 0x00040000 (GPO_BLINK)
gpiobase+0x001c: 0x00000000 (GP_SER_BLINK)
gpiobase+0x0020: 0x00080000 (GP_SB_CMDSTS)
gpiobase+0x0024: 0x00000000 (GP_SB_DATA)
gpiobase+0x0028: 0x0000 (GPI_NMI_EN)
gpiobase+0x002a: 0x0000 (GPI_NMI_STS)
gpiobase+0x002c: 0x00002000 (GPI_INV)
gpiobase+0x002c: 0x00000000 (GPI_INV) DEFAULT
gpiobase+0x002c: 0x00002000 (GPI_INV) DIFF
gpiobase+0x0030: 0x0aff70ff (GPIO_USE_SEL2)
gpiobase+0x0030: 0x020300ff (GPIO_USE_SEL2) DEFAULT
gpiobase+0x0030: 0x08fc7000 (GPIO_USE_SEL2) DIFF
gpiobase+0x0034: 0x15038ff2 (GP_IO_SEL2)
gpiobase+0x0034: 0x1f57fff4 (GP_IO_SEL2) DEFAULT
gpiobase+0x0034: 0x0a547006 (GP_IO_SEL2) DIFF
gpiobase+0x0038: 0xb65e7f4f (GP_LVL2)
gpiobase+0x0038: 0xa4aa0007 (GP_LVL2) DEFAULT
gpiobase+0x0038: 0x12f47f48 (GP_LVL2) DIFF
gpiobase+0x003c: 0x00000000 (RESERVED)
gpiobase+0x0040: 0x000001f3 (GPIO_USE_SEL3)
gpiobase+0x0040: 0x00000130 (GPIO_USE_SEL3) DEFAULT
gpiobase+0x0040: 0x000000c3 (GPIO_USE_SEL3) DIFF
gpiobase+0x0044: 0x00000ef3 (GPIO_SEL3)
gpiobase+0x0044: 0x00000ff0 (GPIO_SEL3) DEFAULT
gpiobase+0x0044: 0x00000103 (GPIO_SEL3) DIFF
gpiobase+0x0048: 0x00000dfc (GPIO_LVL3)
gpiobase+0x0048: 0x000000c0 (GPIO_LVL3) DEFAULT
gpiobase+0x0048: 0x00000d3c (GPIO_LVL3) DIFF
gpiobase+0x004c: 0x00000000 (RESERVED)
gpiobase+0x0050: 0x00000000 (RESERVED)
gpiobase+0x0054: 0x00000000 (RESERVED)
gpiobase+0x0058: 0x00000000 (RESERVED)
gpiobase+0x005c: 0x00000000 (RESERVED)
gpiobase+0x0060: 0x00000000 (GP_RST_SEL1)
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DEFAULT
gpiobase+0x0060: 0x01000000 (GP_RST_SEL1) DIFF
gpiobase+0x0064: 0x00000000 (GP_RST_SEL2)
gpiobase+0x0068: 0x00000000 (GP_RST_SEL3)
gpiobase+0x006c: 0x00000000 (RESERVED)
gpiobase+0x0070: 0x00000000 (RESERVED)
gpiobase+0x0074: 0x00000000 (RESERVED)
gpiobase+0x0078: 0x00000000 (RESERVED)
gpiobase+0x007c: 0x00000000 (RESERVED)
Change-Id: Ic77474c4bc0871e95103ddecd9f6a9406c8f016d
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3000
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Put the ASL snippet for inclusion in the DSDT under the `acpi/`
folder as it is done for the other Super I/O devices.
$ find src/superio/ -name *asl
src/superio/ite/it8772f/acpi/superio.asl
src/superio/smsc/mec1308/acpi/superio.asl
src/superio/smsc/sio1007/acpi/superio.asl
src/superio/winbond/w83627hf/devtree.asl
As there are no users of this file yet, no other adaptations need
to be made.
Change-Id: Id10cd8897592b780c9fd3bd6b45ada4cf1fcf33e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2937
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c:64:12: warning: unused variable 'dev' [-Wunused-variable]
[…]
Removing the variable `dev` addresses the warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f229abccc95ff411f28d91b9b796ab74
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I83f4630cb6ab1e4c95d04b4e8423850ed1858e45
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2965
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c: In function 'smp_write_config_table':
src/mainboard/asrock/e350m1/mptable.c:58:3: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f229abccc95ff411f28d91b9b796ab74
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I7912571fa57f6512b10fc9b5845427fcb6eb50c0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mainboard.ramstage.o
src/mainboard/asrock/e350m1/mainboard.c: In function 'mainboard_enable':
src/mainboard/asrock/e350m1/mainboard.c:63:2: warning: implicit declaration of function 'pm_iowrite' [-Wimplicit-function-declaration]
[…]
This warning was introduced by moving the initialization of the
ASF registers using `pm_iowrite` to `mainboard.c` in
commit db6c5bfd8bdef4489e7fec533cb2ca8ae6c24cf3
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Thu Mar 21 22:21:28 2013 +0100
Asrock E350M1: Use SPD read code from F14 wrapper
Reviewed-on: http://review.coreboot.org/2875
and is fixed by including `southbridge/amd/cimx/cimx_util.h`
declaring `pm_iowrite`.
Note, that the other AMD SB800 based boards seem to use the
header file `southbridge/amd/sb800/sb800.h`, so no warning is shown
for those. But since the CIMx SB800 code is used, the routines
from the CIMx directory are more appropriate to declare these functions.
So delete the commented out include line for this header too.
Change-Id: I179aad5157c5a91294339a3e7b6c4c1715c6f099
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2957
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds the power management register definitions for Intel's Cougar
Point and Panther Point platform controller hubs (PCH). The definitions
are actually a subset of the older ICH10R registers: I've added just
those that are mentioned in the public specifications in [1] and [2].
I've tested dumping with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: Ia6945fe96cd96b568ed5191e91dbba5556e1ee95
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2985
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Auto-select marking the graphics memory as write-combining.
Change-Id: Icf61c5cbd129a97a106f0aaeca4e010d4799b4b8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2981
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Auto-select marking the graphics memory as write-combining.
Change-Id: I0b913f0b318bf57275643d3cfb5bc54ca8a005f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2982
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The pci device code was probing and loading the option rom before
it did the S3 resume check for VGA option roms. Instead move this
check before probing and loading so that we don't unnecessarily
do work.
Change-Id: If2e62d0c0e4b34b4f1bcd56ebcb9d3f54c6d0d24
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2979
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
It makes much more sense to use CONFIG_USE_OPTION_TABLE instead
of CONFIG_HAVE_CMOS_DEFAULT. As we want to read the used
debug_level from our CMOS. This change makes it possible to
change log_debug via nvramtool and make use of the new
value after a reboot/poweroff.
CONFIG_HAVE_CMOS_DEFAULT does have an other meaning
Change-Id: I438dd01a2b4171dba2b73f2001511c71f4317725
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
When calculating the offsets of the various binary blobs within the
coreboot.rom file, we noticed that using mawk as the awk tool instead
of using gawk led to build issues. This was finally traced to the
maximum value of the unsigned long variables within mawk - 0x7fff_ffff.
Because we were doing calculations on values up in the 0xffxxxxxx
range, these numbers would either be turned into floating point values
and printed using scientific notation, or truncated at 0x7fff_ffff.
To fix this, we print the values out as floating point, with no decimal
digits. This works in gawk, mawk, and original-awk and as the testing
below show, seems to be the best way to do this.
printf %u 0xFFFFFFFF | awk '{printf("%.0f %u %d", $1 , $1 , $1 )}'
mawk: 4294967295 2147483647 2147483647
original-awk: 4294967295 2147483648 4294967295
gawk: 4294967295 4294967295 4294967295
The issue of %d not matching gawk and original-awk has been reported
to ubuntu.
In the future, I'd recommend that whenever awk is used, a format is
specified. It doesn't seem that we can count on the representation
being the same between the different versions.
Change-Id: I7b6b821c8ab13ad11f72e674ac726a98e8678710
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2628
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reclaims space in ACPI NVS by removing unused fields and
adds new fields for SerialIO BARs which will be used to communicate
the allocated resources to ACPI.
Change-Id: I002bf396cf7b495bc5b7e54b741527e507aff716
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2969
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This enables the TPM device in ACPI tables so the OS is able
to probe for the TPM without needing it be force loaded.
Change-Id: I21e660ac1c12e3e1341cf266cf8f0bf03763df5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2968
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This imports the newest cache and MMU code from coreboot. This
time it's so new that it hasn't even been checked in to coreboot.
However, this version at least allows DMA to work properly for the
MSHC driver. So even if we rebase a few more times, this version is
at least a step in the right direction.
Note: This omits the stuff that sets up dcache policy since
libpayload should not need to worry about that and it depends
on cbmem stuff.
Change-Id: Idd42b083e8019634aaaa44d5bf5b51db6c3912f5
Signed-off-by: David Hendricks <dhendrix@google.com>
Reviewed-on: http://review.coreboot.org/2975
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This imports the new cache maintenance API from coreboot at
commit bba8090. This is a BSD-licensed implementation which
exposes cache maintenance opertaions necessary for payloads
for things such as DMA transfers.
Change-Id: I554676db89517bebc6edae4f7ab7e5882e6f986d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2974
Tested-by: build bot (Jenkins)
|
|
There is a wildcard rule to include mainboard/fadt.c.
Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2940
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds the PCI IDs of Intel's Cougar Point and Panther Point platform
controller hubs (PCH) to the dumping of the root complex configuration
under the root complex base address (RCBA). Those PCHs are handled exactly
as the older ICHs which can be seen in [1] and [2]. I've tested dumping
with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I2296caae57e614171300362d41715deecec77762
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2986
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Unfortunately, an unneeded mainboard specific `pmio.h` was created
when merging the AMD Parmer and Thatcher ports.
Rudolf used the header from a more generic location
southbridge/amd/agesa/hudson/hudson.h
doing the the ASUS F2A85-M port, but did not delete the `pmio.h`
now unused `pmio.h` header file.
So adapt AMD Parmer and Thatcher to use the Hudson one as done for
the ASUS F2A85-M and delete the now unused mainboard specific header
file `pmio.h` to avoid duplication.
Change-Id: I961cd145ebc3b83e31c638ac453ac95ee19c18db
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2958
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/irq_tables.ramstage.o
src/mainboard/asrock/e350m1/irq_tables.c: In function 'write_pirq_routing_table':
src/mainboard/asrock/e350m1/irq_tables.c:64:2: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration]
[…]
Including the header file `cpu/amd/amdfam14.h` declaring the
function addresses this warning.
The same change was done in the following commit for the
AMD Persimmon board.
commit d7a696d0f229abccc95ff411f28d91b9b796ab74
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I40b5735feb7116961ca0c4d6940ec55cdf42d3c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2956
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
`agesawrapper_amdinitlate`
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/get_bus_conf.ramstage.o
src/mainboard/asrock/e350m1/get_bus_conf.c: In function 'get_bus_conf':
src/mainboard/asrock/e350m1/get_bus_conf.c:82:3: warning: implicit declaration of function 'agesawrapper_amdinitlate' [-Wimplicit-function-declaration]
[…]
Including the header file `agesawrapper.h` declaring the function
`agesawrapper_amdinitlate` fixes this warning.
All AMD Family 14 based boards already include that header file. For
example for the board AMD Persimmon the following patch fixed this
warning.
commit d7a696d0f229abccc95ff411f28d91b9b796ab74
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
Change-Id: I695420b7071e07cb7d4667b2479b9a26ea13723d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2955
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/PlatformGnbPcie.romstage.o
CC mainboard/asrock/e350m1/agesawrapper.romstage.o
CC mainboard/asrock/e350m1/buildOpts.romstage.o
src/mainboard/asrock/e350m1/PlatformGnbPcie.c: In function 'OemCustomizeInitEarly':
src/mainboard/asrock/e350m1/PlatformGnbPcie.c:131:5: warning: 'return' with a value, in function returning void [enabled by default]
[…]
The function signature is (the return type might not be part of this though [1]),
VOID
OemCustomizeInitEarly (
IN OUT AMD_EARLY_PARAMS *InitEarly
)
so do not return anything.
All other AMD Family 14 boards already have the correct code. For example
following commit fixed this for AMD Persimmon.
commit d7a696d0f229abccc95ff411f28d91b9b796ab74
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Reviewed-on: http://review.coreboot.org/137
[1] http://cboard.cprogramming.com/cplusplus-programming/117286-what-exactly-function-signature.html
Change-Id: Ie60246bd9bb8452efd096e6838d8610f6364a6aa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2954
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Use register-sized types in case the inline assembler doesn't do
so automatically.
Change-Id: I3202ba972ef2548323fe557f45dc4b0b1cf6c818
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2983
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
dcache_mmu_disable() no longer needs to have its own iterative loop
to select each cache level of cache since
dcache_clean_invalidate_all() does that now.
Change-Id: I5ca273f98943981b943c1c1622f4574d7133fb50
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2967
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This adds a call to explicitly configure L2 cache (though defaults
should be set correctly).
Change-Id: I120e29c986918c2904a0332e46fcf9f1c5380d85
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2950
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This adds a new function to configure L2 cache for the
exynos5250 and deprecates the old function.
Change-Id: I9562f3301aa1e2911dae3856ab57bb6beec2e224
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2949
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: build bot (Jenkins)
|
|
In the following commit
commit ee5c111755ac4acc6dfb6e10a4e271211e149a39
Author: Paul Menzel <paulepanter@users.sourceforge.net>
Date: Tue Mar 12 12:41:40 2013 +0100
AMD CIMx SB800: Enable AHCI mode for SATA controller by default
Reviewed-on: http://review.coreboot.org/2661
I forgot to update the help texts to the new SATA mode default. Do
so now.
Additionally note that help texts for `choice` do not seem to be
shown.
Change-Id: I17f401633a2136efca2b21a621482e0724ff9f04
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2936
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This way for example a different compiler can easily be used.
CC=clang make
Change-Id: I50b83554fd4826d00d87e60a30eb1f6a88834397
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2935
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This moves the dsb() before the loop to sync any outstanding memory
accesses, and adds an isb() after the loop to ensure all outstanding
instructions are completed.
Change-Id: I1a11b39f104ae780370cfd2db3badcf4e91dc017
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2929
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The WTM2 board has a fairly static configuration. As such
it's been tested to properly handle CACHE_ROM given the number
of MTRRs the boards' CPUs supports.
Change-Id: Ic67cd1eebce580003dc6b6655cac2b2a92dd1b5f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2964
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Now that the AMD Inagua builds without any warnigs, remove the
config option `WARNINGS_ARE_ERRORS` set to no by default from
the file `Kconfig` so warnings are treated as errors to prevent
code from being added in the future introducing warnings.
Change-Id: I0b58bd74b06dc54d180b16d6a207354b5fea0d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2953
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Building the AMD Inagua board, the following warning is thrown.
CC mainboard/amd/inagua/get_bus_conf.ramstage.o
src/mainboard/amd/inagua/broadcom.c:319:6: warning: no previous prototype for 'broadcom_init' [-Wmissing-prototypes]
This warning was introduced by commit 3926b4c5.
commit 3926b4c520e74da9dc22e3d136a8a178483e0d25
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Fri Mar 1 19:41:41 2013 +0100
AMD Inagua: add GEC firmware, document Broadcom BCM57xx Selfboot Patch format
Reviewed-on: http://review.coreboot.org/2831
Adding the prototype to `broadcom.c` and removing it from
`mainboard.c` fixes the warning.
Change-Id: I1da0c4e972e129047dd8230d573f1c43fd71eb20
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2952
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds the GPIO register definitions for Intel's Cougar Point and
Panther Point platform controller hubs (PCH). All information is taken
from the public specifications in [1] and [2]. I've tested it with an
H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I31711e24f852e68b3c113e3bd9243dc7e89ac197
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2961
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds correspondings #defines for the PCI IDs of the LPC device on
Intel's Cougar Point and Panther Point platform controller hubs. Those
will be used more in later commits.
I've checked all those IDs against the specification updates [1] and [2].
[1] Intel 6 Series Chipset and Intel C200 Series Chipset Specification
Update
Document-Number: 324646-019
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH)
Family - Datasheet Specification Update
Document-Number: 326777-010
Change-Id: Ibef5a30d283c568c345eb8d8149723e7a3049272
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2960
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Automatically select CACHE_ROM for all Google boards.
Tested by generating a config for the link board. CACHE_ROM
was selected and was unable to unselect it using
'make oldconfig'.
Change-Id: I8e34207e3929a020bb0280657f95ba7a000ad024
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2963
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There is an optimization that can take place when hole
carving in ranges above 4GiB. If the range is the last
range then there is no need to carve UC holes out from
the larger WB range.
This optimization also has the same assumption of choosing
WB as the default MTRR type: the OS needs to properly
handle accessing realloacted MMIO resources with PAT so
that the MTRR type can be overidden.
Below are results using a combination of options. The
board this was tested on has 10 variable MTRRs at its
disposal. It has 4GiB of RAM.
IO hole config #1: hole starts at 0xad800000
No CACHE_ROM and no WRCOMB resources (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x0000000100000000 size 0x52800000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 4/6.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
No CACHE_ROM and 1 WRCOMB resource (takes 6 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 6/7.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
CACHE_ROM and no WRCOMB resources (takes 7 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000ff800000 size 0x52000000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 11/7.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6
MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6
MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 5 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 6 base 0x0000000100000000 mask 0x0000007f00000000 type 6
CACHE_ROM and 1 WRCOMB resource (takes 8 MTRRs):
Previously this combination was impossible without the optimization.
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 12/8.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6
MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6
MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 5 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 6 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 7 base 0x0000000100000000 mask 0x0000007f00000000 type 6
IO hole config #1: hole starts at 0x80000000
No CACHE_ROM and no WRCOMB resources (takes 1 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x0000000100000000 size 0x80000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 1/2.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000080000000 mask 0x0000007f80000000 type 0
No CACHE_ROM and 1 WRCOMB resource (takes 3 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 4/3.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 2 base 0x0000000100000000 mask 0x0000007f00000000 type 6
CACHE_ROM and no WRCOMB resources (takes 3 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000ff800000 size 0x7f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 9/3.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x0000000100000000 mask 0x0000007f00000000 type 6
CACHE_ROM and 1 WRCOMB resource (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 10/4.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 2 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 3 base 0x0000000100000000 mask 0x0000007f00000000 type 6
Change-Id: Ia3195af686c3f0603b21f713cfb2d9075eb02806
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2959
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some ranges would use less variable MTRRs if an UC area
can be carved off the top of larger WB range. Implement this
approach by doing 3 passes over each region in the addres space:
1. UC default type. Cover non-UC and non-WB regions with respectie type.
Punch UC hole at upper end of larger WB regions with WB type.
2. UC default type. Cover non-UC regions with respective type.
3. WB default type. Cover non-WB regions with respective type.
The hole at upper end of a region uses the same min alignment of 64MiB.
Below are results using a combination of options. The board this was
tested on has 10 variable MTRRs at its disposal. It has 4GiB of RAM.
IO hole config #1: hole starts at 0xad800000
No CACHE_ROM or WRCOMB resources (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x0000000100000000 size 0x52800000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 4/9.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
No CACHE_ROM. 1 WRCOMB resource (takes 6 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 6/10.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
CACHE_ROM and no WRCOMB resources (taks 10 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000ff800000 size 0x52000000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
MTRR: default type WB/UC MTRR counts: 11/10.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6
MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6
MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 5 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 6 base 0x0000000100000000 mask 0x0000007fc0000000 type 6
MTRR: 7 base 0x0000000140000000 mask 0x0000007ff0000000 type 6
Taking a reserved OS MTRR.
MTRR: 8 base 0x000000014f600000 mask 0x0000007fffe00000 type 0
Taking a reserved OS MTRR.
MTRR: 9 base 0x000000014f800000 mask 0x0000007fff800000 type 0
A combination of CACHE_ROM and WRCOMB just won't work.
IO hole config #2: hole starts at 0x80000000:
No CACHE_ROM or WRCOMB resources (takes 1 MTRR):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x0000000100000000 size 0x80000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 1/5.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000080000000 mask 0x0000007f80000000 type 0
No CACHE_ROM. 1 WRCOMB resource (takes 4 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 4/6.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000080000000 mask 0x0000007fc0000000 type 0
MTRR: 1 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 2 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 3 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
CACHE_ROM and no WRCOMB resources (takes 6 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000ff800000 size 0x7f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 9/6.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x0000000100000000 mask 0x0000007f80000000 type 6
MTRR: 3 base 0x000000017ce00000 mask 0x0000007fffe00000 type 0
MTRR: 4 base 0x000000017d000000 mask 0x0000007fff000000 type 0
MTRR: 5 base 0x000000017e000000 mask 0x0000007ffe000000 type 0
CACHE_ROM and 1 WRCOMB resource (takes 7 MTRRs):
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0
0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
MTRR: default type WB/UC MTRR counts: 10/7.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 2 base 0x00000000ff800000 mask 0x0000007fff800000 type 0
MTRR: 3 base 0x0000000100000000 mask 0x0000007f80000000 type 6
MTRR: 4 base 0x000000017ce00000 mask 0x0000007fffe00000 type 0
MTRR: 5 base 0x000000017d000000 mask 0x0000007fff000000 type 0
MTRR: 6 base 0x000000017e000000 mask 0x0000007ffe000000 type 0
Change-Id: Iceb9b64991accf558caae2e7b0205951e9bcde44
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2925
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Two convenience functions are added to operate on a range_entry:
- range_entry_update_tag() - update the entry's tag
- memranges_next_entry() - get the next entry after the one provide
These functions will be used by a follow on patch to the MTRR code
to allow hole punching in WB region when the default MTRR type is
UC.
Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2924
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It's not appropriate for the chromeos Kconfig to automatically
select CACHE_ROM. The reason is that enabling CACHE_ROM is
dependent on the board and chipset atrributes.
Change-Id: I47429f1cceefd40226c4b943215d627a3c869c7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2921
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
