summaryrefslogtreecommitdiff
path: root/src/cpu/x86/mtrr/mtrr.c
AgeCommit message (Collapse)Author
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-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-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-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 2024-11-07 16:08:19 +0000