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>
Using the CPU microcode update script and
Intel's Linux* Processor Microcode Data File
from 2013-02-22
Change-Id: I4585288905cf7374e671894ab37f125220ae535e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2843
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There should be a fixed 10ms wait after sending an INIT IPI. The
previous implementation was just waiting up to 10ms for the IPI to
complete the send. That is not correct. The 10ms is unconditional
according to the documentation. No ill effects were observed with the
previous behavior, but it's important to follow the documentation.
Change-Id: Ib31d49ac74808f6eb512310e9f54a8f4abc3bfd7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2780
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
This patch only applies to CONFIG_MICROCODE_IN_CBFS. The intel microcode
update routine would always walk the CBFS for the microcode file. Then
it would loop through the whole file looking for a match then load the
microcode. This process was maintained for intel_update_microcode_from_cbfs(),
however 2 new functions were exported:
1. const void *intel_microcode_find(void)
2. void intel_microcode_load_unlocked(const void *microcode_patch)
The first locates a matching microcode while the second loads that
mircocode. These new functions can then be used to cache the found
microcode blob w/o having to re-walk the CBFS.
Booted baskingridge board to Linux and noted that all microcode
revisions match on all the CPUs.
Change-Id: Ifde3f3e5c100911c4f984dd56d36664a8acdf7d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2778
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
The save_mrc_data() was previously called conditionally
in the raminit code. The save_mrc_data() function was called
in the non-S3 wake paths. However, the common romstage_common()
code was checking cbmem initialization things on s3 wake. Between
the two callers cbmem_initialize() was being called twice in the
non-s3 wake paths. Moreover, saving of the mrc data was not allowed
when CONFIG_EARLY_CBMEM_INIT wasn't enabled.
Therefore, move the save_mrc_data() to romstage_common. It already has
the knowledge of the wake path. Also remove the CONFIG_EARLY_CBMEM_INIT
requirement from save_mrc_data() as well as the call to cbmem_initialize().
Change-Id: I7f0e4d752c92d9d5eedb8fa56133ec190caf77da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2756
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
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>
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>
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>
The configure_mca() function was hard coding the number of
banks the cpu supported. Query this dynamically so that it
no longer clears only 7 banks.
Change-Id: I33fce8fadc0facd1016b3295faaf3ae90e490a71
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2745
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
This commit adds support for using the SMM modules for haswell-based
boards. The SMI handling was also refactored to put the relocation
handler and permanent SMM handler loading in the cpu directory. All
tseg adjustment support is dropped by relying on the SMM module support
to perform the necessary relocations.
Change-Id: I8dd23610772fc4408567d9f4adf339596eac7b1f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2728
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Haswell CPUs require a FIT table in the firmware. This commit
adds rudimentary support for a FIT table. The number of entries
in the table is based on a configuration option. The code only
generates a type 0 entry. A follow-on tool will need to be developed
to populate the FIT entries as well as checksumming the table.
Verified image has a FIT pointer and table when option is selected.
Change-Id: I3a314016a09a1cc26bf1fb5d17aa50853d2ef4f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2642
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds microcode ffff000a and the CPUIDs for ULT.
Change-Id: I341c1148a355d8373b31032b9f209232bd03230a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2647
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The IA32_ENERGY_PERFORMANCE_BIAS MSR can only be read or written
to if the CPU supports it. The support is indicated by ECX[3] for
cpuid(6). Without this guard, some Haswell parts would GP# fault
in this routine.
No more GP# while running on haswell CRBs.
Change-Id: If41e1e133e5faebb3ed578cba60743ce7e1c196f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2639
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
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>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
And move the corresponding #define to speedstep.h
Change-Id: I8c884b8ab9ba54e01cfed7647a59deafeac94f2d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2339
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a comment explaining that the existing lock bit logic is correct
and "as designed" even though the manual states otherwise. This way
people don't have to "just know" what is going on.
Change-Id: I14e6763abfe339e034037b73db01d4ee634bb34d
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: http://review.coreboot.org/2326
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Updating microcode on several threads in a core at once
can be harmful. Hence add a spinlock to make sure that
does not happen.
Change-Id: I0c9526b6194202ae7ab5c66361fe04ce137372cc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1778
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are some function dependancies that didn't work
when MAX_CPU was set to 1 and the build would fail.
Change-Id: I033a42056f7b48a40316e03772ed89ad9cb013fe
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1819
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Adding an entry for 0x306a0 will make sure that all
CPUs with CPUIDs 0x306aX will execute the driver (analog to
Sandybridge behavior)
Change-Id: I0353f3a48ecfd41274fdf6ee302c7d34482f1b5b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1783
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The VMX MSR may come up with random values and needs to be
initialized to zero. This was done incorrectly in finalize_smm.
It must be done on a per core basis in the general CPU init.
This touches all Sandybridge and Ivybridge configs.
Change-Id: I015352d0f8e2ebe55ac0a5e9c5bbff83bd2ff86b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The MSR for VMX can start with a random value and needs to be
cleared by coreboot. I am reverting this change, as
it handles almost everything and doing a follow-on change to fix
the improper clearing of the MSR.
Change-Id: Ibad7a27b03f199241c52c1ebdd2b6d4e81a18a4e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1793
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The reporting of cores and threads in the system was a bit
ambiguous. This patch makes it clearer.
Change-Id: Ia05838a53f696fbaf78a1762fc6f4bf348d4ff0e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1786
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To allow easy experimentation with thermals, leave power control
registers unlocked.
Change-Id: Ia53065f3f220c2faed58e7d53e60c3f169ae58ec
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://review.coreboot.org/1688
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
All of these capabilities exist on all CPUs supported on
this socket.
Change-Id: I54f34e48e34bb6ab5b9954ab7ece8c2c3a1a8e67
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1664
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds proper support for turbo and super-low-frequency modes.
Calculation of the p-states has been rewritten and moved into an
extra file speedstep.c so it can be used for non-acpi stuff like
EMTTM table generation.
It has been tested with a Core2Duo T9400 (Penryn) and a Core Duo T2300
(Yonah) processor.
Change-Id: I5f7104fc921ba67d85794254f11d486b6688ecec
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We parsed the MSR the wrong way, and didn't support some valid values.
Change-Id: Ia42e3de05dd76b6830aaa310ec82031d36def3a0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We had only some MSR definitions in there, which are used in speedstep
related code. I think speedstep.h is the better and less confusing place
for these.
Change-Id: I1eddea72c1e2d3b2f651468b08b3c6f88b713149
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
