summaryrefslogtreecommitdiff
path: root/src/southbridge/intel/lynxpoint
diff options
context:
space:
mode:
authorAaron Durbin <adurbin@chromium.org>2013-02-13 11:22:25 -0600
committerRonald G. Minnich <rminnich@gmail.com>2013-03-21 22:56:21 +0100
commit738af675d1b29847112f32b3fb2ac2524bb7c4ca (patch)
tree4c2f0b4bd10151b4bc717dc9c43e205b93960cd5 /src/southbridge/intel/lynxpoint
parent159f2ef03a59607c58c0474f9b2941b03710b498 (diff)
haswell: support for parallel SMM relocation
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>
Diffstat (limited to 'src/southbridge/intel/lynxpoint')
0 files changed, 0 insertions, 0 deletions