GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/include/cpu/x86/mtrr.h

119 lines
3.9 KiB
C
Raw Normal View History

- Renamed cpu header files git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14 22:13:01 +02:00
#ifndef CPU_X86_MTRR_H
#define CPU_X86_MTRR_H
/* These are the region types */
#define MTRR_TYPE_UNCACHEABLE 0
#define MTRR_TYPE_WRCOMB 1
/*#define MTRR_TYPE_ 2*/
/*#define MTRR_TYPE_ 3*/
#define MTRR_TYPE_WRTHROUGH 4
#define MTRR_TYPE_WRPROT 5
#define MTRR_TYPE_WRBACK 6
#define MTRR_NUM_TYPES 7
#define MTRRcap_MSR 0x0fe
#define MTRRdefType_MSR 0x2ff
CAR simplifications, typos, readability improvements (trivial). - Use some more #defines instead of hard-coding values. - Merge multiple movl/orl or movl/andl lines into one where possible. - Add some TODOs in places which seem to have either an incorrect code or incorrect comment. - Fix typos: s/for/from/, s/BSC/BSP/, s/size/carsize/. Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Uwe Hermann <uwe@hermann-uwe.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5890 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-10-01 09:27:51 +02:00
#define MTRRdefTypeEn (1 << 11)
#define MTRRdefTypeFixEn (1 << 10)
Make MTRR min hole alignment 64MB 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-01-10 07:05:18 +01:00
#define SMRRphysBase_MSR 0x1f2
#define SMRRphysMask_MSR 0x1f3
- Renamed cpu header files git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14 22:13:01 +02:00
#define MTRRphysBase_MSR(reg) (0x200 + 2 * (reg))
#define MTRRphysMask_MSR(reg) (0x200 + 2 * (reg) + 1)
Now that the VIA code is run above 1Meg (like other boards), it should 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
2011-01-19 07:32:35 +01:00
#define MTRRphysMaskValid (1 << 11)
- Renamed cpu header files git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14 22:13:01 +02:00
#define NUM_FIXED_RANGES 88
x86: add new mtrr implementation 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-26 20:09:47 +01:00
#define RANGES_PER_FIXED_MTRR 8
- Renamed cpu header files git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14 22:13:01 +02:00
#define MTRRfix64K_00000_MSR 0x250
#define MTRRfix16K_80000_MSR 0x258
#define MTRRfix16K_A0000_MSR 0x259
#define MTRRfix4K_C0000_MSR 0x268
#define MTRRfix4K_C8000_MSR 0x269
#define MTRRfix4K_D0000_MSR 0x26a
#define MTRRfix4K_D8000_MSR 0x26b
#define MTRRfix4K_E0000_MSR 0x26c
#define MTRRfix4K_E8000_MSR 0x26d
#define MTRRfix4K_F0000_MSR 0x26e
#define MTRRfix4K_F8000_MSR 0x26f
In 2007 Adrian Reber suggested that we drop ASSEMBLY in favor of __ASSEMBLER__. http://www.coreboot.org/pipermail/coreboot/2007-September/024665.html It's about time we follow this advice. Also move some manually set __PRE_RAM__ defines (ap_romstage.c) to the Makefile and drop unused CPP define Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Patrick Georgi <patrick@georgi-clan.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6482 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-10 06:15:23 +02:00
#if !defined (__ASSEMBLER__) && !defined(__PRE_RAM__)
x86: add new mtrr implementation 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-26 20:09:47 +01:00
/*
* The MTRR code has some side effects that the callers should be aware for.
* 1. The call sequence matters. x86_setup_mtrrs() calls
* x86_setup_fixed_mtrrs_no_enable() then enable_fixed_mtrrs() (equivalent
* of x86_setup_fixed_mtrrs()) then x86_setup_var_mtrrs(). If the callers
* want to call the components of x86_setup_mtrrs() because of other
include: Fix spelling Change-Id: Iadc813bc8208278996b2b1aa20cfb156ec06fac9 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3755 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10 05:46:01 +02:00
* requirements the ordering should still preserved.
x86: add new mtrr implementation 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-26 20:09:47 +01:00
* 2. enable_fixed_mtrr() will enable both variable and fixed MTRRs because
* of the nature of the global MTRR enable flag. Therefore, all direct
* or indirect callers of enable_fixed_mtrr() should ensure that the
* variable MTRR MSRs do not contain bad ranges.
Google Link: Add remaining code to support native graphics 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)
2013-02-26 19:07:40 +01:00
*/
MTRR: get physical address size from CPUID 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>
2012-01-10 12:01:43 +01:00
void x86_setup_mtrrs(void);
x86: add new mtrr implementation 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-26 20:09:47 +01:00
/*
* x86_setup_var_mtrrs() parameters:
* address_bits - number of physical address bits supported by cpu
* above4gb - 2 means dynamically detect number of variable MTRRs available.
* non-zero means handle memory ranges above 4GiB.
* 0 means ignore memory ranges above 4GiB
*/
void x86_setup_var_mtrrs(unsigned int address_bits, unsigned int above4gb);
void enable_fixed_mtrr(void);
Add few missing prototypes, and remove few unused (thus lonelly) variables. TODO - x86emu need (imo) some common header with prototypes at least - clog2, ulzma, hardwaremain prototypes added by this patch probably should be moved to some header too. - in src/devices/device_util.c prototype is before function because seems, it is used only within same file, if not it should be moved to debug section of prototypes in include/device/device.h Signed-off-by: Maciej Pijanka <maciej.pijanka@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4871 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-27 15:29:29 +01:00
void x86_setup_fixed_mtrrs(void);
x86: unify amd and non-amd MTRR routines 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-20 21:50:59 +01:00
/* Set up fixed MTRRs but do not enable them. */
void x86_setup_fixed_mtrrs_no_enable(void);
x86: add new mtrr implementation 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-26 20:09:47 +01:00
int x86_mtrr_check(void);
drop unneeded __ROMCC__ checks when the check for __PRE_RAM__ is more appropriate. Also, factor out post_code() for __PRE_RAM__ code and drop it from some mainboards. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5307 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-28 23:26:54 +02:00
#endif
- Renamed cpu header files git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14 22:13:01 +02:00
AMD boards (non-AGESA): Cleanup earlymtrr.c includes 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-12-12 11:27:53 +01:00
#if !defined(__ASSEMBLER__) && defined(__PRE_RAM__) && !defined(__ROMCC__)
void set_var_mtrr(unsigned reg, unsigned base, unsigned size, unsigned type);
#endif
Re-declare CACHE_ROM_SIZE as aligned ROM_SIZE for MTRR 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>
2014-01-06 10:06:26 +01:00
/* Align up to next power of 2, suitable for ROMCC and assembler too.
* Range of result 256kB to 128MB is good enough here.
*/
#define _POW2_MASK(x) ((x>>1)|(x>>2)|(x>>3)|(x>>4)|(x>>5)| \
(x>>6)|(x>>7)|(x>>8)|((1<<18)-1))
#define _ALIGN_UP_POW2(x) ((x + _POW2_MASK(x)) & ~_POW2_MASK(x))
No warnings day, next round. 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-06 23:50:21 +02:00
#if !defined(CONFIG_RAMTOP)
# error "CONFIG_RAMTOP not defined"
#endif
Remove XIP_ROM_BASE The base is now calculated automatically, and all mentions of that config option were typical anyway (4GB - XIP_ROM_SIZE). Change-Id: Icdf908dc043719f3810f7b5b85ad9938f362ea40 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/366 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-10-31 17:07:52 +01:00
#if ((CONFIG_XIP_ROM_SIZE & (CONFIG_XIP_ROM_SIZE -1)) != 0)
No warnings day, next round. 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-06 23:50:21 +02:00
# error "CONFIG_XIP_ROM_SIZE is not a power of 2"
#endif
Re-declare CACHE_ROM_SIZE as aligned ROM_SIZE for MTRR 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>
2014-01-06 10:06:26 +01:00
/* Select CACHE_ROM_SIZE to use with MTRR setup. For most cases this
* resolves to a suitable CONFIG_ROM_SIZE but some odd cases need to
* use CONFIG_CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig.
*/
#if (CONFIG_CACHE_ROM_SIZE_OVERRIDE != 0)
# define CACHE_ROM_SIZE CONFIG_CACHE_ROM_SIZE_OVERRIDE
#else
# if ((CONFIG_ROM_SIZE & (CONFIG_ROM_SIZE-1)) == 0)
# define CACHE_ROM_SIZE CONFIG_ROM_SIZE
# else
# define CACHE_ROM_SIZE _ALIGN_UP_POW2(CONFIG_ROM_SIZE)
# if (CACHE_ROM_SIZE < CONFIG_ROM_SIZE) || (CACHE_ROM_SIZE >= (2 * CONFIG_ROM_SIZE))
# error "CACHE_ROM_SIZE is not optimal."
# endif
# endif
#endif
#if ((CACHE_ROM_SIZE & (CACHE_ROM_SIZE-1)) != 0)
# error "CACHE_ROM_SIZE is not a power of 2."
Intel cpus: Extend cache to cover complete Flash Device CACHE_ROM_SIZE default is ROM_SIZE, the Flash device size set in menuconfig. This fixes a case where 8 MB SPI flash MTRR setup would not cover the bottom 4 MB when ramstage is decompressed. Verify CACHE_ROM_SIZE is power of two. One may set CACHE_ROM_SIZE==0 to disable this cache. Change-Id: Ib2b4ea528a092b96ff954894e60406d64f250783 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/1146 Tested-by: build bot (Jenkins) Reviewed-by: Sven Schnelle <svens@stackframe.org>
2012-06-30 10:41:08 +02:00
#endif
Re-declare CACHE_ROM_SIZE as aligned ROM_SIZE for MTRR 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>
2014-01-06 10:06:26 +01:00
#define CACHE_ROM_BASE (((1<<20) - (CACHE_ROM_SIZE>>12))<<12)
some ifdef --> if fixes 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@6535 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-21 22:24:43 +02:00
#if (CONFIG_RAMTOP & (CONFIG_RAMTOP - 1)) != 0
No warnings day, next round. 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-06 23:50:21 +02:00
# error "CONFIG_RAMTOP must be a power of 2"
#endif
- Renamed cpu header files git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1659 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2004-10-14 22:13:01 +02:00
#endif /* CPU_X86_MTRR_H */
Reference in a new issue Copy permalink