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
It is based on other existing Fam10 code.
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6464 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Marc Jones <marcj303@gmail.com>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6453 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
States for AMA3000BEX5AR, SDA3100AIO3BX, and SDA3400AIO3BX
are from AMD document 30430 3.51. States for ADA3200AIO4BX
derived from SSDT of a MS-7135. States for TMDML34BKX5LD derived
from legacy PowerNow! table of a MS-7135, and therefore lack accurate
TDP information.
Signed-off-by: Jonathan Kollasch <jakllsch@kollasch.net>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6432 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
With this change the last P-state entry of the last CPU in the table
is successfully conveyed into the SSDT.
Signed-off-by: Jonathan Kollasch <jakllsch@kollasch.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6430 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
I don't understand what this was doing nor find docs for these regs
Maybe it was left over from some copy & paste ?
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6411 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
I don't understand what this was doing nor find docs for these regs
Maybe it was left over from some copy & paste ?
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6410 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
I don't understand what this was doing nor find docs for these regs
Maybe it was left over from some copy & paste ?
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6409 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
In fact I changed coreDelay before deleting
the code in fidvid that called it. But there're
still a couple of calls from src/northbridge/amd/amdmct/wrappers/mcti_d.c
Since the comment encouraged fixing something, I
parametrized it with the delay time in microseconds
and paranoically tried to avoid an overflow at pathological
moments.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6408 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Well, I understand it better like this, but maybe
it's only me, part of the changes are paranoic, and
the only effective change is for a factor depending on
mobile or not that I can't test.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6406 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Add an untested step in BKDG 2.4.2.8. I don't
have the hardware with Core Performance Boost and
I think it's only available in revision E that does
not even have a constant yet.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6405 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Add to init_fidvid_stage2 some step
mentioned in BKDG 2.4.2.7 that was missing . Some lines
are dead code now, but may handy if one day we support
revison E CPUs.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6404 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Add to init_fidvid_stage2 some step for my CPU (rev C3)
mentioned in BKDG 2.4.2.6 (5) that was missing
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6403 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Looking at BKDG the process for updating
Pstate Nb vid after warn reset seemed
more similar to the codethat was there fo
pvi than the one for svi, so I called the
pvi function passing a pvi/svi flag. I don't
find documentation on why should UpdateSinglePlaneNbVid()
be called in PVI, but since I can't test it,
I leave it as it was.
This patch showed some progress beyond fidvid in my
boar,d but only sometimes, most times it just didn't
work.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6402 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Factor out some common expressions.
Add an error message when coreboots hangs waiting for a pstate
that never comes (it happened to me), and throw some
paranoia at it for good mesure.
If I understood BKDG fam10 CPUs never need a software initiated vid transition,
because the hardware knows what to do when you just request
a Pstate change if the cpu is properly configured. In fact
unifying a little what PVI and SVI do was better for my board (SVI).
So I drop transitionVid, which I didn't understand either (why
did it have a case for PVI if it is never called for PVI ?
Why did the PVI case distinguigh cpu or nb when PVI is
theoretically single voltage plane ? ).
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6401 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Contemplate the possibility of nbCofVidUpdate not being
defined, trying to get closer to BKDG
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6399 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Configuration of F3x[84:80] was hardcoded for rev B.
I change that for some code that checks for revision
and configures according to BKDG. Unfinished but
hopefully better than it was.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6398 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
BKDG says nbSynPtrAdj may also be 6 sometimes.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6397 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
I didn't understand quite why it did that iwth F3xA0 (Power
Control Misc Register) so I moved Pll Lock time to rules in defaults.h
and reimplemented F3xA0 programming. A later patch will remove
a part I don't know what's mean to do.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6396 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode.
Bring F3xD4 (Clock/Power Control Register 0) more in line
with BKDG i more cases. It requires looking at the CPU package type
so I add a function for that (in the wrong place?) and some
new constants
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6395 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . Factor out the decision whether
to update northbridge frequency and voltage because there
was the same code in 3 places and so we can later modify it
in one place.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6394 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . Factor out the decision whether
to update northbridge frequency and voltage because there
was the same code in 3 places and so we can later modify it
in one place.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6393 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid. Factor out a little common code.
Also, our earlier config_clk_power_ctrl_reg0
was still too long and it'd get longer with forthcoming patches.
We now take apart F3xD4[PowerStepUp,PowerStepDown]
to its own function.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6392 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3x[84:80],
ACPI Power State Control Registers, to its own function.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6391 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3xDC[NbsynPtrAdj],
Northbridge/core synchronization FIFO pointer adjust, to its own function.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6390 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3xA0,
Power Control Misc Register to its own function.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6389 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode).
No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart F3xD4,
Clock Power/Timing Control 0 to its own function.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6388 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CPU and northbridge frequency and voltage
handling for Fam 10 in SVI mode). No change of behaviour intended.
Refactor FAM10 fidvid . prep_fid_change was already long and it'd
get longer with forthcoming patches. We now take apart VSRamp in step b
of 2.4.1.7 BKDG to its own function.
Signed-off-by: Xavi Drudis Ferran <xdrudis@tinet.cat>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6387 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Also it enables the FID/VID changes in SB. Jakllsch had some troubles with that too but on am2 CPU. Those bits are only documented in SB600. They arent in RRG RPR and BDG.
Signed-off-by: Rudolf Marek <r.marek@asssembler.cz>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6381 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This affects the CMOS options iommu, ECC_memory, max_mem_clock,
hw_scrubber, interleave_chip_selects.
If they're absent in cmos.layout, a Kconfig value is used if it exists,
or a hardcoded default otherwise.
[Patrick: I changed the ramstage CMOS handling a bit, and dropped the
reliance of hw_scrubber on ECC RAM, as it has nothing to do with it -
it's the cache that's being scrubbed here.]
Signed-off-by: Josef Kellermann <seppk@arcor.de>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6380 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This code provides cpu early initialization for Family 14h cpus. It is dependent on the AMD Agesa code.
Signed-off-by: Frank Vibrans <frank.vibrans@amd.com>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6347 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
execution from flash memory. Coreboot uses WB. While there is no
noticeable performance difference between the two settings, use
of WB can cause a problem for a jtag debugger. The attached
patch changes AMD cache as ram setting for flash execution from
WB to WP.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6342 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Workaround for 131 removed.
Changed workaround for erratum 110 to only include pre-revision-F
processors.
For details, check AMD publications:
#25759 (Errata for Fam F pre-revision F processors)
#33610 (Errata for Fam F revision F and later processor)
Based on work and previous patches by:
Rudolf Marek <r.marek@assembler.cz>
Josef Kellermann <seppk@arcor.de>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6340 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
a bit later.
Signed-off-by: Josef Kellermann <seppk@arcor.de>
Acked-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6339 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
the board. I thought we did this ages ago.
Also push CAR BASE further down so it won't conflict with a 32mbit flash part.
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@6299 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
have this go away again.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Kevin O'Connor <kevin@koconnor.net>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6273 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cache that range instead of the first 1Meg. This reduces boot time by
about 1 second on epia-cn.
This patch also adds a MTRRphysMaskValid bit definition.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6272 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The main CIMx code is in a src/vendorcode directory and should not be
changed with regard to coding style etc. in order to remain easily syncable
with the "upstream" AMD code.
Signed-off-by: Kerry She <Kerry.she@amd.com>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6229 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Nils Jacobs <njacobs8@hetnet.nl>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6210 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Nils Jacobs <njacobs8@hetnet.nl>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6209 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Nils Jacobs <njacobs8@hetnet.nl>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6208 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6202 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
which uses it.
Compiles, but not boot tested lately.
Many things missing (eg. SMM support, proper ACPI, ...)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6198 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- move some variables where they belong
Signed-off-by: Stefan Reinauer <stepan@coreboot.org>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6186 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
src/arch/x86.
Signed-off-by: Stefan Reinauer <stepan@coreboot.org>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6161 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
> Definitively a iasl problem, it can't even disassemble it's own
> output back to something equivalent to the input file.
> It seems to be generating Bytecode for the Add where it shouldn't.
Here is a solution using the SSDT.
Unfortunately iasl does not resolve simple arithmetic at compile
time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the
Processor statement.
This patch instead dynamically generates the processor statement.
I can't use the speedstep generate_cpu_entries() directly since the
cpu doesn't support speedstep.
For now the code is in the southbridge directory, but maybe it
should go into cpu/intel/ somewhere.
IIRC notebook cpus of the era can already have speedstep, so it
would probably be possible to pair the i82371eb with a
speedstep-capable cpu...
Also, I don't know if multiprocessor boards (abit bp6?) would need
to be handled differently.
Abuild-tested.
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
All K8/Fam10h boards use CAR, so move the "select CACHE_AS_RAM"
into the socket directories, and remove it from the individual boards.
Do the same for Intel CPUs/sockets where all boards use CAR.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6151 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2) the patch implements get_cbmem_toc in chipset specific way if defined.
On Intel targets it should be unchanged. On K8T890 the the cbmem_toc is read from NVRAM. Why you ask? Because we cannot do it as on intel, because the framebuffer might be there making it hard to look for it in memory (and remember we need it so early that everying is uncached)
3) The patch removes hardcoded limits for suspend/resume save area (it was 1MB) on intel. Now it computes right numbers itself.
4) it impelements saving the memory during CAR to reserved range in sane way. First the sysinfo area (CAR data) is copied, then the rest after car is disabled (cached copy is used). I changed bit also the the copy of CAR area is now done uncached for target which I feel is more right.
I think I did not change the Intel suspend/resume behaviour but best would be if someone can test it. Please note this patch was unfinished on my drive since ages and it would be very nice to get it in to prevent bit rotten it again.
Now I feel it is done good way and should not break anything. I did a test with abuild and it seems fine.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6117 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
initializing VGA happens pretty much as the last thing before starting the
payload. Hence, drop VGA console support, as we did in coreboot v3.
- Drop VGA and BTEXT console support.
Console is meant to be debugging only, and by the time graphics comes up
99% of the risky stuff has already happened. Note: This patch does not remove
hardware init but only the actual output functionality.
The ragexl driver needs some extra love, but that's for another day
- factor out die() and post()
- drop some leftover RAMBASE < 0x100000 checks.
Signed-off-by: Stefan Reinauer <stepan@coreboot.org>
Acked-by: QingPei Wang<wangqingpei@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
deselected it, and very likely there won't ever be any
hardware that requires it deselected.
Keep the "selected" code path around, leading to no
functional change.
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Scott Duplichan <scott@notabs.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6086 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6085 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
make their defaults more obvious.
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6077 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
-- When building for UMA, reduce the limit for DRAM below 4GB
from E0000000 to C0000000. This is needed to accomodate the
UMA frame buffer.
-- Correct problem where msr C0010010 bits 21 and 22 (MtrrTom2En
and Tom2ForceMemTypeWB) are not set consistently across cores.
-- Enable TOM2 only if DRAM is present above 4GB.
-- Use AMD Tom2ForceMemTypeWB feature to avoid the need for
variable MTRR ranges above 4GB.
-- Add above4gb flag argument to function x86_setup_var_mtrrs. Clearing
this flag causes x86_setup_var_mtrrs() to omit MTRR ranges for
DRAM above 4GB. AMD systems use this option to conserve MTRRs.
-- Northbridge.c change to deduct UMA memory from DRAM size reported
by ram_resource. This corrects a problem where mtrr.c generates an
unexpected variable MTRR range.
-- Correct problem causing build failure when CONFIG_GFXUMA=1 and
CONFIG_VAR_MTRR_HOLE=0.
-- Reserve the UMA DRAM range for AMD K8 as is already done for AMD
family 10h.
Tested with mahogany on ECS A780G-GM with 2GB and 4GB.
Tested with mahogany_fam10 on ECS A780G-GM with 2GB and 4GB.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6067 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Linux kernel, which was previously complaining that the MTRR setup
is wrong, if the cpu supports more than CONFIG_CPU_ADDR_BITS bits of
address space.
Shamelessly copied from Linux arch/x86/kernel/cpu/mtrr/main.c
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Acked-by: Scott Duplichan <scott@notabs.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6052 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is Abuild and boot tested.
Signed-off-by: Nils Jacobs <njacobs8@hetnet.nl>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6015 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5989 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
for 256 buses, even if fewer are configured. This patch lets msr
c0010058 programming use the configured bus count, CONFIG_MMCONF_BUS_NUMBER.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5976 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Also, update the board that uses this socket to match.
Signed-off-by: Jonathan Kollasch <jakllsch@kollasch.net>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5969 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
currently restricted to recent model AMD processors, though it could be applied to others after successful testing.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5967 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
is sometimes logged. The reason is that the AP first sets a completion value
such as 0x13, which is what function wait_cpu_state() is waiting for. Then a
short time later, the AP calls function init_fidvid_ap(). This function sets
a completion value of 01. When logging is off, wait_cpu_state is fast enough
to see the initial completion value for each of the APs. But with logging
enabled, one or more APs may go on to complete function init_fidvid_ap, which
sets the completion value to 01. While mostly harmless, the timeout does
increase boot time. This patch eliminates the timeout by making function
wait_cpu_state recognize 01 as an additional valid AP completion value.
Signed-off-by: Scott Duplichan <scott@notabs.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5966 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This also has an additional benefit:
I was running "sh update-microcodes.sh" previously which broke with
update-microcodes.sh: 102: Bad substitution
due to the script requiring /bin/bash instead of /bin/sh (uses bash-specific
stuff). Running "bash update-microcodes.sh" works fine.
Making the script executable in svn reduces the likelyhood of people
running the script with differing shells that may not work.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5963 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
They now have their own home at cpu/intel/model_65x.
Signed-off-by: Keith Hui <buurin@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5960 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
abuild-tested. I have no Deschutes CPUs to boot test this with.
Signed-off-by: Keith Hui <buurin@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5954 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This CAR implementation hardcodes the Cache-as-RAM base address to:
0xd0000 - CacheSize
so the DCACHE_RAM_BASE is never actually used for this implementation
and these sockets.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5953 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- Drop "select ROMCC" from the boards, as well as early_mtrr stuff.
- Add "select CACHE_AS_RAM" to socket_PGA370/Kconfig, as well as the
usual DCACHE_RAM_BASE and DCACHE_RAM_SIZE variables.
- In socket_PGA370/Makefile.inc add:
cpu_incs += $(src)/cpu/intel/car/cache_as_ram.inc
- Other smaller related fixes.
Abuild-tested and boot-tested on MSI MS-6178.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5949 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I could no longer boot my P3B-F with my Tualeron and r5938. Dies with
"unknown CPU". I believe it will happen with any Slot 1 440BX boards
that supports model_6bx CPUs.
I need to make the change below to make it work. abuild tested. Boot
tested on P2B-LS and P3B-F.
Signed-off-by: Keith Hui <buurin@gmail.com>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5945 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
As both ioapic.h and acpi.h define a macro named "NMI", rename one
of them (NMI -> NMIType in acpi.h).
Abuild-tested.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5943 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Macros for the register addresses for the MTRR MSRs are already defined
in include/cpu/x86/car.h. This patch uses those macros instead of
creating a second instance of that same data.
I also added a few macros to the amd mtrr.h to make the MSR naming more
consistent.
Signed-off-by: Warren Turkal <wt@penguintechs.org>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5942 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
The following functions are moved to devices/device_util.c:
- ram_resource()
- tolm_test()
- find_pci_tolm()
There are only two tolm_test() / find_pci_tolm() which differ from the
defaults, one of them can easily be eliminated in a follow-up patch,
maybe even both, but for now keep it simple and only eliminate the majority.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5937 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- Add "select CACHE_AS_RAM" in src/cpu/intel/slot_1/Kconfig.
- Add the following in src/cpu/intel/slot_1/Makefile.inc:
cpu_incs += $(src)/cpu/intel/car/cache_as_ram.inc
- Remove "select ROMCC" from all 440BX board Kconfig files.
- Drop all early_mtrr_init() calls, that's done by CAR code now.
Various small fixes were needed to make it build:
- Drop do_smbus_recv_byte(), do_smbus_send_byte(), do_smbus_write_byte(),
those were never called anyways.
- Remove the "static" from the main() functions in romstage.c files.
- Always call dump_spd_registers() from the 440BX debug.c, but use
"#if CONFIG_DEBUG_RAM_SETUP" to only have that code if RAM debugging
is enabled in menuconfig.
- Drop all "lib/ramtest.c" #includes and ram_check() calls (even if
commented out) from romstage.c's, as we've done for most other boards.
- Add missing #includes or prototypes. Some of the prototypes will be
removed later when we get rid of the #include'd .c files.
Abuild-tested for all boards, and boot-tested on A-Trend ATC-6220.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5917 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Add links to the respective Intel specification updates or manuals where
the IDs are listed. Mention the possible core steppings of each CPU ID.
There are duplicate IDs in model_6xx and model_68x for now, not sure if
those should be eliminated, but there were already duplicates before this
patch, so that's probably an extra issue to look into.
Abuild-tested.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5909 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This makes the CAR implementations a lot more readable, shorter and
easier to follow, and also reduces the amount of uselessly duplicated code.
For example there are more than 12 open-coded "enable cache" instances
spread all over the place (and 12 "disable cache" ones), multiple
"enable mtrr", "save BIST", "restore BIST", etc. etc.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5902 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is abuild-tested.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5901 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- Use some more #defines instead of hard-coding values.
- Merge multiple movl/orl or movl/andl lines into one where possible.
- Add some TODOs in places which seem to have either an incorrect
code or incorrect comment.
- Fix typos: s/for/from/, s/BSC/BSP/, s/size/carsize/.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5890 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Also, whitespace fixes, consistency fixes, and drop some of the less
useful comments.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5888 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Replace $0x200 with $MTRRphysBase_MSR(0) etc. Also, move some #ifdef stuff
a little bit around (should not affect any functionality) to make the
Intel/AMD/VIA CAR implementations more similar and easier to compare.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5887 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
at the same time let the user specify sources instead
of object files:
- objs becomes ramstage-srcs
- initobjs becomes romstage-srcs
- driver becomes driver-srcs
- smmobj becomes smm-srcs
The user servicable parts are named accordingly:
ramstage-y, romstage-y, driver-y, smm-y
Also, the object file names are properly renamed now, using
.ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently.
Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't
easily fit in the build system and aren't useful anyway.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coreystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
For the a number of the socket 940 based machines, I collapsed their CAR
configurations into the socket config.
However, I have kept a number of overrides in place for the following
machines:
* broadcom/blast
* ibm/e32{5,6}
* newisys/khepri
* sunw/ultra40
* tyan/s488{0,2}
These machines used different setting than the defaults for socket 940
systems.
Signed-off-by: Warren Turkal <wt@penguintechs.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5883 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This change is somewhat dangerous as it enables CAR for some boards that
it was not enabled for before.
Signed-off-by: Warren Turkal <wt@penguintechs.org>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5882 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
