| Age | Commit message (Collapse) | Author |
|---|
|
This just updates existing guard name comments on the header files
to match the actual #define name.
As a side effect, if there was no newline at the end of these files,
one was added.
Change-Id: Ia2cd8057f2b1ceb0fa1b946e85e0c16a327a04d7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12900
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead
check to make sure they're defined and not zero. In some cases, zero
might be a valid value, but it didn't look like zero was valid in these
cases.
Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10886
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BRANCH=none
BUG=None
TEST=Build and run on strago
Change-Id: Ia3740353eb16f2a2192cad8c45645f845bf39475
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10588
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I782007fe9754ec3ae0b5dc31e7865f7e46cfbc74
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10576
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I8e694f37c8709efd702208aa005096ebf1f3abb5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10356
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
SMM_TSEG now implies SMM_MODULES and SMM_MODULES can't be used without SMM_TSEG
Remove some newly dead code while on it.
Change-Id: I2e1818245170b1e0abbd853bedf856cec83b92f2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10355
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I534f992ed479c7cdc049bd598259b1f1cf2953b9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10354
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Most Baytrail based devices MMIO registers are reported in ACPI
space and the device's PCI config space is disabled. The PCI config
space is required for many "legacy" OSs that don't have the ACPI
driver loading mechanism. Depthcharge signals the legacy boot
path via the SMI 0xCC and the coreboot SMI handler can switch the
device specific registers to re-enable PCI config space.
BUG=chrome-os-partner:30836
BRANCH=None
TEST=Build and boot Rambi SeaBIOS.
Change-Id: I87248936e2a7e026f38c147bdf0df378e605e370
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: dbb9205ee22ffce44e965be51ae0bc62d4ca5dd4
Original-Change-Id: Ia5e54f4330eda10a01ce3de5aa4d86779d6e1bf9
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219801
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Original-Tested-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/9459
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I682617cd2f4310d3e2e2ab6ffec51def28a4779c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7961
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Because we had no stack on romcc boards, we had a separate, not as
powerful clone of printk: print_*. Back in the day, like more than
half a decade ago, we migrated a lot of boards to printk, but we never
cleaned up the existing code to be consistent. instead, we worked around
the problem with a very messy console.h (nowadays the mess is hidden in
romstage_console.c and early_print.h)
This patch cleans up the cpu code to use printk() on all non-ROMCC
boards.
Change-Id: I233c53300f9a74bce4b828fc4074501a77f7b593
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8114
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
|
|
Cherry-pick from chromium and adjusted for added boards
and changed directory layout for arch/arm.
Timestamp implementation for ARMv7
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Original-Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Original-Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Original-Reviewed-on: https://gerrit.chromium.org/gerrit/63793
(cherry-picked from commit cc1a75e059020a39146e25b9198b0d58aa03924c)
Change-Id: Ic51fb78ddd05ba81906d9c3b35043fa14fbbed75
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8020
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
We relocate GDT to CBMEM, this can be done late in ramstage.
Note: We currently do this for BSP CPU only.
Change-Id: I626faaf22f846433f25ca2253d6a2a5230f50b6b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7858
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Change-Id: I8486e70615f4c404a342cb86963b5357a934c41d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7606
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Placement of romstage stack in RAM was vulnerable for getting corrupted
by decompressed ramstage.
Change-Id: Ic032bd3e69f4ab8dab8e5932df39fab70aa3e769
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7096
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Add the CPU files required to support the Steppe Eagle and Mullins
models of Family 16h SoC processors from AMD. This CPU is based on
the Jaguar core and is similar to Kabini.
Change-Id: Ib48a3f03128f99a1242fe8c157e0e98feb53b1ea
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6679
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
|
|
Continuing on from the rational given in:
a173a62 Remove guarding #includes by CONFIG_FOO combinations
Change-Id: I35c636ee7c0b106323b3e4b90629f7262750f8bd
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6114
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It was never well-defined what value this function should return.
Change-Id: If84aff86e0b556591d7ad557842910a2dfcd3b46
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6166
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Change-Id: If92b50ab3888518228d2d3b76f5c50c4aef968dd
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4561
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
With the recent improvement 3d6ffe76f8a505c2dff5d5c6146da3d63dad6e82,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
In order for the cpu code to start SMM relocation 2 new
functions are added to be shared:
- void smm_initiate_relocation_parallel()
- void smm_initiate_relocation()
The both initiate an SMI on the currently running cpu.
The 2 variants allow for parallel relocation or serialized
relocation.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi using these functions.
Change-Id: I325777bac27e9a0efc3f54f7223c38310604c5a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173982
Reviewed-on: http://review.coreboot.org/4891
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The Bay Trail SMM save state revision is 0x0100.
Add support for this save state area using the
type named em64t100_smm_state_save_area_t.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted using this structure with forthcoming CLs.
Change-Id: Iddd9498ab9fffcd865dae062526bda2ffcdccbce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173981
Reviewed-on: http://review.coreboot.org/4890
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
Reviewed-on: http://review.coreboot.org/4888
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The access to control registers were scattered about.
Provide a single header file to provide the correct
access function and definitions.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted using this infrastructure. Also objdump'd the
assembly to ensure consistency (objdump -d -r -S | grep xmm).
Change-Id: Iff7a043e4e5ba930a6a77f968f1fcc14784214e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172641
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4873
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Romstage and ramstage can use 2 different values for the
amount of ROM to cache just under 4GiB in the address
space. Don't assume a cpu's romstage caching policy
for the ROM.
Change-Id: I689fdf4d1f78e9556b0bc258e05c7b9bb99c48e1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4846
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The tsc header is using u32 w/o including the file
with defines it.
Change-Id: I9fcad882d25e93b4c0032b32abd2432b0169a068
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4843
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
GRUB2-as-payload doesn't use them. Libpayload can live with just coreboot tables
if loaded as payload. memtest86+ can use them but is buggy with them. Solaris
needs a huge boot archive not supported by coreboot and too big to fit in
flash (dozens of megabytes). All-in-all looks like no users are left for this.
Change-Id: Id92f73be5a397db80f5b0132ee57c37ee6eeb563
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4628
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be
set with values that are not power of 2. The region programmed
as WB cacheable will include all of ROM_SIZE.
Side-effects to consider:
Memory region below flash may be tagged WRPROT cacheable. As an
example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB.
Since this can overlap CAR, we add an explicit test and fail
on compile should this happen. To work around this problem, one
needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and
define a smaller region for WB cache.
With this change flash regions outside CBFS are also tagged WRPROT
cacheable. This covers IFD and ME and sections ChromeOS may use.
Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4625
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Change-Id: I5f4bf9dbaf3470dc83d3e980bb6cab10801e15c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4523
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
This commit adds a new Kconfig option for the LynxPoint
southbridge that will have coreboot route all of the USB
ports to the XHCI controller in the finalize step (i.e.
after the bootloader) and disable the EHCI controller(s).
Additionally when doing this the XHCI USB3 ports need
to be put into an expected state on resume in order to make
the kernel state machine happy.
Part of this could also be done in depthcharge but there
are also some resume-time steps required so it makes sense
to keep it all together in coreboot.
This can theoretically save ~100mW at runtime.
Verify that the EHCI controller is not found in Linux and
that booting from USB still works.
Change-Id: I3ddfecc0ab12a4302e6034ea8d13ccd8ea2a655d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63802
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4407
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
With the LynxPoint chipset there are more than 16
possible GPIOs that can trigger an SMI so we need
a mainboard handler that can support this.
There are only a handful of users of this function
so just change them all to use the new prototype.
Change-Id: I3d96da0397d6584f713fcf6003054b25c1c92939
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49530
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4145
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
and add an ARMv7 version.
Change-Id: I14fbff88d7c2b003dde57a19bf0ba9640d322156
Signed-off-by: Stefan Reinauer <reinauer@google.com>
[km: rebased fa004acf8 from chromium git]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3939
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
If romstage does not make cbmem_initialize() call, linker should
optimize the code for CAR migration away.
This simplifies design of CBMEM console by a considerable amount.
As console buffer is now migrated within cbmem_initialize() call there
is no longer need for cbmemc_reinit() call made at end of romstage.
Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3916
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
ROMCC boards were left unmodified.
Change-Id: I3d842196b3f5b6999b6891b914036e9ffcc3cef0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3853
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: Iadc813bc8208278996b2b1aa20cfb156ec06fac9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3755
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
multiply_to_tsc was being copied everywhere, which is bad
practice. Put it in the tsc.h include file where it belongs.
Delete the copies of it.
Per secunet, no copyright notice is needed.
This might be a good time to get a copyright notice into tsc.h
anyway.
Change-Id: Ied0013ad4b1a9e5e2b330614bb867fd806f9a407
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3242
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This continues the work done in patch 6b908d08ab
http://review.coreboot.org/#/c/1685/
and makes the early x86 post codes follow the same options.
Change-Id: Idf0c17b27b3516e79a9a53048bc203245f7c18ff
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The smm_handler_t type was added before the introduction
of the asmlinkage macro. Now that asmlinkage is available
use it.
Change-Id: I85ec72cf958bf4b77513a85faf6d300c781af603
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3215
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Some boards use the local apic for udelay(), but they also provide
their own implementation of udelay() for SMM. The reason for using
the local apic for udelay() in ramstage is to not have to pay the
penalty of calibrating the TSC frequency. Therefore provide a
TSC_CONSTANT_RATE option to indicate that TSC calibration is not
needed. Instead rely on the presence of a tsc_freq_mhz() function
provided by the cpu/board. Additionally, assume that if
TSC_CONSTANT_RATE is selected the udelay() function in SMM will
be the tsc.
Change-Id: I1629c2fbe3431772b4e80495160584fb6f599e9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
Downstream payloads may need to take advantage of caching the
ROM for performance reasons. Add the ability to communicate the
variable range MTRR index to use to perform the caching enablement.
An example usage implementation would be to obtain the variable MTRR
index that covers the ROM from the coreboot tables. Then one would
disable caching and change the MTRR type from uncacheable to
write-protect and enable caching. The opposite sequence is required
to tearn down the caching.
Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2919
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The CONFIG_CACHE_ROM support in the MTRR code allocates an MTRR
specifically for setting up write-protect cachine of the ROM. It is
assumed that CONFIG_ROM_SIZE is the size of the ROM and the whole
area should be cached just under 4GiB. If enabled, the MTRR code
will allocate but not enable rom caching. It is up to the callers
of the MTRR code to explicitly enable (and disable afterwards) through
the use of 2 new functions:
- x86_mtrr_enable_rom_caching()
- x86_mtrr_disable_rom_caching()
Additionally, the CACHE_ROM option is exposed to the config menu so
that it is not just selected by the chipset or board. The reasoning
is that through a multitude of options CACHE_ROM may not be appropriate
for enabling.
Change-Id: I4483df850f442bdcef969ffeaf7608ed70b88085
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2918
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The old MTRR code had issues using too many variable
MTRRs depending on the physical address space layout dictated
by the device resources. This new implementation calculates
the default MTRR type by comparing the number of variable MTRRs
used for each type. This avoids the need for IORESOURE_UMA_FB
because in many of those situations setting the default type to WB
frees up the variable MTTRs to set that space to UC.
Additionally, it removes the need for IORESOURCE_IGNORE_MTRR
becuase the new mtrr uses the memrange library which does merging
of resources.
Lastly, the sandybridge gma has its speedup optimization removed
for the graphics memory by writing a pre-determined MTRR index.
That will be fixed in an upcoming patch once write-combining support
is added to the resources.
Slight differences from previous MTRR code:
- The number of reserved OS MTRRs is not a hard limit. It's now advisory
as PAT can be used by the OS to setup the regions to the caching
policy desired.
- The memory types are calculated once by the first CPU to run the code.
After that all other CPUs use that value.
- CONFIG_CACHE_ROM support was dropped. It will be added back in its own
change.
A pathological case that was previously fixed by changing vendor code
to adjust the IO hole location looked like the following:
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
As noted by the output below it's impossible to accomodate those
ranges even with 10 variable MTRRS. However, because the code
can select WB as the default MTRR type it can be done in 6 MTRRs:
MTRR: default type WB/UC MTRR counts: 6/14.
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
Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2889
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The amd_mtrr.c file contains a copy of the fixed MTRR algorithm.
However, the AMD code needs to handle the RdMem and WrMem attribute
bits in the fixed MTRR MSRs. Instead of duplicating the code
with the one slight change introduce a Kconfig option,
X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields
need to be handled for writeback fixed MTRR ranges.
The order of how the AMD MTRR setup routine is maintained by providing
a x86_setup_fixed_mtrrs_no_enable() function which does not enable
the fixed MTRRs after setting them up. All Kconfig files which had a
Makefile that included amd/mtrr in the subdirs-y now have a default
X86_AMD_FIXED_MTRRS selection. There may be some overlap with the
agesa and socket code, but I didn't know the best way to tease out
the interdependency.
Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2866
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Some of the functions called from assembly assume the standard
x86 32-bit ABI of passing all arguments on the stack. However,
that calling ABI can be changed by compiler flags. In order to
protect against the current implicit calling convention annotate
the functions called from assembly with the cdecl function
attribute. That tells the compiler to use the stack based parameter
calling convention.
Change-Id: I83625e1f92c6821a664b191b6ce1250977cf037a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2794
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The Link native graphics commit 49428d84 [1]
Add support for Google's Chromebook Pixel
was missing some of the higher level bits, and hence could not be
used. This is not new code -- it has been working since last
August -- so the effort now is to get it into the tree and structure
it in a way compatible with upstream coreboot.
1. Add options to src/device/Kconfig to enable native graphics.
2. Export the MTRR function for setting variable MTRRs.
3. Clean up some of the comments and white space.
While I realize that the product name is Pixel, the mainboard in the
coreboot tree is called Link, and that name is what we will use
in our commits.
[1] http://review.coreboot.org/2482
Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2531
Tested-by: build bot (Jenkins)
|
|
Currently the OS is free to use the memory located at the default
SMRAM space because it is not marked reserved in the e820. This can
lead to memory corruption on S3 resume because SMM setup doesn't save
this range before using it to relocate SMRAM.
Resulting tables:
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000002ffff: RAM
2. 0000000000030000-000000000003ffff: RESERVED
3. 0000000000040000-000000000009ffff: RAM
4. 00000000000a0000-00000000000fffff: RESERVED
5. 0000000000100000-0000000000efffff: RAM
6. 0000000000f00000-0000000000ffffff: RESERVED
7. 0000000001000000-00000000acebffff: RAM
8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES
9. 00000000ad000000-00000000af9fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 00000000fed10000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-000000018f5fffff: RAM
e820 map has 13 items:
0: 0000000000000000 - 0000000000030000 = 1 RAM
1: 0000000000030000 - 0000000000040000 = 2 RESERVED
2: 0000000000040000 - 000000000009f400 = 1 RAM
3: 000000000009f400 - 00000000000a0000 = 2 RESERVED
4: 00000000000f0000 - 0000000000100000 = 2 RESERVED
5: 0000000000100000 - 0000000000f00000 = 1 RAM
6: 0000000000f00000 - 0000000001000000 = 2 RESERVED
7: 0000000001000000 - 00000000acec0000 = 1 RAM
8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED
9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED
10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED
11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED
12: 0000000100000000 - 000000018f600000 = 1 RAM
Booted and checked e820 as well as coreboot table information.
Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2688
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add support for SMM modules by leveraging the RMODULE lib. This allows
for easier dynamic SMM handler placement. The SMM module support
consists of a common stub which puts the executing CPU into protected
mode and calls into a pre-defined handler. This stub can then be used
for SMM relocation as well as the real SMM handler. For the relocation
one can call back into coreboot ramstage code to perform relocation in
C code.
The handler is essentially a copy of smihandler.c, but it drops the TSEG
differences. It also doesn't rely on the SMM revision as the cpu code
should know what processor it is supported.
Ideally the CONFIG_SMM_TSEG option could be removed once the existing
users of that option transitioned away from tseg_relocate() and
smi_get_tseg_base().
The generic SMI callbacks are now not marked as weak in the
declaration so that there aren't unlinked references. The handler
has default implementations of the generic SMI callbacks which are
marked as weak. If an external compilation module has a strong symbol
the linker will use that instead of the link one.
Additionally, the parameters to the generic callbacks are dropped as
they don't seem to be used directly. The SMM runtime can provide the
necessary support if needed.
Change-Id: I1e2fed71a40b2eb03197697d29e9c4b246e3b25e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2693
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
According to both Haswell and the SandyBridge/Ivybridge
BWGs the save state area actually starts at 0x7c00 offset
from 0x8000. Update the em64t101_smm_state_save_area_t
structure and introduce a define for the offset.
Note: I have no idea what eptp is. It's just listed in the
haswell BWG. The offsets should not be changed.
Change-Id: I38d1d1469e30628a83f10b188ab2fe53d5a50e5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2515
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
e.g.
-#if CONFIG_LOGICAL_CPUS == 1
+#if CONFIG_LOGICAL_CPUS
This will make it easier to switch over to use the config_enabled()
macro later on.
Change-Id: I0bcf223669318a7b1105534087c7675a74c1dd8a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Using global variables with the TSEG is a bad idea because
they are not relocated properly right now. Instead make
the variables static and add accessor functions for the
rest of SMM to use.
At the same time drop the tcg/smi1 pointers as they are
not setup or ever used. (the debug output is added back
in a subsequent commit)
Change-Id: If0b2d47df4e482ead71bf713c1ef748da840073b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1764
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The CPU can arbitrarily reorder calls to rdtsc, significantly
reducing the precision of timing using the CPUs time stamp counter.
Unfortunately the method of synchronizing rdtsc is different
on AMD and Intel CPUs. There is a generic method, using the cpuid
instruction, but that uses up a lot of registers, and is very slow.
Hence, use the correct lfence/mfence instructions (for CPUs that
we know support it)
Change-Id: I17ecb48d283f38f23148c13159aceda704c64ea5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1422
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This reverts commit 042c1461fb777e583e5de48edf9326e47ee5595f.
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This function is exported so it can be used in other
places that need similar relocation due to TSEG.
Change-Id: I68b78ca32d58d1a414965404e38d71977c3da347
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1310
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are enough differences that it is worth defining the
proper map for the sandybridge/ivybridge CPUs. The state
save map was not being addressed properly for TSEG and
needs to use the right offset instead of pointing in ASEG.
To do this properly add a required southbridge export to
return the TSEG base and use that where appropriate.
Change-Id: Idad153ed6c07d2633cb3d53eddd433a3df490834
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1309
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
CACHE_ROM_SIZE default is ROM_SIZE, the Flash device size set
in menuconfig. This fixes a case where 8 MB SPI flash MTRR setup
would not cover the bottom 4 MB when ramstage is decompressed.
Verify CACHE_ROM_SIZE is power of two.
One may set CACHE_ROM_SIZE==0 to disable this cache.
Change-Id: Ib2b4ea528a092b96ff954894e60406d64f250783
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1146
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
|
|
The current code for initializing AP cpus has several shortcomings:
- it assumes APIC IDs are sequential
- it uses only the BSP for determining the AP count, which is bad if
there's more than one physical CPU, and CPUs are of different type
Note that the new code call cpu->ops->init() in parallel, and therefore
some CPU code needs to be changed to address that. One example are old
Intel HT enabled CPUs which can't do microcode update in parallel.
Change-Id: Ic48a1ebab6a7c52aa76765f497268af09fa38c25
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Replace #if CONFIG_FOO==1 with #if CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*1[[:space:]]*\$,#if \1," {} +
Replace #if (CONFIG_FOO==1) with #if CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*1)[[:space:]]*\$,#if \1," {} +
Replace #if CONFIG_FOO==0 with #if !CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*0[[:space:]]*\$,#if \!\1," {} +
Replace #if (CONFIG_FOO==0) with #if !CONFIG_FOO:
find src -name \*.[ch] -exec sed -i "s,#if[[:space:]]*(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]*0)[[:space:]]*\$,#if \!\1," {} +
(and some manual changes to fix false positives)
Change-Id: Iac6ca7605a5f99885258cf1a9a2473a92de27c42
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1004
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Martin Roth <martin@se-eng.com>
|
|
rename from mainboard_apm_cnt to mainboard_smi_apmc to match the function
naming scheme of the other handlers. Add prototype for mainboard_smi_sleep
(mainboard specific S3 sleep handlers in SMM) that is required by Sandybridge.
Change-Id: Ib479397e460e33772d90d9d41dba267e4e7e3008
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/933
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Instead of opaque numbers like (1<<29), use
symbols like CR0_NoWriteThrough.
Change-Id: Id845e087fb472cfaf5f71beaf37fbf0d407880b5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/833
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Traditionally coreboot's SMM handler runs in ASEG (0xa0000),
"behind" the graphics memory. This approach has two issues:
- It limits the possible size of the SMM handler (and the
number of CPUs supported in a system)
- It's not considered a supported path anymore in newer CPUs.
Change-Id: I9f2877e46873ab2ea8f1157ead4bc644a50be19e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Acked-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/842
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
|
|
This affects the algorithm when determining when to
transform a range into a larger range with a hole.
It is needed when for when I switch on an 8MB TSEG
and cause the memory maps to go crazy.
Also add header defines for the SMRR.
Change-Id: I1a06ccc28ef139cc79f655a8b19fd3533aca0401
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I05f1cbd33f0cb7d80ec90c636d1607774b4a74ef
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The cbmem console structure and car global data are put in their own section,
with the cbmem console coming after the global data. These areas are linked
to be where CAR is available and at the very bottom of the stack.
There is one shortcoming of this change:
The section created by this change needs to be stripped out by the Makefile
since leaving it in confuses cbfstool when it installs the stage in the image.
I would like to make the tools link those symbols at the right location but
leave allocation of that space out of the ELF.
Change-Id: Iccfb99b128d59c5b7d6164796d21ba46d2a674e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/727
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
clang doesn't know about the side effect, so we have to tell it
that it's okay not to care about the result.
Change-Id: Ib11890bff6779e36cf09c178d224695ea16a8ae8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/783
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We used several names for that same value, and hardcoded the value
at some more places.
They're all LOCAL_APIC_ADDR now (except for lapic specific code
that still uses LAPIC_DEFAULT_BASE).
Change-Id: I1d4be73b1984f22b7e84681edfadf0588a7589b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current code uses static values for the physical address size
supported by a CPU. This isn't always the right value: I.e. on
model_6[ef]x Core (2) Duo CPUs physical address size is 36, while
Xeons from the same family have 38 bits, which results in invalid
MTRR setup. Fix this by getting the right number from CPUID.
Change-Id: If019c3d9147c3b86357f0ef0d9fda94d49d811ca
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/529
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ib91889a374515d36a2b12b53aeb12b6ea6e22732
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/364
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The base is now calculated automatically, and all mentions of that
config option were typical anyway (4GB - XIP_ROM_SIZE).
Change-Id: Icdf908dc043719f3810f7b5b85ad9938f362ea40
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/366
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
That value is now generated from a code address and CONFIG_XIP_ROM_SIZE.
This works as MTRRs are fully specified by their size and any address
within the range.
Change-Id: Id35d34eaf3be37f59cd2a968e3327d333ba71a34
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/348
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Move the SMM MSR init to a code run per CPU. Introduce global SMM_BASE define,
later all 0xa0000 could be changed to use it. Remove the unnecessary test if
the smm_init routine is called once (it is called by BSP only) and also remove
if lock bit is set becuase this bit is cleared by INIT it seems.
Add the defines for fam10h and famfh to respective files, we do not have any
shared AMD MSR header file.
Tested on M2V-MX SE with dualcore CPU.
Change-Id: I1b2bf157d1cc79c566c9089689a9bfd9310f5683
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/82
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I002845cf7a37cd6885456131826ae0ba681823ef
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/64
Tested-by: build bot (Jenkins)
|
|
Overwriting the SMM Area on resume leaves us with
all variables cleared out, i.e., the GNVS pointer
is no longer available, which makes SMIF function
calls impossible.
Change-Id: I08ab4ffd41df0922d63c017822de1f89a3ff254d
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/34
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
in the current code, the defines for the APM_CNT (0xb2) register
are duplicated in almost every place where it is used. define those
values in cpu/x86/smm.h, and only include this file.
And while at it, fixup whitespace.
Change-Id: Iae712aff53322acd51e89986c2abf4c794e25484
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/4
Tested-by: build bot (Jenkins)
|
|
motherboards can use this hook to get notified if someone writes
to the APM_CNT port (0xb2). If the hook returns 1, the chipset
specific hook is also skipped.
Change-Id: I05f1a27cebf9d25db8064f2adfd2a0f5759e48b5
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/3
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6536 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6535 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6487 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
http://www.coreboot.org/pipermail/coreboot/2007-September/024665.html
It's about time we follow this advice.
Also move some manually set __PRE_RAM__ defines (ap_romstage.c) to the Makefile and
drop unused CPP define
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6482 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
have this go away again.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Kevin O'Connor <kevin@koconnor.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6273 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
cache that range instead of the first 1Meg. This reduces boot time by
about 1 second on epia-cn.
This patch also adds a MTRRphysMaskValid bit definition.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6272 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6201 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
-- When building for UMA, reduce the limit for DRAM below 4GB
from E0000000 to C0000000. This is needed to accomodate the
UMA frame buffer.
-- Correct problem where msr C0010010 bits 21 and 22 (MtrrTom2En
and Tom2ForceMemTypeWB) are not set consistently across cores.
-- Enable TOM2 only if DRAM is present above 4GB.
-- Use AMD Tom2ForceMemTypeWB feature to avoid the need for
variable MTRR ranges above 4GB.
-- Add above4gb flag argument to function x86_setup_var_mtrrs. Clearing
this flag causes x86_setup_var_mtrrs() to omit MTRR ranges for
DRAM above 4GB. AMD systems use this option to conserve MTRRs.
-- Northbridge.c change to deduct UMA memory from DRAM size reported
by ram_resource. This corrects a problem where mtrr.c generates an
unexpected variable MTRR range.
-- Correct problem causing build failure when CONFIG_GFXUMA=1 and
CONFIG_VAR_MTRR_HOLE=0.
-- Reserve the UMA DRAM range for AMD K8 as is already done for AMD
family 10h.
Tested with mahogany on ECS A780G-GM with 2GB and 4GB.
Tested with mahogany_fam10 on ECS A780G-GM with 2GB and 4GB.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6067 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
This makes the CAR implementations a lot more readable, shorter and
easier to follow, and also reduces the amount of uselessly duplicated code.
For example there are more than 12 open-coded "enable cache" instances
spread all over the place (and 12 "disable cache" ones), multiple
"enable mtrr", "save BIST", "restore BIST", etc. etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5902 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
- Use some more #defines instead of hard-coding values.
- Merge multiple movl/orl or movl/andl lines into one where possible.
- Add some TODOs in places which seem to have either an incorrect
code or incorrect comment.
- Fix typos: s/for/from/, s/BSC/BSP/, s/size/carsize/.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5890 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
The fill_processor_name() function was duplicated in multiple
model_*_init.c files, move it into a new src/cpu/x86/name
directory.
The strcpy() function was also duplicated multiple times, move it
to <string.h> where we already have similar functions.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5879 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Root cause: After function STOP_CAR_AND_CPU disables cache as
ram, the cache as ram stack can no longer be used. Called
functions must be inlined to avoid stack usage. Also, the
compiler must keep local variables register based and not
allocated them from the stack. With gcc 4.5.0, some functions
declared as inline are not being inlined. This patch forces
these functions to always be inlined by adding the qualifier
__attribute__((always_inline)) to their declaration.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5818 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Juhana Helovuo <juhe@iki.fi>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5806 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5756 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
