summaryrefslogtreecommitdiff
path: root/src/cpu/intel/haswell/haswell.h
AgeCommit message (Collapse)Author
2016-07-23intel/haswell: Add asmlinkage for romstage_after_car()Kyösti Mälkki
Change-Id: Ib3c973d2e89d4c25c3bf1e52662fbfcb4b1e4355 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15789 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-06cpu/intel/haswell: convert to using common MP and SMM initAaron Durbin
In order to reduce duplication of code use the common MP and SMM initialization flow. Change-Id: I80b5b94b62bdd001581eb56513a0d532fffb64e8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14596 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2014-05-05haswell: move to mp_init libraryAaron Durbin
The mp_init library was based off of haswell code, but baytrail was the first chipset to take advantage of it. Move haswell over to using it so that the code duplication can be removed. Change-Id: Id6e9464df028aa6ec138051f925817c85b4c13e5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5413 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-30coreboot: config to cache ramstage outside CBMEMAaron Durbin
Haswell was the original chipset to store the cache in another area besides CBMEM. However, it was specific to the implementation. Instead, provide a generic way to obtain the location of the ramstage cache. This option is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM Kconfig option. BUG=chrome-os-partner:23249 BRANCH=None TEST=Built and booted with baytrail support. Also built for falco successfully. Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172602 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4876 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-26src/cpu: Fix spelling of MTTR to MTRRPaul Menzel
Change-Id: Ia4718ac31a5b2bd12f8cda5e107aa878d74d2a03 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/4805 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-12-12haswell: Export functions for CPU family+model and steppingDuncan Laurie
These are needed to enable workarounds/features on specific CPU types and stepping. The older northbridge function and defines from sandybridge/ivybridge are removed. Change-Id: I80370f53590a5caa914ec8cf0095c3177a8b5c89 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61333 Commit-Queue: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4355 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-12-07haswell: VR controller configurationAaron Durbin
Configure the VR controller. This enables the PSIx levels as well as C-state ramping. PSIx thresholds are: - PSI3: 1A. - PSI2: 5A. - PSI1: 15A. Before: 0x601 0x0000000000000100 0x603 0x0036000000262626 0x636 0x000000000000006f After: 0x601 0x4010140f00000100 0x603 0x0036000000262626 0x636 0x000000000000006f Change-Id: I6958845ac4164ebd0f1bb2d6d9be55ba63ed9344 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60931 Reviewed-by: Sameer Nanda <snanda@chromium.org> Reviewed-on: http://review.coreboot.org/4338 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2013-12-07haswell: Misc power management setup and fixesDuncan Laurie
1) fix enable of power aware interrupt routing 2) set BIOS_RESET_CPL to 3 instead of 1 3) mirror PKG power limit values from MSR to MMIO on all SKUs 4) mirror DDR power limit values from MMIO to MSR 5) remove DMI settings that were from snb/ivb as they do not apply to haswell 1) verify power aware interrupt routing is working by looking in /proc/interrupts to see interrupts routed to both cores instead of always to core0 BEFORE: 58: 4943 0 PCI-MSI-edge ahci AFTER: 58: 4766 334 PCI-MSI-edge ahci 2) read back BIOS_RESET_CPL to verify it is == 3 localhost ~ # iotools mmio_read32 0xfed15da8 0x00000003 3) read PKG power limit from MMIO and verify it is the same as the MSR value localhost ~ # rdmsr 0 0x610 0x0000809600dc8078 localhost ~ # iotools mmio_read32 0xfed159a0 0x00dc8078 localhost ~ # iotools mmio_read32 0xfed159a4 0x00008096 4) read DDR power limit from MSR and verify it is the same as the MMIO value (note this is zero based on current MRC input) localhost ~ # rdmsr 0 0x618 0x0000000000000000 localhost ~ # iotools mmio_read32 0xfed158e0 0x00000000 localhost ~ # iotools mmio_read32 0xfed158e4 0x00000000 Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60544 Reviewed-on: http://review.coreboot.org/4333 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2013-12-01slippy/falco/peppy: Fix SPD GPIO initialization.Aaron Durbin
SPD GPIOs were being read prior to initialization in romstage_common. To fix, pass the copy_spd function to romstage_common, to be called at the appropriate time (after PCH init, before DRAM init). Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58608 Reviewed-on: http://review.coreboot.org/4237 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-11-24haswell: Configure PCH power sharing for ULTDuncan Laurie
This reads PCH power levels via PCODE mailbox and writes the values into the PMSYNC registers as indicated in the BWG. Change-Id: Iddcdef9b7deb6365f874f629599d1f7376c9a190 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/49329 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4143 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-11-24haswell: calibrate 24MHz clock against BCLKAaron Durbin
On haswell ULT systems there is a 24MHz clock that continuously runs when deep package c-states are entered. The 100MHz BCLK is shut down in the lower c-states. When the package wakes back up a conversion formula needs to be applied. The 24MHz calibration is done using the internal PCODE unit. Change-Id: I6be7702fb1de1429273724536f5af9125b98da64 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48292 Tested-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4136 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-11-24haswell: configure c-statesAaron Durbin
The c-states are configured according to the BWG, however the package c-states are disabled as they currently cause platform instability. The exposed ACPI c-state to processor c-state mapping are as follows for ULT boards: ACPI(C1) = MWAIT(C1E) ACPI(C2) = MWAIT(C7S long latency) ACPI(C3) = MWAIT(C10) The non-ULT boards have an expoed c-state mapping: ACPI(C1) = MWAIT(C1E) ACPI(C2) = MWAIT(C3) ACPI(C3) = MWAIT(C7S) Included in this patch is removing the updating of current limit registers as some of the MSRs are different and the proper values are currently unknown. Lastly, some of the MSRs were renamed to match the BWG. Booted 3.8 kernel and used powertop to note package, core, and acpi c-state residency. Change-Id: Ia428d4a4979ba3cba44eb9faa96f74b7d3f22dfe Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48291 Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4133 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-07-11cpu: Fix spellingMartin Roth
Change-Id: I69c46648de0689e9bed84c7726906024ad65e769 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-03haswell: allow for disabled hyperthreadingAaron Durbin
There were assumptions being made in the haswell MP and SMM code which assumed the APIC id space was 1:1 w.r.t. cpu number. When hyperthreading is disabled the APIC ids of the logical processors are all even. That means the APIC id space is sparse. Handle this situation. Change-Id: Ibe79ab156c0a171208a77db8a252aa5b73205d6c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3353 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-10Drop prototype guarding for romccStefan Reinauer
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1] made romcc not choke on function prototypes anymore. This allows us to get rid of a lot of ifdefs guarding __ROMCC__ . [1] http://review.coreboot.org/2424 Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3216 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-07haswell: use asmlinkage for assembly-called funcsAaron Durbin
When the haswell MP/SMM code was developed it was using a coreboot repository that did not contain the asmlinkage macro. Now that the asmlinkage macro exists use it. BUG=None BRANCH=None TEST=Built and booted. Change-Id: I662f1b16d1777263b96a427334fff8f98a407755 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3203 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-21haswell: implement ramstage caching in SMM regionAaron Durbin
Cache the relocated ramstage into the SMM region. There is a reserved region within the final SMM region (TSEG). Use that space to cache the relocated ramstage program. That way, on S3 resume there is a copy that can be loaded quickly instead of accessing the flash. Caching the ramstage in the SMM space is also helpful in that it prevents the OS from tampering with the ramstage program. Change-Id: Ifa695ad1c350d5b504b14cc29d3e83c79b317a62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2806 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: add multipurpose SMM memory regionAaron Durbin
The SMM region is available for multipurpose use before the SMM handler is relocated. Provide a configurable sized region in the TSEG for use before the SMM handler is relocated. This feature is implemented by making the reserved size a Kconfig option. Also make the IED region a Kconfig option as well. Lastly add some sanity checking on the Kconfig options. Change-Id: Idd7fccf925a8787146906ac766b7878845c75935 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2804 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: support for parallel SMM relocationAaron Durbin
The haswell processors support the ability to save their SMM state into MSR space instead of the memory. This feaure allows for parallel SMM relocation handlers as well as setting the same SMBASE for each CPU since the save state memory area is not used. The catch is that in order determine if this feature is available the CPU needs to be in SMM context. In order to implement parallel SMM relocation the BSP enters the relocation handler twice. The first time is to determine if that feature is available. If it is, then that feature is enabled the BSP exits the relocation handler without relocating SMBASE. It then releases the APs to run the SMM relocation handler. After the APs have completed the relocation the BSP will re-enter the SMM relocation handler to relocate its own SMBASE to the final location. If the parallel SMM feature is not available the BSP relocates its SMBASE as it did before. This change also introduces the BSP waiting for the APs to relocate their SMBASE before proceeding with the remainder of the boot process. Ensured both the parallel path and the serial path still continue to work on cold, warm, and S3 resume paths. Change-Id: Iea24fd8f9561f1b194393cdb77c79adb48039ea2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2801 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19haswell: Parallel AP bringupAaron Durbin
This patch parallelizes the AP startup for Haswell-based devices. It does not touch the generic secondary startup code. Instead it provides its own MP support matching up with the Haswell BWG. It seemed to be too much trouble to support the old startup way and this new way. Because of that parallel loading is the only thing supported. A couple of things to note: 1. Micrcode needs to be loaded twice. Once before MTRR and caching is enabled. And a second time after SMM relocation. 2. The sipi_vector is entirely self-contained. Once it is loaded and written back to RAM the APs do not access memory outside of the sipi_vector load location until a sync up in ramstage. 3. SMM relocation is kicked off by an IPI to self w/ SMI set as the destination mode. The following are timings from cbmem with dev mode disabled and recovery mode enabled to boot directly into the kernel. This was done on the baskingridge CRB with a 4-core 8-thread CPU and 2 DIMMs 1GiB each. The kernel has console enabled on the serial port. Entry 70 is the device initialization, and that is where the APs are brought up. With these two examples it looks to shave off ~200 ms of boot time. Before: 1:55,382 2:57,606 (2,223) 3:3,108,983 (3,051,377) 4:3,110,084 (1,101) 8:3,113,109 (3,024) 9:3,156,694 (43,585) 10:3,156,815 (120) 30:3,157,110 (295) 40:3,158,180 (1,069) 50:3,160,157 (1,977) 60:3,160,366 (208) 70:4,221,044 (1,060,677) 75:4,221,062 (18) 80:4,227,185 (6,122) 90:4,227,669 (484) 99:4,265,596 (37,927) 1000:4,267,822 (2,225) 1001:4,268,507 (685) 1002:4,268,780 (272) 1003:4,398,676 (129,896) 1004:4,398,979 (303) 1100:7,477,601 (3,078,621) 1101:7,480,210 (2,608) After: 1:49,518 2:51,778 (2,259) 3:3,081,186 (3,029,407) 4:3,082,252 (1,066) 8:3,085,137 (2,884) 9:3,130,339 (45,202) 10:3,130,518 (178) 30:3,130,544 (26) 40:3,131,125 (580) 50:3,133,023 (1,897) 60:3,133,278 (255) 70:4,009,259 (875,980) 75:4,009,273 (13) 80:4,015,947 (6,674) 90:4,016,430 (482) 99:4,056,265 (39,835) 1000:4,058,492 (2,226) 1001:4,059,176 (684) 1002:4,059,450 (273) 1003:4,189,333 (129,883) 1004:4,189,770 (436) 1100:7,262,358 (3,072,588) 1101:7,263,926 (1,567) Booted the baskingridge board as noted above. Also analyzed serial messages with pcserial enabled. Change-Id: Ifedc7f787953647c228b11afdb725686e38c4098 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2779 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: add romstage_after_car() functionAaron Durbin
There are changes coming to perform more complex tasks after cache-as-ram has been torn down but before ramstage is loaded. Therefore, add the romstage_after_car() function to call after cache-as-ram is torn down. Its responsibility is for loading the ramstage and any other complex tasks. For example, the saving of OS-controlled memory in the resume path has now been moved into C instead of assembly. Change-Id: Ie0c229cf83a9271c8995b31c534c8e5a696b164e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2757 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: romstage: pass stack pointer and MTRRsAaron Durbin
Instead of hard coding the policy for the stack and MTRR values after the cache-as-ram is torn down, allow for the C code to pass those policies back to the cache-as-ram assembly file. That way, ramstage relocation can use a different stack as well as different MTRR policies. Change-Id: Ied024d933f96a12ed0703c51c506586f4b50bd14 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2755 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: unify romstage logicAaron Durbin
This commit pulls in all the common logic for romstage into the Haswell cpu directory. The bits specific to the mainboard still reside under their respective directories. The calling sequence bounces from the cpu directory to mainboard then back to the cpu directory. The reasoning is that Haswell systems use cache-as-ram for backing memory in romstage. The stack is used to allocate structures. However, now changes can be made to the romstage for Haswell and apply to all boards. Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2754 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: adjust CAR usageAaron Durbin
It was found that the Haswell reference code was smashing through the stack into the reference code's heap implementation. The reason for this is because our current CAR allocation is too small. Moreover there are quite a few things to coordinate between 2 code bases to get correct. This commit separates the CAR into 2 parts: 1. MRC CAR usage. 2. Coreboot CAR usage. Pointers from one region can be passed between the 2 modules, but one should not be able to affect the others as checking has been put into place in both modules. The CAR size has effectively been doubled from 0x20000 (128 KiB) to 0x40000 (256KiB). Not all of that increase was needed, but enforcing a power of 2 size only utilizes 1 MTRR. Old CAR layout with a single contiguous stack with the region starting at CONFIG_DCACHE_RAM_BASE: +---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE | MRC global variables | | CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes | +---------------------------------------+ | ROM stage stack | | | | | +---------------------------------------+ | MRC Heap 30000 bytes | +---------------------------------------+ | ROM stage console | | CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes | +---------------------------------------+ | ROM stage CAR_GLOBAL variables | +---------------------------------------+ Offset 0 There was some hard coded offsets in the reference code wrapper to start the heap past the console buffer. Even with this commit the console can smash into the following region depending on what size CONFIG_CONSOLE_CAR_BUFFER_SIZE is. As noted above This change splits the CAR region into 2 parts starting at CONFIG_DCACHE_RAM_BASE: +---------------------------------------+ | MRC Region | | CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes | +---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE | ROM stage stack | | | | | +---------------------------------------+ | ROM stage console | | CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes | +---------------------------------------+ | ROM stage CAR_GLOBAL variables | +---------------------------------------+ Offset 0 Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE, which represents the expected stack usage for the romstage. A marker is checked at the base of the stack to determine if either the stack was smashed or the console encroached on the stack. Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2752 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: enable caching before SMM initializationAaron Durbin
The SMM handler resides in the TSEG region which is far above CONFIG_RAM_TOP (which is the highest cacheable address) before MTRRs are setup. This means that calling initialize_cpus() before performing MTRR setup on the BSP means the SMM handler is copied using uncacheable accesses. Improve the SMM handler setup path by enabling performing MTRR setup on for the BSP before the call to initialize_cpus(). In order to do this the haswell_init() function was split into 2 paths: BSP & AP paths. There is a cpu_common_init() that both call to perform similar functionality. The BSP path in haswell_init() then starts the APs using intel_cores_init(). The AP path in haswell_init() loads microcode and sets up MTRRs. This split will be leveraged for future support of bringing up APs in parallel as well as adhering to the Haswell MP initialization requirements. Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2746 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: move definition of CORE_THREAD_COUNT_MSRAaron Durbin
This just moves the definiton of CORE_THREAD_COUNT_MSR so that future code can utilize it. Change-Id: I15a381090f21ff758288f55dc964b6694feb6064 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2744 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: Add initial support for Haswell platformsAaron Durbin
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore, the southbridge support is included as well. The basis for this code is the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires more attention, but this is a good starting point. This code partially gets up through the romstage just before training memory on a Haswell reference board. Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2616 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>