This is a minor set of changes to get DDR3 going.
Move compilation of DDR3 startup to the romstage. Fix a prototype that
was missing a void. Remove a function that is overly flexible, and
even though it is overly flexible only actually can handle one type of
RAM. Mainboards only support one type of DRAM, so create a function
to explicitly initialize the type of DDR we have -- DDR3.
With these changes, and the previous changes, google snow is ready to run
the ramstage.
Change-Id: I37e0ab0d2dbc1dd121fb175386a46bc2fb1285e5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The SPI flash driver for Exynos chipset.
Verified to boot on snow/armv7.
Change-Id: I7eef67a9c57f825d09f13ea44c2b59b54345fa7b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2229
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
At some point we did a lot of cleanup to replace bare 'unsigned'
with 'unsigned int'. Do that work for this imported code as well.
At some point, we may find we can shrink these 'int's to something
smaller, thought I very much doubt it's worth the trouble.
Change-Id: Ic3da491c0188c56c836f8b9c4c8f26a31b4b3573
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2223
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It can be handy to have debug prints as DRAM is started up, so that
in the case of failure (does that ever happen?) you've got some
idea where it failed.
This patch adds some DEBUG_SPEW prints to the DDR3 code. I am doing this
as its own CL because we may find we want to revert it. That's unlikely
but it is not impossible if we skew the timing in some way.
This code works for some trivial DRAM tests.
Change-Id: I57e8d2a2d8df6b8ec8cd0d414681fc513e9999e3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2222
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The timing array is crucial to proper operation of DRAM.
Getting a valid pointer to it is hence very important. Unfortunately,
the constants chosen for the vendor were '1', and '2', (this in a
32-bit word) which in a debug print makes it almost impossible to tell
if you've got a misaligned pointer. Note: coreboot people did not
choose them :-)
So, give them values which are extremely unlikely to occur elsewhere
in the array (or in memory, for that matter).
Given the frequency with which this check occurs, i.e. once, I would
much prefer strings but I expect I'd get shouted down on that
one. Constants in this case are an almost useless optimization but
we'll go with them for now. Note no space is saved by not using
strings: there's an entire function somewhere devoted to mapping the
enum to a string!
Debug prints of pointers to structs in this array are now far more
useful than they were.
See snarky comment in the code (left there to make sure nobody gets
tempted to get fancy again). Comment now less snarky.
This is tested on google snow to the point that the DRAM works.
Change-Id: I30bc44719f321f791fd82ded60e29393399d9e3d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2221
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
The previous incarnation did not use all of mmu_setup, which meant
we did not carefully disable things before (possibly) changing them.
This code is tested and works, and it's a bit of a simplification.
Change-Id: I0560f9b8e25f31cd90e34304d6ec987fc5c87699
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2204
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
This begins to remove references to global data which u-boot used.
There are still many commented out references to gd-> and bd-> which
we'll fix once we're happy with the replacements.
Change-Id: Ie1b40a997e28a118f8f3ad96a2f9a2462d32fbe3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2210
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
`depends on FOO` in
if FOO
... depends on FOO
endif
is useless.
Introduced in
commit 4b508341bc
Author: efdesign98 <efdesign98@gmail.com>
Date: Wed Jul 13 17:16:13 2011 -0700
Add AMD Family 10 support to cpu folder
and probably copied later on in the following commit.
commit d3e990c6e5
Author: Kerry Sheh <shekairui@gmail.com>
Date: Tue Feb 7 20:31:35 2012 +0800
AGESA F15: AGESA family15 model 00-0fh cpu wrapper
Change-Id: I67cf231e3047a07cb6f0eeb5f77be368674a0603
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2186
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Hengelein <ilendir@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch does a few things to get us into romstage:
- Add romstage as a stage (a later patch adds it as a binary, which
is probably wrong). The Makefile magic is complex enough that we
let it build the XIP file for now, but we no longer use it.
- Replace findstage with loadstage. Loadstage will find a stage,
load the code to memory, and zero the remaining part of memory.
Now we can link the romstage to go anywhere!
- Eliminate magic offsets from code/ldscripts and centralize Kconfig
variables in src/cpu/samsung/exynos5250/Kconfig.
- Tidy up code and serial output
Change-Id: Iae4d2f9e7f429cb1df15d49daf9a08b88d75d79d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2174
Tested-by: build bot (Jenkins)
This is the bloated Snow bootblock which includes:
- SPI driver
- UART, including requisite I2C, Maxim PMIC, and clock config code.
- Adjustments for magic offsets (id section, stack pointer address)
This is just a temporary solution until we have romstage loading.
Once that happens, we'll rip out all but the code necessary for
copying SPI ROM content into SRAM.
Change-Id: I2a11e272eb9b6f626b5d9783eabb4a720a1d06be
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a stub for bootblock_cpu_init() for exynos5250. It will
eventually contain code to copy ROM content from SPI to SRAM.
Change-Id: I26ee62a1e701013f38f76f200579faa680530860
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2138
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This lays out the groundwork for using a proper bootblock on ARM.
Currently we bypass the bootblock entirely and go straight to
romstage. However we want to utilize CBFS to maximize flexibility
of placing code without relying on a lot of magic numbers which
will break depending on the SoC in use.
Change-Id: I9cc2a8191d2db38b27b6363ba673e5a360de9684
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the first lowlevel init routine that gets called in romstage.
It's fugly and needs a lot of clean-up, but does the job for now.
Change-Id: Id54bf4f1c3753bcbed5f6b5eeb4b48bc3b41ce93
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2133
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This cannot be used until we get the BL1 mess sorted out.
Change-Id: I2490addb31256e27caa89ebb5b1501296e6903bd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2132
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The high bits of mtrr mask are MBZ (Must be zero). Writing 1 to these
bits will cause exception. So be carefull when spread this change.
The supermicro/h8scm needs more work. Currently it is set as it was.
We need to check if the F10 and F15 have different value.
Change-Id: I2dd8bf07ecee2fe4d1721cec6b21623556e68947
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1661
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
We don't pass arguments when we jump out of assembly code.
Change-Id: Iccf3a6f713e260b08f9ff47e8b542b9e96369166
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2122
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This does some clean-up for the exynos5250 clock_init.c:
- No global data.
- Remove some unused #includes
- Hard-code the memory type for Elpida DRAM. This will need to be
fixed eventually (or the system will be unstable), but is good
enough for early bring-up and until we finish other re-factoring.
Change-Id: Icd2cf8ba35058cbd1131666db311dfb77ef1a160
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2127
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Turns out initializing power rails is necessary, even for getting
serial output.
Change-Id: I3042c1001ae43b1e793ee6cb90bb79b8db0f8fd1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2126
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We moved to using __ASSEMBLER__ years ago since it is set by as.
Change-Id: I60103ba23ebe87be1d0bc63beed0ef5b05eed4f2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2111
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This just cleans out some unused headers and tidies up the early
serial code.
TODO: Clean-up or replace FDT code, make "base_port" easier to
configure.
A bit of cleanup based on earlier patches.
Change-Id: Ie77ee6d4935346e0053c09252055662f1a45d5f5
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2084
Tested-by: build bot (Jenkins)
This patch makes pre-RAM serial init more generic, particularly for
platforms which do not necessarily need cache-as-RAM in order to use
the serial console and do not have a standard 8250 serial port.
This adds a Kconfig variable to set romstage-* for very early serial
console init. The current method assumes that cache-as-RAM should
enable this, so to maintain compatibility selecting CACHE_AS_RAM will
also select EARLY_SERIAL_CONSOLE.
The UART code structure needs some rework, but the use of ROMCC,
romstage, and then ramstage makes things complex.
uart.h now includes all .h files for all uarts. All 2 of them.
This is actually a simplifying change.
Change-Id: I089e7af633c227baf3c06c685f005e9d0e4b38ce
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2086
Tested-by: build bot (Jenkins)
This patch does two things which will take effect in follow-up
patches:
1. Add an intermediate Makefile rule for dd'ing BL1 into the
coreboot.rom pre-image. This is modeled after a similar hack
for the bd82x6x southbridge.
2. Add a Kconfig variable, BOOTBLOCK_OFFSET, which will be used to
pass the bootblock offset into cbfstool.
Change-Id: I89da255dc903c387b754b06a11bb3439035ead87
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2093
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are needed for communicating with the PMIC on Snow. We'll
tidy them up as we go along...
Change-Id: I197f59927eae0ad66191862d052de2a8873fb22f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2078
Tested-by: build bot (Jenkins)
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This imports SPL (second phase loader) files from U-Boot. Most of the
content of these files will eventually go away since they're fairly
U-Boot specific. For now they are here to make Jenkins happy.
Change-Id: Ib3a365ecb9dc304b20f7c1c06665aad2c0c53e69
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2081
Tested-by: build bot (Jenkins)
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Since these don't seem very generic and depend on the BL1, let's
move them to the CPU-specific Kconfig.
Change-Id: I33059b7db30d35a1853918a580f312e50a3499fa
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2077
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SB800 and Hudson now support adding the IMC ROM which runs from the same
chip as coreboot. When the IMC is running, write or erase commands sent to
the spi bus will fail, and the IMC will die. To fix this, we send a request
to the IMC to stop fetching from the SPI rom while we write to it. This
process (in one form or another) is required for writes to the SPI bus while
the IMC is running.
Because the IMC can take up to 500ms to respond every time we claim the
bus, this patch tries to keep the number of times we need to do that to a
minimum. We only need to claim the bus on writes, and using a counter for
the semaphore allows us to call in once to claim the bus at the beginning
of a number of transactions and it will stay claimed until we release it
at the end of the transactions.
Claim() - takes up to 500ms hit
claim() - no delay
erase()
release()
claim() - no delay
write()
release()
Release()
Change-Id: I4e003c5122a2ed47abce57ab8b92dee6aa4713ed
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1976
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... to fit into the naming convention
Change-Id: I4a7d81c4d6674d001fc831df863bd2343f6c636f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2020
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
When we need i2c for this cpu we will use the coreboot
smbus code.
Change-Id: I4ba4cc9ae10e5ca830d621ee9c8d9f7bd2129e2f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2019
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The max include file is in src/drivers/power.
Change-Id: I2e663b472cade17fc50edbb449c0e54fd4a991eb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2017
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This file builds fine without including arch/types.h
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: Icd38cf429576a2a1a33ebca84389526feddfc169
Reviewed-on: http://review.coreboot.org/2015
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Samsung SoC files, including Exynos5 (a Cortex-A15
implementation). Since this is an SoC we'll forego the x86-style
{north,south}bridge and cpu distinction. We may try to split some
stuff out before the final version if prudent.
Change-Id: Ie068e9dc3dd836c83d90e282b10d5202e7a4ba9b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2005
Tested-by: build bot (Jenkins)
Instead of adding regparm(0) to each assembler function called
by coreboot, add an asmlinkage macro (like the Linux kernel does)
that can be different per architecture (and that is empty on ARM
right now)
Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1973
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are from u-boot but have been cleaned up somewhat to remove
references to linux include files.
Change-Id: I5fe3954a11d8c4aa792620ef5e1a5ee8932b8578
Signed-off-by: Hung-Ti Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1930
Tested-by: build bot (Jenkins)
Remove the old, unflexible code for storing S3 data in SPI flash.
Refer to flashrom. Tested on Parmer.
Change-Id: I60a10476befb4afab2b4241f01a988f4a8bb22cd
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1920
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
With these changes we have a mostly compiling target.
I'm still removing and pruning .h files, but hopefully later today I'll do
the last few .h commits and move on to .c
Change-Id: Ia82d787496184e028f37d7b67336d61fda75aa94
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1937
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As we move to supporting other systems we need to get rid of assembly
where we can. The log2 function in src/lib is identical to the assembly
one (tested for all 32-bit signed integers :-) and takes about 10 ns
to run as opposed to 5ns for the non-portable assembly version. While speed
is good, I think we can spare the 15 ns or so we add to boot time
by using the C version only.
Change-Id: Icafa565eae282c85fa5fc01b3bd1f110cd9aaa91
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1928
Tested-by: build bot (Jenkins)
Change-Id: I48497adc29a1b8ca11d1e0a5d879cab5b6b55dcd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1926
Tested-by: build bot (Jenkins)
Per a conversation with Stefan, these chip-dependent files are moved
to the src tree, in the manner of other chips (north and southbridge).
Change-Id: I12645ba05eb241eda200ed06cb633541a6a98119
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Reviewed-on: http://review.coreboot.org/1925
Tested-by: build bot (Jenkins)
This gets rid of the somewhat unstructured placement of AMD's
sysinfo structure in CAR.
We used to carve out some CAR space using a Kconfig variable,
and then put sysinfo there manually (by "virtue" of pointer magic).
Now it's a variable with the CAR_GLOBAL qualifier, and build
system magic.
For this, the following steps were done (but must happen together
since the intermediates won't build):
- Add new CAR_GLOBAL sysinfo_car
- point all sysinfo pointers to sysinfo_car instead of GLOBAL_VAR
- remove DCACHE_RAM_GLOBAL_VAR_SIZE
- from CAR setup (no need to reserve the space)
- commented out code (that was commented out for years)
- only copy sizeof(sysinfo) into RAM after ram init, where
before it copied the whole GLOBAL_VAR area.
- from Kconfig
Change-Id: I3cbcccd883ca6751326c8e32afde2eb0c91229ed
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add support for ICH9 southbridge
Change-Id: I70612431101bf48d9dcc96ee1b37d257c9ad2ee2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
This unused code was not silently dropped as before.
Change-Id: Ic76c58e233869a60c3a8a27c2efc2182b3a4442d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1863
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Agesa wrapper and UDELAY_TIMER2 define their own timer functions,
so don't shove in UDELAY_IO
Change-Id: Ibe3345e825e0c074d5f531dba1198cd6e7b0a42d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1864
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- move VGA handling options into devices/Kconfig
- make Devices a top level menu
- move some options "closer" to the code they control
Change-Id: Ia79541d18b2b0d9b89a8b154255e312060627c48
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1840
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Updating microcode on several threads in a core at once
can be harmful. Hence add a spinlock to make sure that
does not happen.
Change-Id: I0c9526b6194202ae7ab5c66361fe04ce137372cc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1778
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Several small improvements of the stack checking code:
- move the CPU0 stack check right before jumping to the payload
and out of hardwaremain (that file is too crowded anyways)
- fix prototype in lib.h
- print size of used stack
- use checkstack function both on CPU0 and CPU1-x
- print amount of stack used per core
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Test: Boot coreboot on Link, see the following output:
...
CPU1: stack: 00156000 - 00157000, lowest used address 00156c68,
stack used: 920 bytes
CPU2: stack: 00155000 - 00156000, lowest used address 00155c68,
stack used: 920 bytes
CPU3: stack: 00154000 - 00155000, lowest used address 00154c68,
stack used: 920 bytes
...
Jumping to boot code at 1110008
CPU0: stack: 00157000 - 00158000, lowest used address 00157af8,
stack used: 1288 bytes
Change-Id: I7b83eeee0186559a0a62daa12e3f7782990fd2df
Reviewed-on: http://review.coreboot.org/1787
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- drop changelog and add license header instead
- 80+ character fixes
- make stacks array static because it's not used externally
- rename copy_secondary_start_to_1m_below()
Change-Id: I8b461bea21ee0ddd85ea3a3a923d1e15167f54f0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1821
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This addition is in support of future multicore support in
coreboot. It also will allow us to remove some asssembly code.
The CPU "index" -- i.e., its order in the sequence in which
cores are brought up, NOT its APIC id -- is passed into the
secondary start. We modify the function to specify regparm(0).
We also take this opportunity to do some cleanup:
indexes become unsigned ints, not unsigned longs, for example.
Build and boot on a multicore system, with pcserial enabled.
Capture the output. Observe that the messages
Initializing CPU #0
Initializing CPU #1
Initializing CPU #2
Initializing CPU #3
appear exactly as they do prior to this change.
Change-Id: I5854d8d957c414f75fdd63fb017d2249330f955d
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1820
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
There are some function dependancies that didn't work
when MAX_CPU was set to 1 and the build would fail.
Change-Id: I033a42056f7b48a40316e03772ed89ad9cb013fe
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1819
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This change allows us to figure out how much of the AP stacks we are
using, as well as to catch any case of an AP overrunning its stack.
Also, the stack is poisoned, which is a good way to catch programming
errors -- code should never count on auto variables being zerod.
The stack bases are recorded in a new array, stacks. At the end,
when all APs are initialized, the stacks are walked and the
lowest level of the stack that is reached is printed.
Build and boot and look for output like this:
CPU1: stack allocated from 00148000 to 00148ff4:\
lowest stack address was 00148c4c
CPU2: stack allocated from 00147000 to 00147ff4:\
lowest stack address was 00147c4c
CPU3: stack allocated from 00146000 to 00146ff4:\
lowest stack address was 00146c4c
Note that we used only about 1K of stack, even though in this
case we allocated 4K (and in the main branch, we allocate 32K!)
Change-Id: I99b7b9086848496feb3ecd207f64203fa69fadf5
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1818
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Adding an entry for 0x306a0 will make sure that all
CPUs with CPUIDs 0x306aX will execute the driver (analog to
Sandybridge behavior)
Change-Id: I0353f3a48ecfd41274fdf6ee302c7d34482f1b5b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1783
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Applied function attribute to function definition to avoid 'conflicting type' warning.
Function declaration is in src/include/cpu.h
void secondary_cpu_init(unsigned int cpu_index)__attribute__((regparm(0)));
But function definition in lapic_cpu_init.c is missing the "__attribute__" part.
Change-Id: Idb7cd00fda5a2d486893f9866920929c685d266e
Signed-off-by: Han Shen <shenhan@google.com>
Reviewed-on: http://review.coreboot.org/1784
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The VMX MSR may come up with random values and needs to be
initialized to zero. This was done incorrectly in finalize_smm.
It must be done on a per core basis in the general CPU init.
This touches all Sandybridge and Ivybridge configs.
Change-Id: I015352d0f8e2ebe55ac0a5e9c5bbff83bd2ff86b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MSR for VMX can start with a random value and needs to be
cleared by coreboot. I am reverting this change, as
it handles almost everything and doing a follow-on change to fix
the improper clearing of the MSR.
Change-Id: Ibad7a27b03f199241c52c1ebdd2b6d4e81a18a4e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1793
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The reporting of cores and threads in the system was a bit
ambiguous. This patch makes it clearer.
Change-Id: Ia05838a53f696fbaf78a1762fc6f4bf348d4ff0e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1786
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To allow easy experimentation with thermals, leave power control
registers unlocked.
Change-Id: Ia53065f3f220c2faed58e7d53e60c3f169ae58ec
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://review.coreboot.org/1688
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
All of these capabilities exist on all CPUs supported on
this socket.
Change-Id: I54f34e48e34bb6ab5b9954ab7ece8c2c3a1a8e67
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1664
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds proper support for turbo and super-low-frequency modes.
Calculation of the p-states has been rewritten and moved into an
extra file speedstep.c so it can be used for non-acpi stuff like
EMTTM table generation.
It has been tested with a Core2Duo T9400 (Penryn) and a Core Duo T2300
(Yonah) processor.
Change-Id: I5f7104fc921ba67d85794254f11d486b6688ecec
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
add this code according to src/include/cpu/x86/cache.h ,line 92,
functin enable_cache()
Change-Id: Ida96a98397eeed98dd61ca979e8c5a33bf00f9e5
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1662
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
We parsed the MSR the wrong way, and didn't support some valid values.
Change-Id: Ia42e3de05dd76b6830aaa310ec82031d36def3a0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We had only some MSR definitions in there, which are used in speedstep
related code. I think speedstep.h is the better and less confusing place
for these.
Change-Id: I1eddea72c1e2d3b2f651468b08b3c6f88b713149
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Also deletes files not included in build:
src/southbridge/amd/cimx/sb700/chip_name.c
src/southbridge/amd/cimx/sb800/chip_name.c
src/southbridge/amd/cimx/sb900/chip_name.c
Change-Id: I2068e3859157b758ccea0ca91fa47d09a8639361
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1473
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Currently the C32 has some legacy boards which use the old C32 code. We need to seperate them.
CONFIG_CPU_AMD_SOCKET_C32 was used in legacy code before.
But it is not a good idea, so we change the code as follows:
So we use CONFIG_CPU_AMD_SOCKET_C32 to identify mainboard which uses agesa code,
and use CONFIG_CPU_AMD_SOCKET_C32_NON_AGESA to identify mainboard which uses legacy code.
Change-Id: If6114bf8912e78b7732f25a1adfb2e4d8eb10ee4
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1497
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Add code to do the following for the VIA Nano CPUs
- Update microcode
- Set maximum frequency
- Initialize power states
- Set up cache
Attempting to change the voltage or frequency of the CPU without
applying the microcode update will hang the CPU, so we only do
transitions if we can verify the microcode has been updated.
The microcode is updated directly from CBFS. No microcode is
included in ramstage. The microcode is not included in this
commit.
To get the microcode, run bios_extract on the manufacturer supplied
BIOS, and look for the file marked "P6 Microcode". Include this
file in CBFS.
You can have the build system include this file automatically by
selecting Expert Mode, then look under
'Chipset' -> 'Include CPU microcode in CBFS' ->
Include external microcode file (check)
'Path and filename of CPU microcode' should contain the location of
the microcode file previously extracted.
Change-Id: I586aaca5715e047b42ef901d66772ace0e6b655e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1257
Tested-by: build bot (Jenkins)
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are hyper-threading Atom CPUs, those would not enable L2
cache with model_6ex CAR code. Switch to code that can handle
different number of threads and cores.
Change-Id: I57328c231f8998f45f7b0d26c63b24585f8476dd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1384
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: James Laird <jhl@mafipulation.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The name is derived directly from the device path.
Change-Id: If2053d14f0e38a5ee0159b47a66d45ff3dff649a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The search loop for UMA resource was only used to check for the highest
RAM address below 4GB. The cached values from BSP CPU can now be used
for the replication.
Change-Id: I5244ffa6f8a93f5ff5aaf8a71bd006b0f9cd518a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1388
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Take a copy of BSP CPU's TOP_MEM and TOP_MEM2 MSRs to be distributed
to AP CPUs and factor out the debugging info from setup_uma_memory().
Change-Id: I1acb4eaa3fe118aee223df1ebff997289f5d3a56
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1387
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@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)
The function is a noop for all but amd/serengeti_cheetah.
Change-Id: I09e2e710aa964c2f31e35fcea4f14856cc1e1dca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1184
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Detection for a hyper-threading CPU was not compatible with multicore
CPUs. When using CPUID eax==4, also need to set ecx=0.
CAR init tested on real hardware with hyper-threading model_f25 and
under qemu 0.15.1 with multicore CPU.
Change-Id: I28ac8790f94652e4ba8ff88fe7812c812f967608
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1172
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reserved memory resources will get removed from memory table at
the end of write_coreboot_table(),
Change-Id: I02711b4be4f25054bd3361295d8d4dc996b2eb3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1372
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This reverts commit 042c1461fb.
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 reverts commit 78efc4c36c.
The broadcast patch was reverted, so this commit should also
be reverted. The reason for reverting the broadcast patch:
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: I05c27dec55fa681f455215be56dcbc5f22808193
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1380
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The default TCC activation offset is 0, which means TCC
activation starts at Tj_max. For devices with limited
cooling ability it may be desired to lower TCC activation.
This adds an option that can be declared in the devicetree
to set the TCC activation to a non-zero value.
Enable tcc_offset=15 in devicetree.cb and build/boot
the BIOS and check that the value is set in the MSR:
> and $(shr $(rdmsr 0 0x1a2) 24) 0xf
0xf
Change-Id: I88f6857b40fd354f70fa9d5d9c1d8ceaea6dfcd1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1343
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Split this behavior out from PNOT() so the OS can
update _PPC limit without re-reading C-state tables.
Change-Id: I81b9111a4866f6b9916f74ac57a3caefaa77c565
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1342
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing NVS variable for PPCM will be used to
select a dynamic max P-state.
By itself this does not change existing behavior because
the NVS PPCM variable is initialized to zero.
PPCM can be tested by building and booting a modified BIOS
that sets gnvs->ppcm to a value greater than 1 and checking
from the OS that the P-state is limited to that value.
Change-Id: Ia7b3bbc6b84c1aa42349bb236abee5cc92486561
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EHCI debug allows to send message with 8 bytes length, but
we're only sending one byte in each transaction. Buffer up
to 8 bytes to speed up debug output.
Change-Id: I9dbb406833c4966c3afbd610e1b13a8fa3d62f39
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1357
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
On SandyBridge systems configured to work with Panther Point the CPU
would wrongly be described as IvyBridge. Fix this issue and drop an
unneeded Kconfig variable at the same time.
Change-Id: I501a4fa00613e589cd315cfee61b2f9561dfcb4d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1335
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When fixing the SMM state table for SandyBridge/IvyBridge CPUs
the wrong table was used for older 64bit capable CPUs.
Change-Id: Ia7dff21aa3f0e5aa61575634fc839777de6bef10
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1353
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On both SandyBridge and IvyBridge BCLK is fixed at 100MHz. Have the
comment reflect that.
Change-Id: Ia81c3501dc3e68cf3143c3bc864dfbf88901f9f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
.. in case the system has pluggable CPUs or might come in different SKUs.
Change-Id: I7a7cd95b4de5dd78370355f448688e8d000434c1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Date and time are mixed up:
microcode: updated to revision 0x12 date=2012-12-04
should be
microcode: updated to revision 0x12 date=2012-04-12
Change-Id: I85f9100f31d88bb831bef07131f361c92c7ef34e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1334
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The LAPIC timer is running at BCLK (100MHz) on Sandy Bridge and Ivy
Bridge systems. However, the current timer code assumed that the clock
would run at 200MHz instead. This made all delays twice as long as
needed.
Change-Id: I41b1186daee11cfd9a25b3a9d5ebdeeb271293c7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1330
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
CPUs with configurable TDP will run the TSC at the max non-turbo
ratio for the maximum TDP value, which can cause issues if another
TDP is desired. To deal with this we set the flex ratio to the
nominal TDP ratio early in the boot and then configure the Soft
Reset Data registers so the PCH can tell the CPU what frequency
to run at after a reset.
This is done very early in the bootblock because it is necessary
to reset the system after setting a flex ratio.
The end result is that the TSC will now increment at the max
non-turbo frequency for the nominal TDP.
On some system with 1.8GHz CPU ensure that the kernel
detects the CPU speed as ~1800mhz rather than ~2300mhz:
> dmesg | grep "MHz processor"
[ 0.004000] Detected 1795.801 MHz processor.
Change-Id: I8436dced9199003b6423186a2b041e3f7b84ab8c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
In order to support SPI and ELOG drivers the SMM region
needs to be able to be larger than the previous allocation
below 0x7400. Now that we have support for 4M TSEG we do
not need to live in this region.
This change adds a 16KB heap region abofe the save state area
at TSEG+64KB and moves the C handler above this.
The heap region is then available for malloc and the C handler
can grow to support flash and event log features.
While updating the memory map comment in assembly stub I also
added a pause instruction to the cpu spin lock as this was
added to the C code in latest upstream rebase.
Dump sympbols from smm.elf binary to see the new regions:
00010000 B _heap
00014000 B _eheap
00014000 T _smm_c_handler_start
0001b240 T _smm_c_handler_end
Change-Id: I45f0ab4df1fdef3b626f877094a58587476ac634
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1308
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The BWG says ivybridge current limit for PP1 is 50A.
Verify the PP1 current limit value on link device:
> echo $(( ( $(rdmsr 0 0x602) & 0x1fff ) >> 3 ))
50
Change-Id: I946269d21ef605f2525fe03993f569d69128294b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1305
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Ivybridge B0+ CPUs are capable of supporting multiple TDP levels.
This complicates the default case because now the registers that
were reporting max non-turbo ratio are reporting that value for
the highest possible TDP level.
For now this change just forces everything to use the Nominal TDP
values instead of the higher (or lower) levels.
- When building P-state tables, determine the P[1] (max non turbo)
ratio based on the Nominal ratio if available.
- Set the turbo activation ratio to the Nominal max ratio.
- Mirror the power level settings in new MCHBAR register after
they are written, which happens after BIOS_RESET_CPL is set.
- Set the current ratio to Nominal ratio at boot.
1) Verify that P-state table is generated properly with
P[0]=1801MHz (ratio 0x1C) and P[1]=1800MHz (ratio 0x12)
PSS: 1801MHz power 17000 control 0x1c00 status 0x1c00
PSS: 1800MHz power 17000 control 0x1200 status 0x1200
2) Verify power limits in MCHBAR match PKG_POWER_LIMIT:
> rdmsr 0 0x610
0x800080aa00dc8088
> mmio_read32 0xfed159a4
0x000080aa
> mmio_read32 0xfed159a0
0x00dc8088
3) Verify turbo activation ratio is set to nominal ratio:
> rdmsr 0 0x64c
0x0000000000000012
4) Check that proper ratio was set at boot on one core only:
> grep 'frequency set to' /sys/firmware/log
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
Change-Id: I592e60a7740f31b140986a8269dca91b4adbb270
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1304
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and don't require it to specify a cache type.
This function is only used on romcc boards, and should go away
(because all boards should be switched to CAR)
Change-Id: Ic32ca3be1afffc773c72c140e88b338d48a0c8ca
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1288
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Nothing is yet enabled, this is just a config skeleton change.
The MICROCODE_INCLUDE_PATH definition is going to be used by the
Makefile building the microcode blob for CBFS inclusion.
Change-Id: I7868db3cfd4b181500e361706e5f4dc08ca1c87d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1292
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
When CONFIG_MICROCODE_IN_CBFS is enabled, find the microcode blob in
CBFS and pass it to intel_update_microcode() instead of using the
compiled in array.
CBFS accesses in pre-RAM and 'normal' environments are provided
through different API.
Change-Id: I35c1480edf87e550a7b88c4aadf079cf3ff86b5d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1296
Tested-by: build bot (Jenkins)
It's only used on AMD based boards. Hence drop it, so we don't
accidently start using it by mistake instead of MAX_CPUS
Change-Id: Id8f522f24283129874d56e70bd00df92abe9c3cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1325
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In preparation to support CBFS hosted microcode blobs, this change
renames the wrapper include file containing the microcode to be
independent of CPU model.
Change-Id: If1a4963a52e5037a3a3495b90708ffc08b23f4c1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1294
Tested-by: build bot (Jenkins)
Dump and disassemble ACPI tables and look in _CST.
In the last entry the state was getting set to 0:
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x01, // Bit Width
0x02, // Bit Offset
0x0000000000000030, // Address
0x01, // Access Size
)
},
0x00000000, // State
0x0000005A, // Latency
0x000000C8 // Power
}
Now it is properly identifed as state 3:
Package (0x04)
{
ResourceTemplate ()
{
Register (FFixedHW,
0x01, // Bit Width
0x02, // Bit Offset
0x0000000000000030, // Address
0x01, // Access Size
)
},
0x00000003, // State
0x0000005A, // Latency
0x000000C8 // Power
}
Change-Id: Ie0a68606c5a43ac5fb5ba7bb9a3fef933ad67b64
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1297
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
There are several reasons for this:
1. It's a core setting, not a platform setting, which is bizarre. But,
we disable vmx via an SMI, and that only happens on core 0.
Hence, the code did not correctly make the same settings on all cores-
one had them disabled, the others were in an unknown state.
When (e.g.) kvm started on a vmx-enabled core, then moved to a
vmx-disabled core, the processor would reset *very* quickly.
Changing this would be messy.
2. On the CPU on link, there is something about trying to set the lock
bit that is getting a GPF.
3. It's the wrong place and time to set it. Once controlled, they can't
be changed in the kernel. The kernel is what should control this
feature, not the BIOS, as we have learned time and time again. If
somebody is in as root and can start a VM, you have a lot more to
worry about than someone starting a guest virtual machine.
Change-Id: I4f36093f1b68207251584066ccb9a6bcfeec767e
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1276
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's not really useful anymore I guess, and it makes the log files
harder to read. Hence dropping it.
Change-Id: If4c3e8b40ae491ca527ef62f8145206960f6579d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1272
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to be able to use udelay in code running on AP cores
the timer has to be initialized on the according local APICs
or the system will just hang when udelay is used.
Change-Id: I776bc96aa6d876ff2582d0c05cbc9c7611cb06b5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1267
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Updated P state table to make frequency scaling work.
Added these CPUs: http://support.amd.com/us/Processor_TechDocs/30430.pdf
Also wrote a Python script for parsing AMD docs,
but not sure where to put it: http://pastebin.com/1dSvkXwc
Change-Id: I8f08111b73b9be551f3f59d2acb15051ccf36c1e
Signed-off-by: Jukka Rantala <jukka.rantala@gmail.com>
Reviewed-on: http://review.coreboot.org/1244
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Northbridge code incorrectly adjusted the last cacheable memory
resource to accomodate room for UMA framebuffer. If system had
4GB or more memory that last resource is not below 4GB and not
the one where UMA is located.
There are three consequences:
The last entry in coreboot memory table is reduced by uma_memory_size.
Due the incorrect code in northbridge code state.tomk,
end of last resource below 4GB, had not been adjusted.
Incrementing that by uma_memory_size diverts a region
possibly claimed for MMIO to RAM, as TOP_MEM is written.
Since the UMA framebuffer did not have IORESOURCE_CACHEABLE,
it was ignored from the MTRR setup and not set uncacheable.
The setting of TOP_MEM and TOP_MEM2, as well as all the MTRRs,
should be copied from BSP to all APs instead of deriving the data
separately for each Logical CPU.
Change-Id: I8e69fc8854b776fe9e4fe6ddfb101eba14888939
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1217
Tested-by: build bot (Jenkins)
Reviewed-by: Denis Carikli <GNUtoo@no-log.org>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Use state.tomk to refer TOP_MEM, largest RAM address below 4GB.
Use state.tom2k to refer TOP_MEM2, largest RAM address above 4GB.
When setting either TOP_MEM or TOP_MEM2, any RAM resource found
must fit below the set value. Thus, round register value upwards,
not downwards.
Change-Id: I436c1b3234c911680ce8b095052f8d71f40113e2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1216
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If northbridge called uma_resource() a resource of this type
should be found when walking the resources list.
For now, be rude and don't even try to combine it with
neighboring regions. As the type is un-cacheable it is
dominant over other MTRR setups claiming the same region.
Change-Id: I57805e7e7da0709f8ed78d8df62c2abf22172a06
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1215
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Use of the uma_memory_base and _size variables is very scattered.
Implementation of setup_uma_memory() will appear in each northbridge.
It should be possible to do this setup entirely in northbridge
code and get rid of the globals in a follow-up.
Change-Id: I07ccd98c55a6bcaa8294ad9704b88d7afb341456
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
All but one board use the default value of enabled. Disabling
this can only increase the number of MTRR registers used.
Change-Id: I7d28adc31b9fae2301e4ff78fcb96486f81d5ec2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1213
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are two errors in the code. The first one is a missing
$ sign in mov _stack, %esp. Thanks to Ronald G Minnich for
catching that bug.
The second bug is the 'incl %eax', which shouldn't be there, as
there's no secondary CPU with index 0. CPU0 uses always the stack
below _estack.
Change-Id: Id267a654ba95b0e898eeaaafb2403b438250a563
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1212
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The SIPI vector copy can use a static location below 1MB, aligned
to 4kB. Jump out of the copy once in protected mode.
Change-Id: I6299aa3448270663941cf2c4113efee74bcc7993
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1165
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
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>
Diff between model_106cx and model_6ex CAR codes suggests currently
used model_106cx CAR is not optimal - destination RAM and source ROM
of ramstage copy_and_run are only partly set cacheable.
It appears variable MTRR setting for XIP cache is left enabled on
model_106cx code, where it should have extended to cover all of Flash.
Introduces untested functional change on boards:
intel/d945gclf
iwave/iWRainbowG6
Deletes file:
model_106cx/cache_as_ram.inc
Change-Id: I35229f8433927e83821e72e9d9a9fc8fb09c3f1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/642
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
A diff from model_6fx to model_106cx suggests there is little
CORE2 specific code that was once considered useful to have.
In its current status however, sockets supporting model_6fx use
model_6ex CAR init, so that specific code is actually
never used.
Deletes file:
model_6fx/cache_as_ram.inc
Change-Id: I6c0204446fa98207e31f91895e1cf30fde42382c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/640
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Default CPU_ADDR_BITS is 36.
For Atom (model_106cx) use 32. This model is known to
fail execution-in-place (XIP) with the default 36.
Pentium M should use 32, but doesn't even with this patch.
Some Xeon and CORE(2) models should use 38 or 40.
Change-Id: If604badcdc578c4f4bc7d30da2f61397ec0d754c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/639
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
The wrapper for Trinity. Support S3. Parme is a example board.
Change-Id: Ib4f653b7562694177683e1e1ffdb27ea176aeaab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The new broadcast code doesn't support serial init - if a CPU
needs serial init, this should be handled in the model specific CPU
init code.
Change-Id: I7cafb0af10d712366819ad0849f9b93558e9d46a
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1140
Tested-by: build bot (Jenkins)
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>
Early HT-enabled CPUs do not serialize microcode updates within a core.
Solve this by running microcode updates on the thread with the smallest
lapic ID of a core only.
Also set MTRRs once per core only.
Change-Id: I6a3cc9ecec2d8e0caed29605a9b19ec35a817620
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1142
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Those CPUs support the PECI (Platform Environment Control
Interface), so enable it. This interface is commonly used
for tasks like fan control.
Change-Id: Id2dadc4821de8cc0b579e77235aa36892e57fd02
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1104
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
commit 5b6404e419 ("Fix timer frequency
detection on Sandybridge") reworked the udelay code, but didn't add
the 333MHz FSB entry used on Model 15 Xeons.
Change-Id: Ie34f9ae3703b64672625e7bf1b943654a7a5eaa6
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1099
Tested-by: build bot (Jenkins)
Without that fix the debugging is harder because the person debugging
coreboot will see the following twice(note the repeated MTRR number):
Setting variable MTRR 0, base: 0MB, range: 4096MB, type WB
[...]
Setting variable MTRR 1, base: 4096MB, range: 512MB, type WB
Setting variable MTRR 1, base: 4608MB, range: 256MB, type WB
Setting variable MTRR 1, base: 3072MB, range: 1024MB, type UC
instead of the following twice:
Setting variable MTRR 0, base: 0MB, range: 4096MB, type WB
[...]
Setting variable MTRR 1, base: 3072MB, range: 1024MB, type UC
Thanks to kmalkki on #coreboot's Freenode IRC channel for the idea:
May 25 23:57:17 <kmalkki> I would add (move) that "Setting variable MTRR..." debug at the end of set_var_mtrrs()
Change-Id: I9f4b7110ba34d017a58d8cc5fb06a7b1c3d0c8aa
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1058
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It's only used in the ACPI generator for Sandybridge/Ivybridge CPUs
and the code can easily be changed to not rely on any Kconfig magic.
Change-Id: Ie2f92edfe8908f7eb2fda3088f77ad22f491ddcf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1047
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Replace #elif (CONFIG_FOO==1) with #elif CONFIG_FOO
find src -type f -exec sed -i "s,\(#.*\)(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]1),\1\2,g" {} +
(manual tweak since it hit a false positive)
Replace #elif (CONFIG_FOO==0) with #elif !CONFIG_FOO
find src -type f -exec sed -i "s,\(#.*\)(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]0),\1\!\2,g" {} +
Change-Id: I8f4ebf609740dfc53e79d5f1e60f9446364bb07d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1006
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Another bug in the Intel microcode update code that existed since we switched
to LinuxBIOSv2 in 2004:
The inline assembly code that reads the CPU revision from an MSR after running
cpuid(1) trashes registers EBX and ECX. Only ECX was mentioned in the clobber
list. C code running after this function could silently access completely wrong
data, which resulted in the wrong date being printed on microcode updates (and
potentially other issues happening until the C code writes to EBX again)
Change-Id: Ida733fa1747565ec9824d3a37d08b1a73cd8355f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/996
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If microcode.c is built by romcc, this indicates that we are running
microcode updates in the bootblock (e.g. before enabling cache as ram).
In this case we did not enable any consoles yet, so we don't output
anything.
This patch removes inclusion of the unnecessary console/console.h for
that case, which was breaking with certain configurations.
Change-Id: Iebb57794d7b1e84cac253d249d47b88de4dd28a3
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/988
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CONFIG_MAX_PHYSICAL_CPUS is defined by quite a number of
mainboards whithout any code actually using the variable.
Hence, drop MAX_PHYSICAL_CPUS from Kconfig for those boards.
In the long run we should drop CONFIG_MAX_PHYSICAL_CPUS use
completely and make the code dynamic or depend on CONFIG_MAX_CPUS
instead.
Change-Id: I37dcc74d245ddba5186b96bd82220dacb6f4d323
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/984
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Instead of the special case in the generic Makefile.inc,
use cbfs-files in the CPU directories.
Change-Id: I71d9c8dff906c9a516ac0dd09a315f8956075592
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/962
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
... or fail if repository is not enabled.
Change-Id: I0a1e6d6fed852ec7edf96ace8346ae6b23838a56
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/959
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This code fixes the sandybridge C state generation code to work with
the current version of the ACPI code generator.
Change-Id: I56ae1185dc0694c06976236523fdcbe5c1795b01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/950
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... in order to unify the Sandybridge and Lenovo implementations
currently used in the tree.
- use acpi_addr_t in acpigen_write_register()
- use acpi_cstate_t for cstate tables (and fix up
the x60 and t60)
- drop cst_entry from acpigen.h
Change-Id: Icb87418d44d355f607c4a67300107b40f40b3b3f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/943
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There is no reason for this to be a top level directory.
Some stuff from lib/ should also be moved to drivers/
Change-Id: I3c2d2e127f7215eadead029cfc7442c22b26814a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/939
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Most subsystems print their name with a colon, and then the
message. Do the same thing for the microcode update code.
Also, each microcode update has a date header. Print the
date from that header to make it easier to determine whether
you're running the latest microcode.
Change-Id: Ic22947c4b9f0502d4091d975e1f1ab42f70aa1aa
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/929
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
- add GPLv2 + copyright header after talking to Ron
- "bits" in struct microcode served no real purpose but
getting its address taken. Hence drop it
- use asm volatile instead of __asm__ volatile
- drop superfluous wrmsr (that seems to be harmless but
is still wrong) in read_microcode_rev
- use u32 instead of unsigned int where appropriate
- make code usable both in bootblock and in ramstage
- drop ROMCC style print_debug statements
- drop microcode update copy in Sandybridge bootblock
Change-Id: Iec4d5c7bfac210194caf577e8d72446e6dfb4b86
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/928
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>
Comment out the id variable which is used in a commented code
block.
Change-Id: Ib002d57e5314971f0589d04b7e451ab7d7079f53
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/913
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This change reverts :
Change Id I4fdb281b2b684ab5fea999aae28ca08dce24da4d
The wbinvd (or invd) should not be needed at the reset vector. It
causes problems with some CPUs AP init. If there is a problem with
a specific CPU and it must be done at this location, it should be
added conditionally.
Change-Id: I85b71b0a07f039359a4fb889aaa05c75fff619be
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/908
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
1. Move the Stack to high memory.
2. Restore the MTRR before Coreboot jump to the wakeup vector.
Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Change the ExecuteFinalHltInstruction to assembly code. so we can make
sure the code can run stackless.
Change-Id: I783ced6cf7c5bc29c12a37aef29077e610d8957d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the early days of v2 the (e.g.) #ifdef SMP style was frowned upon in
some quarters.
Hence, empty definitions of functions were created. This
particular function, possibly the last remaining example,
was no longer even being used anywhere.
Signed-off-by: Ron Minnich <rminnich@gmail.com>
- preprocessor macros should not use defined(CONFIG_*) but
just CONFIG_*
- drop AMD CPU model 14XXX config variable use. Those do not exist.
- skip some delays on Sandybridge systems
- Count how long we're waiting for each AP to stop
- Skip speedstep specific CPU entries
Change-Id: I13db384ba4e28acbe7f0f8c9cd169954b39f167d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/871
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix regression after commit:
7dfe32c540
Only align 16-bit entry on platforms that really require it,
indicated by selecting SIPI_VECTOR_IN_ROM in CPU Kconfig.
Disable assertion test of AP_SIPI_VECTOR for platforms not
depending on this feature.
Build of romstage should be fixed to get the vector address from
bootblock build automatically.
Change-Id: Ide470833c0254df1a9ff708369ab1c095ccfb98d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/875
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Previously this part of smmrelocate.S had to be omitted because
the CONFIG_ options for those components did not exist yet. Add
them back.
Change-Id: I6ac94ca804e03062724401a08d1d174adac5e830
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/874
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Also fix the MTRR check to use the total_mtrrs
variable instead of a hardcoded 8.
Change-Id: I2c5ceb3910cd949f43ecf5b8aff857d6ffe0b1a5
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/873
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some CPUs (Sandybridge) seem to require this, and it does not hurt
on other CPUs.
Change-Id: I4fdb281b2b684ab5fea999aae28ca08dce24da4d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/869
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
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)
From wikipedia:
Intel Turbo Boost is a technology implemented by Intel in certain
versions of their Nehalem- and Sandy Bridge-based CPUs, including Core
i5 and Core i7 that enables the processor to run above its base
operating frequency via dynamic control of the CPU's "clock rate".
It is activated when the operating system requests the highest
performance state of the processor.
Change-Id: I166ead7c219083006c2b05859eb18749c6fbe832
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/844
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The socket mPGA604 is for P4 Xeon which to my knowledge is always
HT-enabled. I assume the existing usage of car/cache_as_ram.inc
on socket_mPGA604, namely the Tyan S2735, as broken.
Existing car/cache_as_ram.inc has invalid SIPI vector and it does
not initialise AP CPU's to activate L2 cache.
Other mPGA604 boards are not affected, as they have not been
converted to CAR.
Change-Id: I7320589695c7f6a695b313a8d0b01b6b1cafbb04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/607
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
some blank changing is integrated into the previous patches, which hold
the unsplitted diff hunk.
Change-Id: If9e5066927c5e27fee7ac8422dbfbf2cbeac7df5
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/625
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Use CPUID to get MAXPHYADDR and set MTRR masks correctly.
Also only BSP CPU clears MTRRs and initializes its Local APIC.
Change-Id: I89ee765a17ec7c041284ed402f21d9a969d699bd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/686
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This improvement of CAR code starts the sibling CPU processors and
clears their cache disable bits (CR0.CD) in case a hyper-threading
CPU is detected.
Change-Id: Ieabb86a7c47afb3e178cc75bb89dee3efe0c3d18
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/604
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Most or many Xeons have no MSR 0x11e.
I have previously tested that a HT-enabled P4 (model f25) can
execute this but will not have cache-as-ram enabled. Should work
for non-HT P4.
Change-Id: I28cbfa68858df45a69aa0d5b050cd829d070ad66
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/644
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For a hyper-threading processor, enabling cache requires that both the
BSP and AP CPU clear CR0.CD (Cache Disable) bit. For a Cache-As-Ram
implementation, partial multi-processor initialisation precedes
raminit and AP CPUs' 16bit entry must be run from ROM.
The AP CPU can only start execute real-mode code at a 4kB aligned
address below 1MB. The protected mode entry code for AP is identical
with the BSP code, which is already located at the top of bootblock.
This patch takes the simplest approach and aligns the bootblock
16 bit entry at highest possible 4kB boundary below 1MB.
The symbol ap_sipi_vector is tested to match CONFIG_AP_SIPI_VECTOR
used by the CAR code in romstage. Adress is not expected to ever
change, but if it does, link will fail.
Change-Id: I82e4edbf208c9ba863f51a64e50cd92871c528ef
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/454
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Delete dead CAR code and whitespace fixes.
Replace cryptic 32bit hex values with existing LAPIC definitions.
Do not assume state of direction flag before "rep" instruction.
Do not load immediate values on temporary registers when not needed.
Parameter pushed on stack was not popped (or flushed) after returning
from call. This is a sort-of memory leak if multiple call's are
implemented the same way.
Change-Id: Ibb93e889b3a0af87b89345c462e331881e78686a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/643
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Cache was enabled for the last 4 MB below 4 GB when ramstage is
loaded. This does not cover the case of a 8 MB Flash and could
overlap with some system device placed at high memory.
Use the actual device size for the cache region. Mainboard
may override this with Kconfig CACHE_ROM_SIZE if necessary.
Change-Id: I622223b1e2af0b3c1831f3570b74eacfde7189dc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/641
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Copy model_6ex CAR as car/cache_as_ram_ht.inc to be extended
with hyper-threading CPU support.
Change-Id: I09619363e714b1ebf813932b0b22123c1d89010e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/606
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
With >= 4GB memory installed we get a memory map split in the middle
due to remap that has boundaries that are inconveniently aligned for
MTRRs due to the various UMA regions.
0000MB-2780MB 2780MB RAM (writeback)
2780MB-2782MB 2MB TSEG (uncached/SMRR)
2782MB-2784MB 2MB GFX GTT (uncached)
2784MB-2816MB 32MB GFX UMA (uncached)
2816MB-4096MB 1280MB EMPTY (N/A)
4096MB-5368MB 1272MB RAM (writeback)
5368MB-5376MB 8MB ME UMA (uncached)
The default MTRR allocation method of trying to cover everything
with one MTRR and then carve out a single uncached region does
not work for the GPU aperture which needs write-combining type,
and it also has issues trying to cover the uneven boundaries
in the avaiable variable MTRRs.
My goal was to make a minimal set of changes and avoid modifying
behavior on existing systems with an algorithm that is not always
optimal for a typical memory layout. So the flag 'above4gb=2'
will change these allocation behaviors:
1) Detect the number of available variable MTRRs rather than
limiting to hardcoded value. We need every last MTRR.
2) Don't try to cover all RAM with one MTRR, instead let each
RAM region get covered independently.
3) Don't assume uma_memory_base is part of the last region
and increase the size of that region. In this case the UMA
region is carved out from the lower memory region and it is
already declared as part of the ram region.
4) If a memory region can't be covered with MTRRs >= 16MB then
instead make a larger region and trim it with uncached MTRRs.
Change-Id: I5a60a44ab6d3ae2f46ea6ffa9e3677aaad2485eb
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Future CPUs will require TSEG use for SMM
Change-Id: I1432569ece4371d6e12c997e90d66c175fa54c5c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/766
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Do not use printk on the running thread after it has been sent
the INIT IPI, execution may halt with console spinlock held.
Change-Id: I64608935ea740fb827fa0307442f3fb102de7a08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/776
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Only the BSP CPU was able to start its hyper-threading CPU siblings.
When an AP CPU attempts this it calls start_cpu() within start_cpu(),
deadlocking the system with start_cpu_lock.
At the time intel_sibling_init() is run, the BSP CPU is still
walking the cpu_bus linked list in lapic_cpu_init: start_other_cpus().
A sibling CPU appended at the end of this list will get started.
Also fail compile with #error if SERIAL_CPU_INIT==0, as microcode
updates on hyper-threading sibling CPUs must be serialized.
Tested with HT-enabled P4 Xeons on dual-socket604 platform.
Change-Id: I0053f58f49ed604605ce0a55e826d3e1afdc90b6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/775
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
It was not obvious which CAR was compiled in. Also build would fail
if a socket included two models with both having an include for CAR.
Change-Id: I000c2e24807c3d99347a43d120333c13fbf91af4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/626
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Also any CPU_AMD_AGESA_FAMILYxx selects CPU_AMD_AGESA, so remove
the explicit selects from the mainboards.
Change-Id: I4d71726bccd446b0f4db4e26448b5c91e406a641
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/792
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Kconfig leaked XIP_ROM_SIZE to other platforms and also
defined obsolete option XIP_ROM_BASE.
Alias AMD_AGESA as NORTHBRIDGE_AMD_AGESA.
Break the circular dependency with family15 Kconfig.
Change-Id: Ic7891012220e1bef758a5a39002b66971d5206e3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/773
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
So set their XIP configuration to ROM_SIZE.
Change-Id: I6c1abccec3b1d7389c85df55343ff0fc68a61eec
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/797
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The original comment says it's a Via C3 and not Epia requirement
to deliver IOAPIC interrupts on APIC serial bus.
Change-Id: I73c55755e0ec1ac5756b4ee7ccdfc8eb93184e4f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/435
Tested-by: build bot (Jenkins)
In a case of CS & 0x0fff != 0x0, lidt memory operand does not point
to nullidt, this can raise an exception and shutdown the CPU.
When an AP CPU receives 8-bit Start-Up IPI vector yzH, it starts
execute at physical address 000yz000H. Seems this translates to
either yz00:0000 or y000:z000 (CS:IP), depending of the CPU model.
With the change entry16.inc is relocatable as the commentary suggests
and can be used as ap_sipi_vector on SMP systems.
Change-Id: I885a2888179700ba6e2b11d4f2d6a64ddea4c2dc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/707
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Because it's included everywhere anyways.
Change-Id: I99a9e6edac08df57c50ef3a706fdbd395cad0abc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/691
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Also mark the corresponding lint test stable.
Change-Id: Ib7c9ed88c5254bf56e68c01cdbd5ab91cd7bfc2f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MTRR check for WB TOM2 setting was only checking revF, not extended family
revisions. All families above revf indicate 0xf in the family field and have
additional bits in the extended family field.
Change-Id: I93d719789acda6b7c42de7fd6d4bad2da866a25f
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: http://review.coreboot.org/627
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix issues reported by new lint test.
Change-Id: I077a829cb4a855cbb3b71b6eb5c66b2068be6def
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/646
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Kconfig directives to select chip drivers for compile literally
match the chip directory names capitalized and underscored.
Note: CPU_INTEL_CORE2 was used on both model_6fx and model_1067x.
Change-Id: I8fa5ba71b14dcce79ab2a2c1c69b3bc36edbdea0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/618
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Added a macro in the post code list, which replaces hard coded
value in cpu/x86/cache/cache.c
Change-Id: I27cb27827272584a8a17a41c111e2dc155196a97
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/572
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to use SSE+MMX optimized payloads we don't want to disable SSE+MMX
instructions in the CPU after romstage.
Change-Id: I51aeb01f04492ad7bc8b1fe181a4ae17fe0ca61e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/553
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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: If681a33deb7df752b37c6a8a20482d3c374af936
Signed-off-by: Nils Jacobs <njacobs8@adsltotaal.nl>
Reviewed-on: http://review.coreboot.org/528
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Philip Prindeville <philipp@redfish-solutions.com>
This function prevents the linker from choosing the right
get_cst_entries(), preventing writing the _CST tables.
Change-Id: I4bc0168aee110171faeaa081f217dfd1536bb821
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/496
Tested-by: build bot (Jenkins)
I misunderstood how kconfig select works. It needs to be selected with a config option. Moved the select to the correct location.
Change-Id: If9b1e21e6cbc5af4671efb76cf87dd18dbbe2234
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: http://review.coreboot.org/487
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This fixes problems in AP init when multiple APs are trying to access
PCI config space. All Fam10 CPUs setup and support MMCONF.
Change-Id: I00a25bbf4e4152c89024f14a3c4c1c36b48d0128
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: http://review.coreboot.org/455
Tested-by: build bot (Jenkins)
Reviewed-by: Alec Ari <neotheuser@ymail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Detection of a CPU being a BSP CPU is not dependent of the existence
of northbridge and/or southbridge init code in the bootblock.
Even if CONFIG_LOGICAL_CPUS==0, boot_cpu() can get executed on an AP
CPU of a hyper-threading CPU and needs to return actual BSP bit from
MSR.
Change-Id: I9187f954bb357ba1dbd459cfe11cc96cb7567968
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/447
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Following files were no longer used in the build and are deleted:
src/arch/x86/init/entry.S
src/arch/x86/init/ldscript.ld
Also fix ugly whitespace in code copyrights and comments.
Change-Id: Ia6360b0ffc227f372d5f997495697a101f7ad81b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/440
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Disable DRAM controller on non-fam-f CPUs not using fam-f register layout.
Change-Id: I2cc87857452555011d69bfebe9f9c4c17cef8f6c
Signed-off-by: Florian Zumbiehl <florz@florz.de>
Reviewed-on: http://review.coreboot.org/448
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Relocate early post_code() so it gets executed and does not corrupt
BIST at %eax.
Change-Id: Ieeebcb23f7c327e501b410eaa60d1e49110ee988
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/439
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>
It is meant to be a address and not a dereference. Otherwise MTRR
is filled with code and not with the address.
This is what I hate at most on the AT&T syntax. Instead of taking
the address, it was a dereference. Not greatly visible, except
I wondered why opcode is not 0xb4 but 0xa1 and it took another
half an our to see it.
Change-Id: I6b339656024de8f6e6b3cde63b16b7ff5562d055
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/358
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This change removes CONFIG_TINY_BOOTBLOCK, CONFIG_BIG_BOOTBLOCK, and
all their uses, assuming TINY_BOOTBLOCK=y, BIG_BOOTBLOCK=n.
This might break a couple of boards on runtime, but so far, fixes were
quite simple.
There's a flag day: Code that relies on CONFIG_TINY_BOOTBLOCK must be
adapted.
Change-Id: I1e17a4a1b9c9adb8b43ca4db8aed5a6d44d645f5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/320
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>
As new microcode files were included, the table was not updated with
families 0f25 and 0f26.
Change-Id: I5bb8be9d7c37eb8406dcb48a4b933eab24639bda
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/290
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
First issue fixed:
For multi-socket CPU the current implementation emitted
Processor objects for cores in the first CPU only. This
commit fixes the bug by really emitting one Processor
object for each core. However, the unlikely case of mixed
CPU models is still not handled correctly.
Second issue fixed:
One loop was wrong in case a processor in the table declares
no P-states at all. The rewritten loop is safe. Some possibly
dangerous array lengths were also fixed.
Third issue: on MP-boards the recommended ramp-voltage (RVO) is 0mV
according to the BKDG. The current implementation always set it
to 25mV. This commit selects 0 or 25mV depending on CONFIG_MAX_PHYSICAL_CPUS.
Fourth issue: If a processor without PowerNow! support was inserted in a
system with coreboot configured with SET_FIDVID then the boot process hanged
mysteriously and very early. Apparently because init_fidvid_ap tampers with
non-existing registers. This commit fixes the bug by bailing out
from init_fidvid_ap if PowerNow! capability is missing.
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Change-Id: I61f6e2210b84ccba33a36c5efc866447b7134417
Reviewed-on: http://review.coreboot.org/239
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
According to Rudolf Marek putting a memory instruction between
the CR0 write and the jmp in protected mode switching might hang the
machine. Move it after the jmp.
There might be a better solution for this, such as enabling the cache, as
keeping it disabled does not prevent cache poisoning attacks, so there is no
real point.
However, Intel docs say that SMM code in ASEG is always running uncached, so
we might want to consider running SMM out of TSEG instead, as well.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Id396acf3c8a79a9f1abcc557af6e0cce099955ec
Reviewed-on: http://review.coreboot.org/283
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Tested-by: build bot (Jenkins)
Load an IDT with NULL limit to prevent the 16bit IDT being used
in protected mode before c_start.S sets up a 32bit IDT when entering
ram stage.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I8d048c894c863ac4971fcef8f065be6b899e1d3e
Reviewed-on: http://review.coreboot.org/259
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
AMD K8 rev F and later implements a bit SYSCFG_MSR_TOM2WB to
mark dram memory above 4GB as WB. However, AMD K8
rev E and earlier don't implement this bit and therefore need
MTRR spanning dram memory above 4GB. The current implementation
of amd_setup_mtrrs never generate MTRR above 4GB.
This caused memory > 4GB not to be recognized in e.g. Linux on those
rev E or older platforms. This commit should fix that bug.
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Change-Id: Ie568a52a8eb355969c86964d5afc4692e60f69c1
Reviewed-on: http://review.coreboot.org/238
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
the patch file comes from
src/vendorcode/amd/agesa/f12/Proc/CPU/Family/0x10/RevE
/F10MicrocodePatch010000bf.c
Change-Id: If701c8a908edf1c486665d3ce4df65da0f65c802
Signed-off-by: QingPei Wang <wangqingpei@gmail.com>
Reviewed-on: http://review.coreboot.org/202
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
This commit adds in some more fixes to AMD F14 compile
warnings. The change in the mtrr.c file is in prep-
aration for changes yet to com, but it is currently
innocuous.
Change-Id: I6b204fe0af16a97d982f46f0dfeaccc4b8eb883e
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/133
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The CPUs start on their slowest speed, and were left that way by
coreboot. This change will speed up coreboot a bit, as well as
systems that don't change the clock for whatever reason.
Change-Id: Ia6225eea97299a473cf50eccc6c5e7de830b1ddc
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/176
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change updates the AMD Agesa code to support the Family 14
rev C0 cpus. It also fixes (again) a ton of warnings, although
not all of them are gone. The warning fixes affect code in the
Family 12 tree as well, so there are some small changes therein.
This code has been tested on a Persimmon and passes Abuild.
This is the first (and largest) of a number of commits to complete
the upgrade.
Change-Id: Id28d9bf7931f8baa2a602f6bb096a5a465ccd20d
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/131
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Bring from coreboot v1 support for initializing L2 cache on Slot 1
Pentium II/III CPUs, code names Klamath, Deschutes and Katmai.
Build tested on ASUS P2B-LS and P3B-F. Boot tested on P2B-LS with
Pentium III 600MHz, Katmai core.
Also add missing include of model_68x in slot_1, to address a
similar problem fixed for model_6bx by r5945.
Also change Deschutes CPU init sequence to match Katmai.
Change-Id: I502e8481d1a20f0a2504685e7be16b57f59c8257
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: http://review.coreboot.org/122
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change separates out changes that were initially found
in the commit for XHCI and AHCI changes to "arch/x86/Makefile.
inc". It also corrects a comment. The SSE3 dependent code
adds a pair of CR4 access functions and a blob of code that
re-sets CR4.OSFXSR and CR4.OSXMMEXCPT.
Change-Id: Id97256978da81589d97dcae97981a049101b5258
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/113
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This updates the code for the AMD SR5650 and SB700 southbridges.
Among other things, it changes the romstage.c files by replacing a
.C file include with a pair of .H file includes. The .C file is
now added to the romstage in the SB700 or SR5650 Makefile.inc.
file to the romstage and ramstage elements. This particular change
affects all mainboards that use the SB700, and their changes are
include herein. These mainboards are:
Advansus a785e,
AMD Mahogany, Mahogany-fam10, Tilapia-fam10,
Asrock 939a785gmh,
Asus m4a78-em, m4a785-m,
Gigabyte ma785gm,
Iei Kino-780am2-fam10
Jetway pa78vm5
Supermicro h8scm_fam10
The nuvoton/wpcm450 earlysetup interface is changed because the file
is no longer included in the mainboard romstage.c files.
Change-Id: I502c0b95a7b9e7bb5dd81d03902bbc2143257e33
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/107
Tested-by: build bot (Jenkins)
Reviewed-by: Kerry She <shekairui@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
This change adds the AMD Family 10 cpu support to the
cpu folder. It also updates the makefiles of the Families
12 and 14 to take advantage of a pair of shared files that
are moved to the cpu/agesa folder.
Change-Id: Ibd3a50ea7a3028bd6a2d2583f021506b73e2fce2
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/97
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
Align the spinlock to the 4 byte boundary (CPU will guarantee atomicity of XCHG).
While at it add the PAUSE instruction to spinlock loop to hint the CPU we are just
spinlocking. The rep nop could not be used because "as" complains that rep is used
without string instructions.
Change-Id: I325cd83de3a6557b1bee6758bc151bc81e874f8c
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/81
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This change adds the wrapper code for the AMD Family12
cpus and the AMD Hudson-2 (SB900) southbridge to the cpu,
northbridge and southbridge folders respectively.
Change-Id: I22b6efe0017d0af03eaa36a1db1615e5f38da06c
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/53
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change moves the AMD Family14 cpu Agesa code to
the vendorcode/amd/agesa/f14 folder to complete the
transition to the family oriented folder structure.
Change-Id: I211e80ee04574cc713f38b4cc1b767dbb2bfaa59
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/52
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
This change renames the cpu/amd/agesa_wrapper, northbridge/
amd/agesa_wrapper, and southbridge/amd/cimx_wrapper folders
to {cpu|NB}/amd/agesa and {SB}/amd/agesa to shorten and
simplify the folder names.
There is also a fix to vendorcode/amd/agesa/lib/amdlib.c to
append "ull" to a trio of 64-bit hexadecimal constants to
allow abuild to run successfully.
Change-Id: I2455e0afb0361ad2e11da2b869ffacbd552cb715
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Signed-off-by: efdesign98 <efdesign98@gmail.com>
Reviewed-on: http://review.coreboot.org/51
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Fixes spurious SMI crashes i've seen, and ACPI/SMM interaction.
For reference, the mail i've sent to ML with the bugreport:
whenever i've docked/undocked the thinkpad from the docking station,
i had to do that twice to get the action actually to happen.
First i thought that would be some error in the ACPI code. Here's a
short explanation how docking/undocking works:
1) ACPI EC Event 0x37 Handler is executed (EC sends event 0x37 on dock)
2) _Q37 does a Trap(SMI_DOCK_CONNECT). Trap is declared as follows:
a) Store(Arg0, SMIF) // SMIF is in the GNVS Memory Range
b) Store(0, 0x808) // Generates I/O Trap to SMM
c) // SMM is executed
d) Return (SMIF) // Return Result in SMIF
I've verified that a) is really executed with ACPI debugging in the
Linux Kernel. It writes the correct value to GNVS Memory. After that,
i've logged the SMIF value in SMM, which contains some random (or
former) value of SMIF.
So i've added the GNVS area to /proc/mtrr which made things work.
I've also tried a wbinvd() in SMM code, with the same result.
After reading the src/cpu/x86/smm/smmhandler.S code, i've recognized
that it starts with:
movw $(smm_gdtptr16 - smm_handler_start +
SMM_HANDLER_OFFSET), %bx
data32 lgdt %cs:(%bx)
movl %cr0, %eax
andl $0x7FFAFFD1, %eax /* PG,AM,WP,NE,TS,EM,MP = 0 */
orl $0x60000001, %eax /* CD, NW, PE = 1 */
movl %eax, %cr0
/* Enable protected mode */
data32 ljmp $0x08, $1f
...which disables caching in SMM code, but doesn't flush the cache.
So the problem is:
- the linux axpi write to the SMIF GNVS Area will be written to Cache,
because GNVS is WB
- the SMM code runs with cache disabled, and fetches SMIF directly from
Memory, which is some other value
Possible Solutions:
- enable cache in SMM (yeah, cache poisoning...)
- flush caches in SMM (really expensive)
- mark GNVS as UC in Memory Map (will only work if OS
really marks that Area as UC. Checked various vendor BIOSes, none
of them are marking NVS as UC. So this seems rather uncommon.)
- flush only the cache line which contains GNVS. Would fix this
particular problem, but users/developers could see other Bugs like
this. And not everyone likes to debug such problems. So i won't like
this solution.
Change-Id: Ie60bf91c5fd1491bc3452d5d9b7fc8eae39fd77a
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/39
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>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6594 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6571 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2) Remove coreboot variable MTRR initialization because AMD reference code handles it.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6570 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Simplify
read_option(CMOS_VSTART_foo, CMOS_VLEN_foo, somedefault)
to
read_option(foo, somedefault)
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6565 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
example.
This newer version reflects the recent changes to further simplify the console
code and partly gets rid of some hacks in the previous version.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6544 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
for that instead. This also allows using non-uart8250 consoles for smi
debugging.
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@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
