summaryrefslogtreecommitdiff
path: root/src/cpu/x86/mtrr
AgeCommit message (Collapse)Author
2020-05-08cpu/x86/mtrr: Replace GPLv2 long form headers with SPDX headerElyes HAOUAS
Change-Id: I9d97cac214f04604f956cd9eee1e281b75c93645 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41134 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-06treewide: Move "is part of the coreboot project" line in its own commentPatrick Georgi
That makes it easier to identify "license only" headers (because they are now license only) Script line used for that: perl -i -p0e 's|/\*.*\n.*This file is part of the coreboot project.*\n.*\*|/* This file is part of the coreboot project. */\n/*|' # ...filelist... Change-Id: I2280b19972e37c36d8c67a67e0320296567fa4f6 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41065 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-05-01cpu/x86/mtrr/earlymtrr: Validate MTRR argumentsRaul E Rangel
The AMD64 Architecture Programmer's Manual, Volume 2: Systems Programming says the following about variable MTRRs: Variable Range Size and Alignment. The size and alignment of variable memory-ranges (MTRRs) and I/O ranges (IORRs) are restricted as follows: * The boundary on which a variable range is aligned must be equal to the range size. For example, a memory range of 16 Mbytes must be aligned on a 16-Mbyte boundary (i.e., naturally aligned). * The range size must be a power of 2 (2^n , 52 > n > 11), with a minimum allowable size of 4 Kbytes. For example, 4 Mbytes and 8 Mbytes are allowable memory range sizes, but 6 Mbytes is not allowable. Print out errors if these conditions are violated. I didn't assert since `set_var_mtrr` can be used in boot block before the serial console is enabled. BUG=b:147042464 TEST=Boot trembyle and see MTRR errors: MTRR Error: base 0xcc800000 must be aligned to size 0x1000000 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I8b8c734c7599bd89cf9f212ed43c2dd5b2c8ba7b Reviewed-on: https://review.coreboot.org/c/coreboot/+/40762 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-01src: Remove unused 'include <cpu/x86/cache.h>'Elyes HAOUAS
Change-Id: I2bf1eb87bb5476dd77b5a56dfe8846e82d414523 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40666 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-29src/cpu/x86/mtrr/earlymtrr: Add clear_all_var_mtrrRaul E Rangel
Picasso does not define the state of variable MTRRs on boot. Add a helper function to clear all MTRRs. BUG=b:147042464 TEST=Build trembyle Signed-off-by: Raul E Rangel <rrangel@chromium.org> Change-Id: I21b887ce12849a95ddd8f1698028fb6bbfb4a7f6 Reviewed-on: https://review.coreboot.org/c/coreboot/+/40764 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-04-04src/cpu: Use SPDX for GPL-2.0-only filesAngel Pons
Done with sed and God Lines. Only done for C-like code for now. Change-Id: I2adf28d805fe248d55a9514f74c38280c0ad9a78 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
2019-11-03cpu/x86/mtrr/xip_cache.c: Fix inconsistent messageAngel Pons
Change-Id: Ic99e61632664f86cc12507f2ddffa364fdd79202 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36585 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-02cpu/x86: Add a prog_run hook to set up caching of XIP stagesArthur Heymans
Some platforms lack a non-eviction mode and therefore caching the whole ROM to speed up XIP stages can be dangerous as it could result in eviction if too much of the ROM is being accessed. The solution is to only cache a region, about the size of the stage that the bootblock is about to load: verstage and/or romstage. TODO: now a limit of 256KiB is set for the total amount of cache that can be used. This should fit most use cases for the time being. Change-Id: I94d5771a57ffd74d53db3e35fe169d77d7fbb8cd Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35993 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2019-09-28cpu,device/: Remove some __SIMPLE_DEVICE__ and __ROMCC__ useKyösti Mälkki
Change-Id: I62d7450c8e83eec7bf4ad5d0709269a132fd0499 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35649 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-09-10AUTHORS: Move src/cpu copyrights into AUTHORS fileMartin Roth
As discussed on the mailing list and voted upon, the coreboot project is going to move the majority of copyrights out of the headers and into an AUTHORS file. This will happen a bit at a time, as we'll be unifying license headers at the same time. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Id6070fb586896653a1e44951a6af8f42f93b5a7b Reviewed-on: https://review.coreboot.org/c/coreboot/+/35184 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-08-08cpu/x86/mtrr: Replace CONFIG_CPU_ADDR_BITS with cpu_phys_address_size()Subrata Banik
This patch helps to generate correct MTRR mask value while using set_var_mtrr(). example: set_var_mtrr(1, 0x99000000, 16*MiB, WP) without CL : 0x0000000099000005: PHYBASE2: Address = 0x0000000099000000, WP 0x0000000fff000800: PHYMASK2: Length = 0x0000007001000000, Valid with CL : 0x0000000099000005: PHYBASE1: Address = 0x0000000099000000, WP 0x0000007fff000800: PHYMASK1: Length = 0x0000000001000000, Valid Change-Id: Ie3185dd8d4af73ec0605e19e9aa4223f2c2ad462 Signed-off-by: Subrata Banik <subrata.banik@intel.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34753 Reviewed-by: V Sowmya <v.sowmya@intel.com> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-06-22src/cpu: Use 'include <stdlib.h>' when appropriateElyes HAOUAS
Change-Id: I44346594bc106eed73a1268b82f026b69e5f4512 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32821 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2019-06-21cpu: Add missing #include <commonlib/helpers.h>Elyes HAOUAS
ALIGN and ALIGN_UP needs 'helpers.h' Change-Id: Ib3a9e0d6caff69f4b0adb54364b47cc6ac52a610 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33658 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2019-05-29cpu/x86/mtrr: Assert that MSR arrays are fully initializedJacob Garber
The initialization logic for the fixed_msrs and msr_index arrays depends on the contents of the fixed MTRR descriptor. However, Coverity is unable to check these values and believes (incorrectly) that the arrays may not be entirely initialized. An assert was added in commit b28025a434 to ensure that one of the loops is entered, but it is simplest to just check that msr_num has iterated over the entire array after the loops are over. This also acts as a sanity check that the values in the MTRR descriptor were hardcoded correctly. Change-Id: Ia573792f74aa6ea5e659c1e2253f112184fbb0a5 Signed-off-by: Jacob Garber <jgarber1@ualberta.ca> Found-by: Coverity CID 1370582 Reviewed-on: https://review.coreboot.org/c/coreboot/+/33048 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Lance Zhao <lance.zhao@gmail.com>
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06src: Drop unused include <arch/acpi.h>Elyes HAOUAS
Change-Id: I1f44ffeb54955ed660162a791c6281f292b1116a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31715 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2019-02-28cpu/x86/mtrr/mtrr.c:Avoid static scan false positiveRichard Spiegel
Static scan does not know the contents of the fixed MTRR descriptor, so it has no way to eval the result for variable num_ranges. If num_ranges is less or equal to 0, the for loop will not be entered, and the values of fixed_msrs will not be set. Asserting that num_ranges is greater than 0 ensures the loop enters at least once. BUG=b:112253891 TEST=build grunt Change-Id: Ieec0ac432c745bde4b1700539c266625da6cfd77 Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-on: https://review.coreboot.org/c/31527 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2018-11-23soc/intel/common: Bring DISPLAY_MTRRS into the lightNico Huber
Initially, I wanted to move only the Kconfig DISPLAY_MTRRS into the "Debug" menu. It turned out, though, that the code looks rather generic. No need to hide it in soc/intel/. To not bloat src/Kconfig up any further, start a new `Kconfig.debug` hierarchy just for debug options. If somebody wants to review the code if it's 100% generic, we could even get rid of HAVE_DISPLAY_MTRRS. Change-Id: Ibd0a64121bd6e4ab5d7fd835f3ac25d3f5011f24 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/29684 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-11-12src: Remove unneeded include "{arch,cpu}/cpu.h"Elyes HAOUAS
Change-Id: I17c4fc4e3e2eeef7c720c6a020b37d8f7a0f57a4 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29300 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-04-11Correct "MTTR" to "MTRR"Jonathan Neuschäfer
The term MTRR has been misspelled in a few places. Change-Id: I3e3c11f80de331fa45ae89779f2b8a74a0097c74 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/25568 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-04-11cpu/x86/mtrr: Fix broken output ("indexis")Jonathan Neuschäfer
The missing space resulted in the following broken output: > ERROR: Not enough MTRRs available! MTRR indexis 10 with 10 MTTRs in total. Put the string on one line to make it obvious where the spaces should be and to help users of grep. Change-Id: Ib9e8109d88c1bf38e7dda3dbf1c8d47fb0d23265 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/25567 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-04-09cpu/x86/mtrr: Use single code path with/without holesNico Huber
Now that calc_var_mtrrs_with_hole() always chooses the optimal allocation, there is no need for calc_var_mtrrs_without_hole() any more. Drop it and all the logic to decide which one to call. Tests performed compared to "upstream" (before "cpu/x86/mtrr: Optimize hole carving strategy") on a Lenovo/X200s with 48MiB GFX stolen memory. 2GiB total RAM: 3 MTRRs saved MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x000000007ac00000 size 0x7ab40000 type 6 0x000000007ac00000 - 0x00000000d0000000 size 0x55400000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 upstream: MTRR: Removing WRCOMB type. WB/UC MTRR counts: 7/8 > 6. MTRR: default type WB/UC MTRR counts: 4/7. MTRR: WB selected as default type. MTRR: 0 base 0x000000007ac00000 mask 0x0000000fffc00000 type 0 MTRR: 1 base 0x000000007b000000 mask 0x0000000fff000000 type 0 MTRR: 2 base 0x000000007c000000 mask 0x0000000ffc000000 type 0 MTRR: 3 base 0x0000000080000000 mask 0x0000000f80000000 type 0 patched: MTRR: default type WB/UC MTRR counts: 7/5. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6 MTRR: 1 base 0x000000007ac00000 mask 0x0000000fffc00000 type 0 MTRR: 2 base 0x000000007b000000 mask 0x0000000fff000000 type 0 MTRR: 3 base 0x000000007c000000 mask 0x0000000ffc000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1 4GiB total RAM: no MTRRs saved but slightly more accurate alignment MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x000000007cc00000 size 0x7cb40000 type 6 0x000000007cc00000 - 0x00000000d0000000 size 0x53400000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000017c000000 size 0x7c000000 type 6 upstream: MTRR: default type WB/UC MTRR counts: 7/6. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6 MTRR: 1 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0 MTRR: 2 base 0x000000007d000000 mask 0x0000000fff000000 type 0 MTRR: 3 base 0x000000007e000000 mask 0x0000000ffe000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1 MTRR: 5 base 0x0000000100000000 mask 0x0000000f00000000 type 6 patched: MTRR: default type WB/UC MTRR counts: 7/6. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6 MTRR: 1 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0 MTRR: 2 base 0x000000007d000000 mask 0x0000000fff000000 type 0 MTRR: 3 base 0x000000007e000000 mask 0x0000000ffe000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1 MTRR: 5 base 0x0000000100000000 mask 0x0000000f80000000 type 6 8GiB total RAM: possible savings but WB still beats UC MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x000000007cc00000 size 0x7cb40000 type 6 0x000000007cc00000 - 0x00000000d0000000 size 0x53400000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000027c000000 size 0x17c000000 type 6 upstream: MTRR: Removing WRCOMB type. WB/UC MTRR counts: 7/11 > 6. MTRR: default type WB/UC MTRR counts: 4/10. MTRR: WB selected as default type. MTRR: 0 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0 MTRR: 1 base 0x000000007d000000 mask 0x0000000fff000000 type 0 MTRR: 2 base 0x000000007e000000 mask 0x0000000ffe000000 type 0 MTRR: 3 base 0x0000000080000000 mask 0x0000000f80000000 type 0 patched: MTRR: Removing WRCOMB type. WB/UC MTRR counts: 7/7 > 6. MTRR: default type WB/UC MTRR counts: 4/6. MTRR: WB selected as default type. MTRR: 0 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0 MTRR: 1 base 0x000000007d000000 mask 0x0000000fff000000 type 0 MTRR: 2 base 0x000000007e000000 mask 0x0000000ffe000000 type 0 MTRR: 3 base 0x0000000080000000 mask 0x0000000f80000000 type 0 Change-Id: Iedf7dfad61d6baac91973062e2688ad866f05afd Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21916 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-04-09cpu/x86/mtrr: Optimize hole carving strategyNico Huber
For WB ranges with unaligned end, we try to align the range up and carve a hole out of it which might reduce MTRR usage. Instead of trying an arbitrary alignment, we try all and choose an optimal one. Also, restructure the cases when we try to find a hole. Which leads us to the following three: 1. WB range is last in address space: Aligning up, up to the next power of 2, may gain us something. 2. The next range is of type UC: We may align up, up to the _end_ of the next range. If there is a gap between the current and the next range, it would have been covered by the default type UC anyway. 3. The next range is not of type UC: We may align up, up to the _base_ of the next range. This is the end of the gap, if there is one. Change-Id: Iefb064ce8c4f293490a19dd46054b966c63bde44 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21915 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-02-16x86/mtrr: Enable Rd/WrDram mod in AMD fixed MTRRsMarshall Dawson
AMD's fixed MTRRs have RdDram and WrDram bits that route memory accesses to DRAM vs. MMIO. These are typically hidden for normal operation by clearing SYS_CFG[19] (MtrrFixDramModEn). According to BKDGs and AMD64 Programmer's Manual vol 2, this bit is clear at reset, should be set for configuration during POST, then cleared for normal operation. Attempting to modify the RdDram and WrDram settings without unhiding them causes a General Protection Fault. Add functions to enable and disable MtrrFixDramModEn. Unhide/hide as necessary when copying or writing the fixed MTRRs. Finally, modify sipi_vector.S to enable the bits prior to writing the fixed MTRRs and disable when complete. This functionality is compiled out on non-AMD platforms. BUG=b:68019051 TEST=Boot Kahlee, check steps with HDT Change-Id: Ie195131ff752400eb886dfccc39b314b4fa6b3f3 Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com> Reviewed-on: https://review.coreboot.org/23722 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-10-16cpu/x86/mtrr: Remove var-MTRR alignment optimizationNico Huber
The code used to split up ranges >64MiB into 64MiB-aligned and unaligned parts. However in its current state the next step, calc_var_mtrr_range(), results in the same allocation, no mat- ter if we split the range up before. So just drop the split-up. Change-Id: I5481fbf3168cdf789879064077b63bbfcaf122c9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21914 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-07-13src/cpu: add IS_ENABLED() around Kconfig symbol referencesMartin Roth
Some of these can be changed from #if to if(), but that will happen in a follow-on commmit. Change-Id: I4e5e585c3f98a129d89ef38b26d828d3bfeac7cf Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/20356 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2017-06-13cpu/x86/mtrr: fail early if solution exceeds available MTRRsAaron Durbin
If an MTRR solution exceeds the number of available MTRRs don't attempt to commit the result. It will just GP fault with the MSR write to an invalid MSR address. Change-Id: I5c4912d5244526544c299c3953bca1bf884b34d5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/20163 Reviewed-by: Youness Alaoui <snifikino@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-03-16cpu/x86: Wrap lines at 80 columnsLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: line over 80 characters TEST=Build and run on Galileo Gen2 Change-Id: I56ea28826963403dc0719f40c13782c56dc97feb Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18844 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16cpu/x86: Add int to unsignedLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' TEST=Build and run on Galileo Gen2 Change-Id: I97bbe8ba19680bdb99fa38daa5e18b440c338576 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18843 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16cpu/x86: Use tabs for indentLee Leahy
Fix the following error and warning detected by checkpatch.pl: ERROR: code indent should use tabs where possible WARNING: please, no spaces at the start of a line TEST=Build and run on Galileo Gen2 Change-Id: Ie6e4dd4c3eb0d2c44ecd008740dfc348d496fe78 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18841 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-22src/cpu/x86: Update/Add license headers to all filesMartin Roth
Change-Id: I436bf0e7db008ea78e29eaeef10bea101e6c8922 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18405 Tested-by: build bot (Jenkins) Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2016-11-12cpu/x86/mtrr: allow temporary MTRR range during corebootAaron Durbin
Certain platforms have a poorly performing SPI prefetcher so even if accessing MMIO BIOS once the fetch time can be impacted. Payload loading is one example where it can be impacted. Therefore, add the ability for a platform to reconfigure the currently running CPU's variable MTRR settings for the duration of coreboot's execution. The function mtrr_use_temp_range() is added which uses the previous MTRR solution as a basis along with a new range and type to use. A new solution is calculated with the updated settings and the original solution is put back prior to exiting coreboot into the OS or payload. Using this patch on apollolake reduced depthcharge payload loading by 75 ms. BUG=chrome-os-partner:56656,chrome-os-partner:59682 Change-Id: If87ee6f88e0ab0a463eafa35f89a5f7a7ad0fb85 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17371 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-09-12cpu/x86: Move fls() and fms() to mtrr.hRizwan Qureshi
Move the funtion to find most significant bit set(fms) and function to find least significant bit set(fls) to a common place. And remove the duplicates. Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53 Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com> Reviewed-on: https://review.coreboot.org/16525 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-22cpu/x86/mtrr: correct variable MTRR calculation around 1MiB boundaryAaron Durbin
The fixed MTRRs cover the range [0:1MiB). While calculating the variable MTRR usage the 1MiB boundary is checked such that an excessive number of MTRRs aren't used because of unnatural alignment at the low end of the physical address space. Howevever, those checks weren't inclusive of the 1MiB boundary. As such a variable MTRR could be used for a range which is actually covered by the fixed MTRRs when the end address is equal to 1MiB. Likewise, if the starting address of the range lands on the 1MiB boundary then more variable MTRRs are calculated in order to meet natural alignment requirements. Before: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0 0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6 0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0 0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1 0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0 0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6 CPU physical address size: 39 bits MTRR: default type WB/UC MTRR counts: 7/17. MTRR: WB selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007ffff00000 type 0 MTRR: 1 base 0x000000007b800000 mask 0x0000007fff800000 type 0 MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0 MTRR: 3 base 0x0000000080000000 mask 0x0000007fe0000000 type 0 MTRR: 4 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0 MTRR: 5 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1 MTRR: 6 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0 After: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0 0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6 0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0 0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1 0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0 0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6 CPU physical address size: 39 bits MTRR: default type WB/UC MTRR counts: 6/8. MTRR: WB selected as default type. MTRR: 0 base 0x000000007b800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x000000007c000000 mask 0x0000007ffc000000 type 0 MTRR: 2 base 0x0000000080000000 mask 0x0000007fe0000000 type 0 MTRR: 3 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0 BUG=chrome-os-partner:55504 Change-Id: I7feab38dfe135f5e596c9e67520378a406aa6866 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15780 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-04-28soc/intel/apollolake: Add cache for BIOS ROMAndrey Petrov
Enable caching of BIOS region with variable MTRR. This is most useful if enabled early such as in bootblock. Change-Id: I39f33ca43f06fce26d1d48e706c97f097e3c10f1 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14480 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-03-18mtrr: Define a function for obtaining free var mtrrFurquan Shaikh
Instead of hard-coding var mtrr numbers in code, use this function to identify the first available variable mtrr. If no such mtrr is available, the function will return -1. Change-Id: I2a1e02cdb45c0ab7e30609641977471eaa2431fd Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14115 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-16cpu/x86: compile earlymtrr.c code for romstage as wellAndrey Petrov
In order to make this work earlymtrr.c needed to be removed from intel/truxton/romstage.c. It's not a ROMCC board so there's no reason to be including .c files. Change-Id: If4f5494a53773454b97b90fb856f7e52cadb3f44 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14094 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-16cpu/x86/mtrr: remove early_mtrr_* functionsAaron Durbin
I see no user of any of this code. Remove it. Change-Id: I776cd3d9ac6578ecb0fe6d98f15611e4463afb7a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14098 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-16cpu/x86/mtrr: move cache_ramstage() to its only userAaron Durbin
The Intel i3100 northbridge code is the only user of cache_ramstage(). Therefore, place it next to the sole consumer. Change-Id: If15fb8d84f98dce7f4de9e089ec33035622d8f74 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14097 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-08cpu/x86/mtrr: add helper function to detect variable MTRRsAaron Durbin
The current MTRR API doesn't allow one to detect variable MTRRs along with handling fixed MTRRs in one function call. Therefore, add x86_setup_mtrrs_with_detect() to perform the same actions as x86_setup_mtrrs() but always do the dynamic detection. Change-Id: I443909691afa28ce11882e2beab12e836e5bcb3d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13935 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-02-02src: Fix various spelling and whitespace issues.Martin Roth
This fixes some spelling and whitespace issues that I came across while working on various things in the tree. There are no functional changes. Change-Id: I33bc77282f2f94a1fc5f1bc713e44f72db20c1ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13016 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@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-10-15cpu/x86/mtrr: Add MTRR index and total MTRRs to error messagePaul Menzel
Change-Id: I626a11c17c9d05c174c507d50684e498c8604cbc Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11905 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de>
2015-10-15cpu/mtrr.h: Fix macro names for MTRR registersAlexandru Gagniuc
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR, we also remove the _MSR suffix, as they are, by definition, MSRs. Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/11761 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-07-12Verify Kconfigs symbols are not zero for hex and int type symbolsMartin Roth
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead check to make sure they're defined and not zero. In some cases, zero might be a valid value, but it didn't look like zero was valid in these cases. Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10886 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-12Change #ifdef and #if defined CONFIG_ bools to #if IS_ENABLED()Martin Roth
Kconfigs symbols of type bool are always defined, and can be tested with the IS_ENABLED() macro. symbol type except string. Change-Id: Ic4ba79f519ee2a53d39c10859bbfa9c32015b19d Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10885 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-09-25x86/mtrr: Enable MTRR's before enabling cachingIsaac Christensen
Fix up the following commit by enabling the MTRR's before enabling caching. 7756fe7 x86: Minimize work done with the caches disabled in mtrr functions. Also fix two typos in comments. Change-Id: If751b815f9dab781fc38c898cf692f0940c57695 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6969 Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins)
2014-09-24x86: Minimize work done with the caches disabled in mtrr functions.Gabe Black
The code in src/cpu/x86/mtrr/mtrr.c disables caching in a few places when changing mtrr settings. While I can't find anything that says that's actually required, I can believe it's necessary. With that said, other code around the wrmsr instructions which actually modify the settings should be able to run with caching enabled with no ill effects. This is particularly true for two calls to printk, one in the fixed mtrr code and one in the variable, which could result in an arbitrary amount of work being done without caching. When changing the implementation of the cbmem console, these two printks caused a significant regression in boot performance on link of about 70ms which is about 10% of total firmware boot time. When the window where the cache is disabled is minimized, both this and the new implementation were about 30ms faster than the original boot time. For the variable MTRRs, we now store what we want to set the MSRs to and then write them all at once at the end of commit_var_mtrrs(). This way we don't have some set and some not, but we still minimize the time we spend with the caches disabled. Change-Id: I5139b262bd2d13f79afd88e2e2c0f514fb3e27c9 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/187811 Reviewed-by: Ronald Minnich <rminnich@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 31529d6d965676c6cedeb62137eabc26819956fc) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6952 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-06-30x86 MTRR: Drop unused return valueKyösti Mälkki
It was never well-defined what value this function should return. Change-Id: If84aff86e0b556591d7ad557842910a2dfcd3b46 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/6166 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>