summaryrefslogtreecommitdiff
path: root/src/cpu/x86/mtrr/mtrr.c
AgeCommit message (Collapse)Author
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-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-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-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-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
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-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
2009-04-01Fix typo.Marc Jones
trivial. Signed-off-by: Marc Jones <marcj303@gmail.com> Acked-by: Marc Jones <marcj303@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4046 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-03-04I just went on a bugfix frenzy and fixed all printk format warningsCarl-Daniel Hailfinger
triggered by the AMD 690/SB600 targets. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3970 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-02-12This patch converts __FUNCTION__ to __func__, since __func__ is standard.Myles Watson
Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3943 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-02-12Fix mtrr setup for UMA architectures.Stefan Reinauer
If high SMM memory is used (and needs to be uncached for whatever reason; it shouldn't in my opinion), we should do it the same way. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3942 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-02-11Print a loud warning message if we run out of MTRRs.Carl-Daniel Hailfinger
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3937 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-02-09Remove some warnings, mainly from format strings which didn't match theMyles Watson
arguments. Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3931 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2008-08-01same spelling in all mtrr output.. (trivial)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@3453 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2007-10-23fix a whole bunch of warnings. (trivial)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@2890 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2007-04-24trivial: fix filename in comment. 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@2616 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2007-04-06This is part of the outstanding mcp55 commit from January 18th. It willYinghai Lu
likely break the build, since it is only a small part, but it needs to go in at some point and doing it directory by directory makes things easier. Signed-off-by: Yinghai Lu <yinghai.lu at amd.com> Signed-off-by: Ed Swierk <eswierk at arastra.com> Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Ward Vandewege <ward at gnu.org> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2588 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2006-10-04AMD Rev F supportYinghai Lu
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2435 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2005-07-08eric patchYinghai Lu
1. x86_setup_mtrr take address bit. 2. generic ht, pcix, pcie beidge... 3. scan bus and reset_bus 4. ht read ctrl to decide if the ht chain is ready 5. Intel e7520 and e7525 support 6. new ich5r support 7. intel sb 6300 support. yhlu patch 1. split x86_setup_mtrrs to fixed and var 2. if (resource->flags & IORESOURCE_FIXED ) return; in device.c pick_largest_resource 3. in_conherent.c K8_SCAN_PCI_BUS git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1982 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2005-07-06Revision: linuxbios@linuxbios.org--devel/freebios--devel--2.0--patch-34arch import user (historical)
Creator: Yinghai Lu <yhlu@tyan.com> AMD D0/E0 Opteron new mem mapping support, AMD E Opteron mem hole support,AMD K8 Four Ranks DIMM support git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1950 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2005-01-27spare one more mtrrYinghai Lu
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1903 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2005-01-06add NC support to spare mtrrs for 64G memory storedYinghai Lu
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1843 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-30- To reduce confuse rename the parts of linuxbios bios that run fromEric Biederman
ram linuxbios_ram instead of linuxbios_c and linuxbios_payload... - Reordered the linker sections so the LinuxBIOS fallback image can take more the 64KiB on x86 - ROM_IMAGE_SIZE now will work when it is specified as larger than 64KiB. - Tweaked the reset16.inc and reset16.lds to move the sanity check to see if everything will work. - Start using romcc's built in preprocessor (This will simplify header compiler checks) - Add helper functions for examining all of the resources - Remove debug strings from chip.h - Add llshell to src/arch/i386/llshell (Sometime later I can try it...) - Add the ability to catch exceptions on x86 - Add gdb_stub support to x86 - Removed old cpu options - Added an option so we can detect movnti support - Remove some duplicate definitions from pci_ids.h - Remove the 64bit resource code in amdk8/northbridge.c in preparation for making it generic - Minor romcc bug fixes git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1727 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-22- Better memory I/O space distinguishing in amd_mtrr.cEric Biederman
This is way to much code duplication but for now things work. - Fix the typo in amd8111_lpc.c - Remove an unused macro, use continue instead of break in mtrr.c git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1704 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14- Add new cvs code to cvsEric Biederman
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1657 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-19 08:02:18 +0000