The CPU can arbitrarily reorder calls to rdtsc, significantly
reducing the precision of timing using the CPUs time stamp counter.
Unfortunately the method of synchronizing rdtsc is different
on AMD and Intel CPUs. There is a generic method, using the cpuid
instruction, but that uses up a lot of registers, and is very slow.
Hence, use the correct lfence/mfence instructions (for CPUs that
we know support it)
Change-Id: I17ecb48d283f38f23148c13159aceda704c64ea5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1422
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
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>
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>
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>
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)
... 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>
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>
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>
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>
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>
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>
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>
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>
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>
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)
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>
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>
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 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>
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>
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>
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
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
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
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
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
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
