Age | Commit message (Collapse) | Author |
|
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>
|
|
Change-Id: I853454e8f5617fb7af5dddd7288bdeeacc7b1b8e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1663
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
Change-Id: I3efef6bc8f519382ffdd92eb10b4bcd1a4361ba9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1657
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>
|
|
Change-Id: Ia7ef3a4cbc3638a9c9a48b297e392e4e655b6e6b
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/1581
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I7a49d5fc13fb605a47c3c1662758ebd5935e7780
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1564
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
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>
|
|
CONFIG_CPU_AMD_SOCKET_C32_NON_AGESA
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>
|
|
Change-Id: I4bcf3f3435f0ba487955d14ed1b010fd94b9f625
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1408
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 042c1461fb777e583e5de48edf9326e47ee5595f.
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This reverts commit 78efc4c36c68b51b3e73acdb721a12ec23ed0369.
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>
|
|
Change-Id: Idee4facc18e0be60906d2a2f0e99bd39de8d7247
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1332
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|