summaryrefslogtreecommitdiff
path: root/src/cpu/x86/mtrr
AgeCommit message (Collapse)Author
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>
2014-06-30Use MTRR definesKyösti Mälkki
Change-Id: I60ae6dcb8c3b280fe74f27f4d61de70cc1ba190b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/6123 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-02-25Remove CACHE_ROM.Vladimir Serbinenko
With the recent improvement 3d6ffe76f8a505c2dff5d5c6146da3d63dad6e82, speedup by CACHE_ROM is reduced a lot. On the other hand this makes coreboot run out of MTRRs depending on system configuration, hence screwing up I/O access and cache coherency in worst cases. CACHE_ROM requires the user to sanity check their boot output because the feature is brittle. The working configuration is dependent on I/O hole size, ram size, and chipset. Because of this the current implementation can leave a system configured in an inconsistent state leading to unexpected results such as poor performance and/or inconsistent cache-coherency Remove this as a buggy feature until we figure out how to do it properly if necessary. Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/5146 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-02-09mtrr: only add prefetchable resources as WRCOMB for VGA devicesAaron Durbin
Be more conservative and only add VGA devices' prefetchable resources as write-combining in the address space. Previously all prefetchable memory was added as a write-combining memory type. Some hardware incorrectly advertises its BAR as prefetchable when it shouldn't be. A new memranges_add_resources_filter() function is added to provide additional filtering on device and resource. Change-Id: I3fc55b90d8c5b694c5aa9e2f34db1b4ef845ce10 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5169 Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com> Tested-by: build bot (Jenkins)
2014-02-06MTRR: Mark all prefetchable resources as WRCOMB.Vladimir Serbinenko
Change-Id: I2ecfd9733b65b6160bc2232d22db7b16692a847f Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/5149 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-02-06mtrr: retry fitting w/o WRCOMB if usage exceeds BIOS allocationAaron Durbin
If the MTRR usage exceeds the BIOS allocation for MTRR usage re-try without the WRCOMB type. Change-Id: Ie70ce84994428ff6700c36310264c3c44d9ed128 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5151 Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com> Tested-by: build bot (Jenkins)
2014-01-26src/cpu: Fix spelling of MTTR to MTRRPaul Menzel
Change-Id: Ia4718ac31a5b2bd12f8cda5e107aa878d74d2a03 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/4805 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-15Re-declare CACHE_ROM_SIZE as aligned ROM_SIZE for MTRRKyösti Mälkki
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be set with values that are not power of 2. The region programmed as WB cacheable will include all of ROM_SIZE. Side-effects to consider: Memory region below flash may be tagged WRPROT cacheable. As an example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB. Since this can overlap CAR, we add an explicit test and fail on compile should this happen. To work around this problem, one needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and define a smaller region for WB cache. With this change flash regions outside CBFS are also tagged WRPROT cacheable. This covers IFD and ME and sections ChromeOS may use. Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4625 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2013-12-26AMD boards (non-AGESA): Cleanup earlymtrr.c includesKyösti Mälkki
Change-Id: I5f4bf9dbaf3470dc83d3e980bb6cab10801e15c1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4523 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-10-03cpu/x86/mtrr/mtrr.c: Remove superfluous assignment to `type_index`Paul Menzel
When building coreboot with the Clang static analyzer scan-build, it reports »Value stored to 'type_index' is never read«. Indeed, in `memranges_each_entry()` `type_index` is assigned a value before being read. So remove that line. Change-Id: I6da2fb8be7157bb98c57281babd4a08ca0d9f7a7 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3953 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-11cpu: Fix spellingMartin Roth
Change-Id: I69c46648de0689e9bed84c7726906024ad65e769 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-01x86: use boot state callbacks to disable rom cacheAaron Durbin
On x86 systems there is a concept of cachings the ROM. However, the typical policy is that the boot cpu is the only one with it enabled. In order to ensure the MTRRs are the same across cores the rom cache needs to be disabled prior to OS resume or boot handoff. Therefore, utilize the boot state callbacks to schedule the disabling of the ROM cache at the ramstage exit points. Change-Id: I4da5886d9f1cf4c6af2f09bb909f0d0f0faa4e62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3138 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-04AMD: Drop six copies of wrmsr_amd and rdmsr_amdKyösti Mälkki
Based on comments in cpu/x86/msr.h for wrmsr/rdmsr, and for symmetry, I have added __attribute__((always_inline)) for these. Change-Id: Ia0a34c15241f9fbc8c78763386028ddcbe6690b1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2898 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-04-01boot: add disable_cache_rom() functionAaron Durbin
On certain architectures such as x86 the bootstrap processor does most of the work. When CACHE_ROM is employed it's appropriate to ensure that the caching enablement of the ROM is disabled so that the caching settings are symmetric before booting the payload or OS. Tested this on an x86 machine that turned on ROM caching. Linux did not complain about asymmetric MTRR settings nor did the ROM show up as cached in the MTRR settings. Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: mtrr: optimize hole carving above 4GiBAaron Durbin
There is an optimization that can take place when hole carving in ranges above 4GiB. If the range is the last range then there is no need to carve UC holes out from the larger WB range. This optimization also has the same assumption of choosing WB as the default MTRR type: the OS needs to properly handle accessing realloacted MMIO resources with PAT so that the MTRR type can be overidden. Below are results using a combination of options. The board this was tested on has 10 variable MTRRs at its disposal. It has 4GiB of RAM. IO hole config #1: hole starts at 0xad800000 No CACHE_ROM and no WRCOMB resources (takes 4 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x0000000100000000 size 0x52800000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 4/6. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0 No CACHE_ROM and 1 WRCOMB resource (takes 6 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 6/7. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0 CACHE_ROM and no WRCOMB resources (takes 7 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000ff800000 size 0x52000000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 11/7. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6 MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6 MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 5 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 6 base 0x0000000100000000 mask 0x0000007f00000000 type 6 CACHE_ROM and 1 WRCOMB resource (takes 8 MTRRs): Previously this combination was impossible without the optimization. MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 12/8. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6 MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6 MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 5 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 6 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 7 base 0x0000000100000000 mask 0x0000007f00000000 type 6 IO hole config #1: hole starts at 0x80000000 No CACHE_ROM and no WRCOMB resources (takes 1 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x0000000100000000 size 0x80000000 type 0 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 1/2. MTRR: WB selected as default type. MTRR: 0 base 0x0000000080000000 mask 0x0000007f80000000 type 0 No CACHE_ROM and 1 WRCOMB resource (takes 3 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 4/3. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 2 base 0x0000000100000000 mask 0x0000007f00000000 type 6 CACHE_ROM and no WRCOMB resources (takes 3 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x00000000ff800000 size 0x7f800000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 9/3. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 2 base 0x0000000100000000 mask 0x0000007f00000000 type 6 CACHE_ROM and 1 WRCOMB resource (takes 4 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 10/4. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 2 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 3 base 0x0000000100000000 mask 0x0000007f00000000 type 6 Change-Id: Ia3195af686c3f0603b21f713cfb2d9075eb02806 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2959 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: mtrr: add hole punching supportAaron Durbin
Some ranges would use less variable MTRRs if an UC area can be carved off the top of larger WB range. Implement this approach by doing 3 passes over each region in the addres space: 1. UC default type. Cover non-UC and non-WB regions with respectie type. Punch UC hole at upper end of larger WB regions with WB type. 2. UC default type. Cover non-UC regions with respective type. 3. WB default type. Cover non-WB regions with respective type. The hole at upper end of a region uses the same min alignment of 64MiB. Below are results using a combination of options. The board this was tested on has 10 variable MTRRs at its disposal. It has 4GiB of RAM. IO hole config #1: hole starts at 0xad800000 No CACHE_ROM or WRCOMB resources (takes 4 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x0000000100000000 size 0x52800000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 4/9. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0 No CACHE_ROM. 1 WRCOMB resource (takes 6 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 6/10. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0 CACHE_ROM and no WRCOMB resources (taks 10 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000ff800000 size 0x52000000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 MTRR: default type WB/UC MTRR counts: 11/10. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x0000000080000000 mask 0x0000007fe0000000 type 6 MTRR: 2 base 0x00000000a0000000 mask 0x0000007ff0000000 type 6 MTRR: 3 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 4 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 5 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 6 base 0x0000000100000000 mask 0x0000007fc0000000 type 6 MTRR: 7 base 0x0000000140000000 mask 0x0000007ff0000000 type 6 Taking a reserved OS MTRR. MTRR: 8 base 0x000000014f600000 mask 0x0000007fffe00000 type 0 Taking a reserved OS MTRR. MTRR: 9 base 0x000000014f800000 mask 0x0000007fff800000 type 0 A combination of CACHE_ROM and WRCOMB just won't work. IO hole config #2: hole starts at 0x80000000: No CACHE_ROM or WRCOMB resources (takes 1 MTRR): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x0000000100000000 size 0x80000000 type 0 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 1/5. MTRR: WB selected as default type. MTRR: 0 base 0x0000000080000000 mask 0x0000007f80000000 type 0 No CACHE_ROM. 1 WRCOMB resource (takes 4 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 4/6. MTRR: WB selected as default type. MTRR: 0 base 0x0000000080000000 mask 0x0000007fc0000000 type 0 MTRR: 1 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0 MTRR: 2 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 3 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0 CACHE_ROM and no WRCOMB resources (takes 6 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x00000000ff800000 size 0x7f800000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 9/6. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 2 base 0x0000000100000000 mask 0x0000007f80000000 type 6 MTRR: 3 base 0x000000017ce00000 mask 0x0000007fffe00000 type 0 MTRR: 4 base 0x000000017d000000 mask 0x0000007fff000000 type 0 MTRR: 5 base 0x000000017e000000 mask 0x0000007ffe000000 type 0 CACHE_ROM and 1 WRCOMB resource (takes 7 MTRRs): MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6 0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x00000000ff800000 size 0x1f800000 type 0 0x00000000ff800000 - 0x0000000100000000 size 0x00800000 type 5 0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6 MTRR: default type WB/UC MTRR counts: 10/7. MTRR: UC selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6 MTRR: 1 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 2 base 0x00000000ff800000 mask 0x0000007fff800000 type 0 MTRR: 3 base 0x0000000100000000 mask 0x0000007f80000000 type 6 MTRR: 4 base 0x000000017ce00000 mask 0x0000007fffe00000 type 0 MTRR: 5 base 0x000000017d000000 mask 0x0000007fff000000 type 0 MTRR: 6 base 0x000000017e000000 mask 0x0000007ffe000000 type 0 Change-Id: Iceb9b64991accf558caae2e7b0205951e9bcde44 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2925 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: add rom cache variable MTRR index to tablesAaron Durbin
Downstream payloads may need to take advantage of caching the ROM for performance reasons. Add the ability to communicate the variable range MTRR index to use to perform the caching enablement. An example usage implementation would be to obtain the variable MTRR index that covers the ROM from the coreboot tables. Then one would disable caching and change the MTRR type from uncacheable to write-protect and enable caching. The opposite sequence is required to tearn down the caching. Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2919 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: mtrr: add CONFIG_CACHE_ROM supportAaron Durbin
The CONFIG_CACHE_ROM support in the MTRR code allocates an MTRR specifically for setting up write-protect cachine of the ROM. It is assumed that CONFIG_ROM_SIZE is the size of the ROM and the whole area should be cached just under 4GiB. If enabled, the MTRR code will allocate but not enable rom caching. It is up to the callers of the MTRR code to explicitly enable (and disable afterwards) through the use of 2 new functions: - x86_mtrr_enable_rom_caching() - x86_mtrr_disable_rom_caching() Additionally, the CACHE_ROM option is exposed to the config menu so that it is not just selected by the chipset or board. The reasoning is that through a multitude of options CACHE_ROM may not be appropriate for enabling. Change-Id: I4483df850f442bdcef969ffeaf7608ed70b88085 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2918 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29mtrr: honor IORESOURCE_WRCOMBAaron Durbin
All resources that set the IORESOURCE_WRCOMB attribute which are also marked as IORESOURCE_PREFETCH will have a MTRR set up that is of the write-combining cacheable type. The only resources on x86 that can be set to write-combining are prefetchable ones. Change-Id: Iba7452cff3677e07d7e263b79982a49c93be9c54 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2892 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29x86: add new mtrr implementationAaron Durbin
The old MTRR code had issues using too many variable MTRRs depending on the physical address space layout dictated by the device resources. This new implementation calculates the default MTRR type by comparing the number of variable MTRRs used for each type. This avoids the need for IORESOURE_UMA_FB because in many of those situations setting the default type to WB frees up the variable MTTRs to set that space to UC. Additionally, it removes the need for IORESOURCE_IGNORE_MTRR becuase the new mtrr uses the memrange library which does merging of resources. Lastly, the sandybridge gma has its speedup optimization removed for the graphics memory by writing a pre-determined MTRR index. That will be fixed in an upcoming patch once write-combining support is added to the resources. Slight differences from previous MTRR code: - The number of reserved OS MTRRs is not a hard limit. It's now advisory as PAT can be used by the OS to setup the regions to the caching policy desired. - The memory types are calculated once by the first CPU to run the code. After that all other CPUs use that value. - CONFIG_CACHE_ROM support was dropped. It will be added back in its own change. A pathological case that was previously fixed by changing vendor code to adjust the IO hole location looked like the following: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 As noted by the output below it's impossible to accomodate those ranges even with 10 variable MTRRS. However, because the code can select WB as the default MTRR type it can be done in 6 MTRRs: MTRR: default type WB/UC MTRR counts: 6/14. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0 Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2889 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: unify amd and non-amd MTRR routinesAaron Durbin
The amd_mtrr.c file contains a copy of the fixed MTRR algorithm. However, the AMD code needs to handle the RdMem and WrMem attribute bits in the fixed MTRR MSRs. Instead of duplicating the code with the one slight change introduce a Kconfig option, X86_AMD_FIXED_MTRRS, which indicates that the RdMem and WrMem fields need to be handled for writeback fixed MTRR ranges. The order of how the AMD MTRR setup routine is maintained by providing a x86_setup_fixed_mtrrs_no_enable() function which does not enable the fixed MTRRs after setting them up. All Kconfig files which had a Makefile that included amd/mtrr in the subdirs-y now have a default X86_AMD_FIXED_MTRRS selection. There may be some overlap with the agesa and socket code, but I didn't know the best way to tease out the interdependency. Change-Id: I256d0210d1eb3004e2043b46374dcc0337432767 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2866 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-15Google Link: Add remaining code to support native graphicsRonald G. Minnich
The Link native graphics commit 49428d84 [1] Add support for Google's Chromebook Pixel was missing some of the higher level bits, and hence could not be used. This is not new code -- it has been working since last August -- so the effort now is to get it into the tree and structure it in a way compatible with upstream coreboot. 1. Add options to src/device/Kconfig to enable native graphics. 2. Export the MTRR function for setting variable MTRRs. 3. Clean up some of the comments and white space. While I realize that the product name is Pixel, the mainboard in the coreboot tree is called Link, and that name is what we will use in our commits. [1] http://review.coreboot.org/2482 Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2531 Tested-by: build bot (Jenkins)
2012-08-01Intel Sandybridge: add reserved memory as resourcesKyösti Mälkki
Reserved memory resources will get removed from memory table at the end of write_coreboot_table(), Change-Id: I02711b4be4f25054bd3361295d8d4dc996b2eb3e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/1372 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2012-07-24Rename cache_lbmem() to cache_ramstage()Stefan Reinauer
... and don't require it to specify a cache type. This function is only used on romcc boards, and should go away (because all boards should be switched to CAR) Change-Id: Ic32ca3be1afffc773c72c140e88b338d48a0c8ca Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1288 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24MTRR: drop repetetive debug messageStefan Reinauer
It's not really useful anymore I guess, and it makes the log files harder to read. Hence dropping it. Change-Id: If4c3e8b40ae491ca527ef62f8145206960f6579d Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1272 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-16Check for IORESOURCE_UMA_FB in MTRR setupKyösti Mälkki
If northbridge called uma_resource() a resource of this type should be found when walking the resources list. For now, be rude and don't even try to combine it with neighboring regions. As the type is un-cacheable it is dominant over other MTRR setups claiming the same region. Change-Id: I57805e7e7da0709f8ed78d8df62c2abf22172a06 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/1215 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-07-16Define global uma_memory variablesKyösti Mälkki
Use of the uma_memory_base and _size variables is very scattered. Implementation of setup_uma_memory() will appear in each northbridge. It should be possible to do this setup entirely in northbridge code and get rid of the globals in a follow-up. Change-Id: I07ccd98c55a6bcaa8294ad9704b88d7afb341456 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/1204 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-07-12Drop Kconfig VAR_MTRR_HOLE optionKyösti Mälkki
All but one board use the default value of enabled. Disabling this can only increase the number of MTRR registers used. Change-Id: I7d28adc31b9fae2301e4ff78fcb96486f81d5ec2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/1213 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-05-30Fix the location of "Setting variable MTRR" printk.Denis 'GNUtoo' Carikli
Without that fix the debugging is harder because the person debugging coreboot will see the following twice(note the repeated MTRR number): Setting variable MTRR 0, base: 0MB, range: 4096MB, type WB [...] Setting variable MTRR 1, base: 4096MB, range: 512MB, type WB Setting variable MTRR 1, base: 4608MB, range: 256MB, type WB Setting variable MTRR 1, base: 3072MB, range: 1024MB, type UC instead of the following twice: Setting variable MTRR 0, base: 0MB, range: 4096MB, type WB [...] Setting variable MTRR 1, base: 3072MB, range: 1024MB, type UC Thanks to kmalkki on #coreboot's Freenode IRC channel for the idea: May 25 23:57:17 <kmalkki> I would add (move) that "Setting variable MTRR..." debug at the end of set_var_mtrrs() Change-Id: I9f4b7110ba34d017a58d8cc5fb06a7b1c3d0c8aa Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/1058 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
2012-05-08Some more #if cleanupPatrick Georgi
Replace #elif (CONFIG_FOO==1) with #elif CONFIG_FOO find src -type f -exec sed -i "s,\(#.*\)(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]1),\1\2,g" {} + (manual tweak since it hit a false positive) Replace #elif (CONFIG_FOO==0) with #elif !CONFIG_FOO find src -type f -exec sed -i "s,\(#.*\)(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]0),\1\!\2,g" {} + Change-Id: I8f4ebf609740dfc53e79d5f1e60f9446364bb07d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1006 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-04-06Cache 8MB flash instead of 4MBStefan Reinauer
Also fix the MTRR check to use the total_mtrrs variable instead of a hardcoded 8. Change-Id: I2c5ceb3910cd949f43ecf5b8aff857d6ffe0b1a5 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/873 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-30Make MTRR min hole alignment 64MBDuncan Laurie
This affects the algorithm when determining when to transform a range into a larger range with a hole. It is needed when for when I switch on an 8MB TSEG and cause the memory maps to go crazy. Also add header defines for the SMRR. Change-Id: I1a06ccc28ef139cc79f655a8b19fd3533aca0401 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/765 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-30Fix MB calculation in the reporting of the MTRR holeDuncan Laurie
Change-Id: I34b5c4ffd2a3f3e895d2bffedce1c00ee9aea942 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/763 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-30MTRR: add alternate allocation method for odd memory mapsDuncan Laurie
With >= 4GB memory installed we get a memory map split in the middle due to remap that has boundaries that are inconveniently aligned for MTRRs due to the various UMA regions. 0000MB-2780MB 2780MB RAM (writeback) 2780MB-2782MB 2MB TSEG (uncached/SMRR) 2782MB-2784MB 2MB GFX GTT (uncached) 2784MB-2816MB 32MB GFX UMA (uncached) 2816MB-4096MB 1280MB EMPTY (N/A) 4096MB-5368MB 1272MB RAM (writeback) 5368MB-5376MB 8MB ME UMA (uncached) The default MTRR allocation method of trying to cover everything with one MTRR and then carve out a single uncached region does not work for the GPU aperture which needs write-combining type, and it also has issues trying to cover the uneven boundaries in the avaiable variable MTRRs. My goal was to make a minimal set of changes and avoid modifying behavior on existing systems with an algorithm that is not always optimal for a typical memory layout. So the flag 'above4gb=2' will change these allocation behaviors: 1) Detect the number of available variable MTRRs rather than limiting to hardcoded value. We need every last MTRR. 2) Don't try to cover all RAM with one MTRR, instead let each RAM region get covered independently. 3) Don't assume uma_memory_base is part of the last region and increase the size of that region. In this case the UMA region is carved out from the lower memory region and it is already declared as part of the ram region. 4) If a memory region can't be covered with MTRRs >= 16MB then instead make a larger region and trim it with uncached MTRRs. Change-Id: I5a60a44ab6d3ae2f46ea6ffa9e3677aaad2485eb Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/761 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-30Add an option to keep the ROM cached after romstageStefan Reinauer
Change-Id: I05f1cbd33f0cb7d80ec90c636d1607774b4a74ef Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/739 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-01-10MTRR: get physical address size from CPUIDSven Schnelle
The current code uses static values for the physical address size supported by a CPU. This isn't always the right value: I.e. on model_6[ef]x Core (2) Duo CPUs physical address size is 36, while Xeons from the same family have 38 bits, which results in invalid MTRR setup. Fix this by getting the right number from CPUID. Change-Id: If019c3d9147c3b86357f0ef0d9fda94d49d811ca Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/529 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-10-28Get rid of AUTO_XIP_ROM_BASEPatrick Georgi
That value is now generated from a code address and CONFIG_XIP_ROM_SIZE. This works as MTRRs are fully specified by their size and any address within the range. Change-Id: Id35d34eaf3be37f59cd2a968e3327d333ba71a34 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/348 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-04-14earlymtrr.c: wipe some dead code, use names instead of numbers and someStefan Reinauer
cosmetics. Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6499 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-01-19Now that the VIA code is run above 1Meg (like other boards), it shouldKevin O'Connor
cache that range instead of the first 1Meg. This reduces boot time by about 1 second on epia-cn. This patch also adds a MTRRphysMaskValid bit definition. Signed-off-by: Kevin O'Connor <kevin@koconnor.net> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6272 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-13MTRR related improvements for AMD family 10h and family 0Fh systemsScott Duplichan
-- When building for UMA, reduce the limit for DRAM below 4GB from E0000000 to C0000000. This is needed to accomodate the UMA frame buffer. -- Correct problem where msr C0010010 bits 21 and 22 (MtrrTom2En and Tom2ForceMemTypeWB) are not set consistently across cores. -- Enable TOM2 only if DRAM is present above 4GB. -- Use AMD Tom2ForceMemTypeWB feature to avoid the need for variable MTRR ranges above 4GB. -- Add above4gb flag argument to function x86_setup_var_mtrrs. Clearing this flag causes x86_setup_var_mtrrs() to omit MTRR ranges for DRAM above 4GB. AMD systems use this option to conserve MTRRs. -- Northbridge.c change to deduct UMA memory from DRAM size reported by ram_resource. This corrects a problem where mtrr.c generates an unexpected variable MTRR range. -- Correct problem causing build failure when CONFIG_GFXUMA=1 and CONFIG_VAR_MTRR_HOLE=0. -- Reserve the UMA DRAM range for AMD K8 as is already done for AMD family 10h. Tested with mahogany on ECS A780G-GM with 2GB and 4GB. Tested with mahogany_fam10 on ECS A780G-GM with 2GB and 4GB. Signed-off-by: Scott Duplichan <scott@notabs.org> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6067 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-09-30Rename build system variables to be more intuitive, andPatrick Georgi
at the same time let the user specify sources instead of object files: - objs becomes ramstage-srcs - initobjs becomes romstage-srcs - driver becomes driver-srcs - smmobj becomes smm-srcs The user servicable parts are named accordingly: ramstage-y, romstage-y, driver-y, smm-y Also, the object file names are properly renamed now, using .ramstage.o, .romstage.o, .driver.o, .smm.o suffixes consistently. Remove stubbed out via/epia-m700 dsdt/ssdt files - they didn't easily fit in the build system and aren't useful anyway. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coreystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5886 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-08-30We call this cache as ram everywhere, so let's call it the same in KconfigStefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Myles Watson <mylesgw@gmail.com> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5756 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-08-01make early_mtrr_init() invisible for cache as ram targets as it breaks them.Stefan Reinauer
Fix up converted mainboards that still used early_mtrr_init() Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5678 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-27Since some people disapprove of white space cleanups mixed in regular commitsStefan Reinauer
while others dislike them being extra commits, let's clean them up once and for all for the existing code. If it's ugly, let it only be ugly once :-) Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-14drop quite a lot of dead code that did nothing but produce warnings and makeStefan Reinauer
the rest of the code unreadable. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5426 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-09zero warnings days.Stefan Reinauer
The tyan s2895 is down to 3 warnings, 2 of which are caused by #warning. The 1000 ways of how the AMD code waits for the cores to be started up are a real pain for the brain. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5396 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-07clean up age old via epia target.Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5368 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-06No warnings day, next round.Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5359 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-03remove more warnings.Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5353 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-22printk_foo -> printk(BIOS_FOO, ...)Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5266 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-02-11Fix AUTO_XIP_ROM_BASE issues on AMD boards with certain compilers,Patrick Georgi
and expose the error earlier in the build. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Patrick Georgi <patrick.georgi@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5119 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-02-11Adapt all uses of CONFIG_XIP_ROM_BASE to usePatrick Georgi
AUTO_XIP_ROM_BASE (as implemented for tinybootblock) if available. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5118 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-02-07newconfig is no more.Patrick Georgi
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5089 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-19Clean up some #ifdef CONFIG_*Myles Watson
Change HAVE_FAN_CTL to be specific to the SuperIO that supports it. Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Uwe Hermann <uwe@hermann-uwe.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4809 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-16Change CONFIG_LB_MEM_TOPK to CONFIG_RAMTOP to match CONFIG_RAMBASE.Myles Watson
Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4788 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-12Kconfig!Patrick Georgi
Works on Kontron, qemu, and serengeti. Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de> tested on abuild only. Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-08-11The code between #if and #endif is only about UMA mode. The CONFIG_GFXUMA ↵Zheng Bao
should be 1. We have another mode called side port mode. It is When the CONFIG_GFXUMA is 0. Signed-off-by: Zheng Bao <zheng.bao@amd.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4525 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 16:50:31 +0000