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.
CQ-DEPEND=CL:172643
CQ-DEPEND=CL:*146397
CQ-DEPEND=CL:*146398
CQ-DEPEND=CL:*146435
CQ-DEPEND=CL:*146445
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>
The CPU_ADDR_BITS was being unconditionally set.
Don't do that.
BUG=None
BRANCH=None
TEST=Built bayleybay and can now set CPU_ADDR_BITS properly.
Change-Id: Idbc63328fade8f5f05f7f46282139b86e6694989
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169711
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Reviewed-on: https://gerrit.chromium.org/gerrit/63793
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
These are needed to enable workarounds/features on specific
CPU types and stepping. The older northbridge function and
defines from sandybridge/ivybridge are removed.
BUG=chrome-os-partner:20772
BRANCH=none
TEST=emerge-falco chromeos-coreboot-falco
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>
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
BUG=chrome-os-partner:20604
BRANCH=none
TEST=manual:
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
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).
BUG=chrome-os-partner:20162.
TEST=Manual. Test on peppy board with non-zero SPD GPIOs, verify correct
SPD is selected.
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
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
BUG=chrome-os-partner:19928
BRANCH=none
TEST=manual: enter recovery with crossystem recovery_request=193
Change-Id: Ic927c69a95a2114e29c343f0dcc28374266db394
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57470
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When an INIT# is delivered to the CPU the CPU starts
executing from the reset vector. However, the internal state
is maintained. Therefore, check for such a condition and
reset the system.
BUG=chrome-os-partner:19355
BRANCH=None
TEST=Issues 'apreset warm' on the EC console. INIT# is sent and
CPU notices it's not a clean reset and forces one. No hangs.
Change-Id: I71229e0e5015ba8c60f5989c533268604ecc1ecc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57111
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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.
BUG=chrome-os-partner:19699
BRANCH=None
TEST=Used HT disabled part on WTM2. No more spontaneous reboots.
Change-Id: Ia4e3aa7456092e0ac0ea0ef16f10ba638a3e6dbe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56824
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The haswell code allows for vboot ramstage verification.
However, that code path relies on accessing global cache-as-ram
variables after cache-as-ram is torn down. In order to avoid
that situation enable cache-as-ram migration.
cbmemc_reinit() no longer needs to be called from romstage
because it is invoked automatically by the cache-as-ram
migration infrastructure.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: I1a8de380a70d8b375ba138da3219408ef5c823b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51390
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
BUG=None
BRANCH=None
TEST=Built
Change-Id: I9d65a8e67ffdee5fd813f7554ecafbdf37b93af0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51163
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
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
BUG=none
TEST=boot tested on Link
BRANCH=none
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>
Reviewed-on: https://gerrit.chromium.org/gerrit/50723
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
BUG=none
TEST=boot tested on snow+link
BRANCH=none
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50721
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
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: I2ebd567c7c40cf5013f2c1d7e3b381171ad17a4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50454
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Instead of using the local apic timer for udelay() use the tsc.
That way SMM, romstage, and ramstage all use the same delay
functionality.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Iac35eb02b424b54e490b4fdaa2fc74f35066db27
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
With the XHCI controller enabled we no longer hang the
system when dropping into a package C-state so remove
the code that was disabling it.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=boot wtm2 and verify package C2 residency with powertop
Change-Id: Icd60488fd2506dac04fb6ec96a77bec265b10d8c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50355
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current microcode blobs contain both ULT and non-ULT
revisions. Only include one or the other based off of the
CONFIG_INTEL_LYNXPOINT_LP Kconfig option.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: I3e4e41d4cd727b1a974361fb469267e6f6022d5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50318
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Haswell ULT devices have a 24MHz package-level counter. Use
this counter to provide a timer_monotonic_get() implementation.
Change-Id: I72dce5976acd44376bc8ac1587dcb3c3d5b9f1e7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49749
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This reads PCH power levels via PCODE mailbox and writes the
values into the PMSYNC registers as indicated in the BWG.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: boot on WTM2 and read PMSYNC registers and
compare to the values read from PCU
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>
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.
BUG=None
BRANCH=None
TEST=Booted but as we have package c-states disabled this change doesn't
have much of an impact at the moment.
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>
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.
BUG=None
BRANCH=None
TEST=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>
The recommendation from Intel is to report each core as a
separate logical domain in the _PSD table.
This goes against the recommendation in the ACPI specification
because all of these cores are on the same package and share a
VR so they will do voltage transitions together.
The reasoning is that with a larger number of logical processors
the P-state often ramps too quickly resulting in higher power
consumption. By exposing each core as a separate domain the OS
can manage them individually allowing the socket to select the
optimum frequency.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: boot on wtm2, read and verify the ACPI _PSD table in
the SSDT and ensure each core is in a separate domain.
$ cat /sys/firmware/acpi/tables/SSDT > /tmp/SSDT
$ iasl -d /tmp/SSDT
Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000000,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000001,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU2, 0x02, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000002,
0x000000FE,
0x00000001
}
})
}
Processor (\_PR.CPU3, 0x03, 0x00000000, 0x00)
{
Name (_PSD, Package (0x01)
{
Package (0x05)
{
0x05,
0x00,
0x00000003,
0x000000FE,
0x00000001
}
})
}
Change-Id: I5ef41b6ead4d88e9ba117003293dbc629c376803
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If ROM caching is selected the haswell CPU initialization code
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I75424bb75174bfeca001468c3272e6375e925122
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3016
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MP code on haswell was mirroring the BSPs MTRRs. In addition it
was cleaning up the ROM cache so that the MTRR register values were
the same once the OS was booted. Since the hyperthread sibling of
the BSP was going through this path the ROM cache was getting torn
down once the hyperthread was brought up.
That said, there was no differnce in observed boot time keeping the
ROM cache enabled.
Change-Id: I2a59988fcfeea9291202c961636ea761c2538837
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3008
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The haswell code was using the old assumption of which MTRR
was used for the ROM cache. Now that there is an API for doing
this use it as the old assumption is no longer valid.
Change-Id: I59ef897becfc9834d36d28840da6dc4f1145b0c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3007
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Previously southbridge_smm_init() was provided that did both
the clearing of the SMM state and enabling SMIs. This is
troublesome in how haswell machines bring up the APs. The BSP
enters SMM once to determine if parallel SMM relocation is possible.
If it is possible the BSP releases the APs to do SMM relocation.
Normally, after the APs complete the SMM relocation, the BSP would then
re-enter the relocation handler to relocate its own SMM space.
However, because SMIs were previously enabled it is possible for an SMI
event to occur before the APs are complete or have entered the
relocation handler. This is bad because the BSP will turn off parallel
SMM save state. Additionally, this is a problem because the relocation
handler is not written to handle regular SMIs which can cause an
SMI storm which effectively looks like a hung machine. Correct these
issues by turning on SMIs after all the SMM relocation has occurred.
Change-Id: Id4f07553b110b9664d51d2e670a14e6617591500
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Take the vboot path in romstage. This will complete the haswell
support for vboot firmware selection.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as
well by choosing the RO path.
Change-Id: Ie2b0a34e6c5c45e6f0d25f77a5fdbaef0324cb09
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2856
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Convert the existing haswell code to support reloctable ramstage
to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as
this option is a hard requirement for relocatable ramstage.
Aside from converting a few new API calls, a cbmem_top()
implementation is added which is defined to be at the begining of the
TSEG region. Also, use the dynamic cbmem library for allocating a
stack in ram for romstage after CAR is torn down.
Utilizing dynamic cbmem does mean that the cmem field in the gnvs
chromeos acpi table is now 0. Also, the memconsole driver in the kernel
won't be able to find the memconsole because the cbmem structure
changed.
Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: I9bb60bdc46f69db85487ba923e62315f6e5352f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2845
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: Icaf0e39978daa9308cc2f0c4856d99fb6b7fdffa
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2844
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
for latest URL of their microcode tar ball
Change-Id: I3da2bdac4b2ca7d3f48b20ed389f6a47275d24fe
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2842
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These base addresses are used in several places and it
is helpful to have one location that is reading it.
Change-Id: Ibf589247f37771f06c18e3e58f92aaf3f0d11271
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2812
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The RESET_ON_INVALID_RAMSTAGE_CACHE option indicates what to do
when the ramstage cache is found to be invalid on a S3 wake. If
selected the system will perform a system reset on S3 wake when the
ramstage cache is invalid. Otherwise it will signal to load the
ramstage from cbfs.
Change-Id: I8f21fcfc7f95fb3377ed2932868aa49a68904803
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2807
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
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>
The TSEG region is accessible until the SMM handler is relocated
to that region. Set the region as cacheable in romstage so that it
can be used for other purposes with fast access.
Change-Id: I92b83896e40bc26a54c2930e05c02492918e0874
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2803
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
Now that there is a way to disseminate the presence of s3 wake more
formally use that instead of hard coded pointers in memory and stashing
magic values in device registers. The northbridge code picks up the
field's presence in the romstage_handoff structure and sets up the
acpi_slp_type variable accordingly.
Change-Id: Ida786728ce2950bd64610a99b7ad4f1ca6917a99
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2799
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the functions called from assembly assume the standard
x86 32-bit ABI of passing all arguments on the stack. However,
that calling ABI can be changed by compiler flags. In order to
protect against the current implicit calling convention annotate
the functions called from assembly with the cdecl function
attribute. That tells the compiler to use the stack based parameter
calling convention.
Change-Id: I83625e1f92c6821a664b191b6ce1250977cf037a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2794
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that CONFIG_RELOCTABLE_RAMSTAGE is available support it on
Haswell-based systems. This patch is comprised of the following changes:
1. Ensure that memory is not preserved when a relocatable ramstage is
enabled. There is no need.
2. Pick the proper stack to use after cache-as-ram is torn down. When
the ramstage is relocatable, finding a stack to use before vectoring
into ramstage is impossible since the ramstage is a black box with an
unknown layout.
Change-Id: I2a07a497f52375569bae9c994432a8e7e7a40224
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2793
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The current ramstage code contains uses of symbols that cause issues
when the ramstage is relocatable. There are 2 scenarios resolved by this
patch:
1. Absolute symbols that are actually sizes/limits. The symbols are
problematic when relocating a program because there is no way to
distinguish a symbol that shouldn't be relocated and one that can.
The only way to handle these symbols is to write a program to post
process the relocations and keep a whitelist of ones that shouldn't
be relocated. I don't believe that is a route that should be taken
so fix the users of these sizes/limits encoded as absolute symbols
to calculate the size at runtime or dereference a variable in memory
containing the size/limit.
2. Absoulte symbols that were relocated to a fixed address. These
absolute symbols are generated by assembly files to be placed at a
fixed location. Again, these symbols are problematic because one
can't distinguish a symbol that can't be relocated. The symbols
are again resolved at runtime to allow for proper relocation.
For the symbols defining a size either use 2 symbols and calculate the
difference or provide a variable in memory containing the size.
Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2789
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: I853e381240b539b204c653404ca3d46369109219
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2846
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
