summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2013-03-29google boards: auto-select CACHE_ROMAaron Durbin
Automatically select CACHE_ROM for all Google boards. Tested by generating a config for the link board. CACHE_ROM was selected and was unable to unselect it using 'make oldconfig'. Change-Id: I8e34207e3929a020bb0280657f95ba7a000ad024 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2963 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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-29memrange: add 2 new range_entry routinesAaron Durbin
Two convenience functions are added to operate on a range_entry: - range_entry_update_tag() - update the entry's tag - memranges_next_entry() - get the next entry after the one provide These functions will be used by a follow on patch to the MTRR code to allow hole punching in WB region when the default MTRR type is UC. Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2924 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29chromeos: remove CACHE_ROM automatic selectionAaron Durbin
It's not appropriate for the chromeos Kconfig to automatically select CACHE_ROM. The reason is that enabling CACHE_ROM is dependent on the board and chipset atrributes. Change-Id: I47429f1cceefd40226c4b943215d627a3c869c7b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2921 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-29sandybridge: add option to mark graphics memory write-combining.Aaron Durbin
The graphics memory can be accessed in a faster manner by setting it to write-combing mode. Add an option to enable write-combining for the graphics memory. Change-Id: I7d37fd78906262aabef92c2b4f4cab0e3f7e4f6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2894 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29haswell: add option to mark graphics memory write-combining.Aaron Durbin
The graphics memory can be accessed in a faster manner by setting it to write-combing mode. Add an option to enable write-combining for the graphics memory. Change-Id: I797fcd9f0dfb074f9e45476773acbfe614eb4b0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2893 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-29lib: add memrange infrastructureAaron Durbin
The memrange infrastructure allows for keeping track of the machine's physical address space. Each memory_range entry in a memory_ranges structure can be tagged with an arbitrary value. It supports merging and deleting ranges as well as filling in holes in the address space with a particular tag. The memrange infrastructure will serve as a shared implementation for address tracking by the MTRR and coreboot mem table code. Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2888 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29stdlib: add ALIGN_UP and ALIGN_DOWN macrosAaron Durbin
There wasn't an equivalent to align down so add ALIGN_DOWN. For symmetry provide an ALIGN_UP macro as well. Change-Id: I7033109311eeb15c8c69c649878785378790feb9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2951 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29resources: introduce IORESOURCE_WRCOMBAaron Durbin
Certain MMIO resources can be set to a write-combining cacheable mode to increase performance. Typical resources that use this would be graphics memory. Change-Id: Icd96c720f86f7e2f19a6461bb23cb323124eb68e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2891 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29resources: remove IORESOURCE_[UMA_FB|IGNORE_MTRR]Aaron Durbin
The IORESOURCE_UMA_FB and IORESOURCE_IGNORE_MTRR attributes on a resource provided hints to the MTRR algorithm. The IORESOURCE_UMA_FB directed the MTRR algorithm to setup a uncacheable space for the resource. The IORESOURCE_IGNORE_MTRR directed the MTRR algorithm to ignore this resource as it was used reserving RAM space. Now that the optimizing MTRR algorithm is in place there isn't a need for these flags. All IORESOURCE_IGNORE_MTRR users are handled by the MTRR code merging resources of the same cacheable type. The users of the IORESOURCE_UMA_FB will find that the default MTRR type calculation means there isn't a need for this flag any more. Change-Id: I4f62192edd9a700cb80fa7569caf49538f9b83b7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2890 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-29coreboot table: use memrange libraryAaron Durbin
Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Iee2a7c37a3f4cf388db87ce40b580f274384ff3c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2917 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29armv7: set cache level explicitly for dcache/unified cache caseDavid Hendricks
This adds a missing CSSELR write in the case of a dcache or unified cache being invalidated by armv7_invalidate_caches(), ensuring that all levels of dcache/unified cache are invalidated as expected when the function is called. Change-Id: Ie90184bf8a8181afa3afe0786897455b30b7f022 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2947 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: invalidate TLB after changing translation table entriesDavid Hendricks
This adds a call to tlb_invalidate_all() after configuring a range of memory. Change-Id: I558402e7e54b6bf9e0b013f153d9b84c0873a6cf Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2946 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: iterate thru all levels when doing dcache opsDavid Hendricks
This makes dcache maintenance functions operate on all levels of cache instead of just the current one. Change-Id: I2708fc7ba6da6740dbdfd733d937e7c943012d62 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2945 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: add functions for reading/writing L2CTLRDavid Hendricks
This adds simple accessor functions for reading/writing L2CTLR. Change-Id: I2768d00d5bb2c43e84741ccead81e529dac9254d Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2948 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29armv7: use stdint.h in cache and MMU filesDavid Hendricks
This makes it easier to copy + paste code into libpayload since libpayload since both coreboot and libpayload have stdint.h and it defines the types needed. Change-Id: Ifa55f04a9bdddd17bc1a2679321a6744c75f25a8 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2944 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29armv7: added paranoia for cache libraryDavid Hendricks
This adds some paranoia to cache manipulation routines: - "memory" is added to the clobber list for functions which clean and/or invalidate dcache or TLB entries. - Remove unneeded clobber list for read_sctlr() Change-Id: Iaa82ef78bfdad4119f097c3b6db8219f29f832bc Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2928 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-28armv7: clean+invalidate all cache levels when disabling MMUDavid Hendricks
This iterates thru all cache levels and cleans + invalidates all data and unified caches before disabling dcache and MMU. Change-Id: I8a671b4c90d7b88b8d0a95947bfa17f912cebaa2 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2930 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-28armv7: cosmetic changes to dcache_op_mva()David Hendricks
This is just a cosmetic change to dcache_op_mva() to (hopefully) make it a easier to follow and more difficult to screw up. Change-Id: Ia348b2d58f2f2bf5c3cafabcfba06bc411937dba Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2927 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-28armv7: fix a bad variable assignmentDavid Hendricks
'<' was used when '<<' is needed. Oops! Change-Id: I8451f76888e86219df16b50739cd2c8db80dcb14 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2941 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-28armv7: pass incremented value to dccimvacDavid Hendricks
This passes the correct value into dccimvac. Change-Id: I6098440ea48a9b6429380d5913fce6d36e3afb41 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2926 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-27exynos5250: assign RAM resources in cpu_init()David Hendricks
This moves the ram resource allocation into cpu_init() so that we no longer rely on declaring a domain in devicetree.cb (which is kind of weird for this platform). This does not cause any actual changes to the coreboot memory table, and paves the way for further updates to Snow's devicetree. Change-Id: I141277f59b5d48288f409257bf556a1cfa7a8463 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2923 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26armv7: fixes for dcache_op_by_mva()David Hendricks
This fixes a couple issues with dcache_op_by_mva(): - Add missing data and instruction sync barriers. - Removes unneded -1 from loop terminating condition. Change-Id: I098388614397c1e53079c017d56b1cf3ef273676 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2913 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26ARMv7: Drop ROMSTAGE_BASE from Makefile.incStefan Reinauer
It's not used (instead ARM puts it in Kconfig) Change-Id: Ia22a7ac756bec4cb6fee00a4d946a020ea6290aa Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2916 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-03-26Revert "coreboot table: use memrange library"Aaron Durbin
This reverts commit 56075eaefcd7ef51464206166b24a0a47a59147f Change-Id: I8a37ce1f5ce36e4a120941ec264140abc9447ff5 Reviewed-on: http://review.coreboot.org/2915 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-26x86: dynamic cbmem: fix acpi reservationsAaron Durbin
If a configuration was not using RELOCTABLE_RAMSTAGE, but it was using HAVE_ACPI_RESUME then the ACPI memory was not being marked as reserved to the OS. The reason is that memory is marked as reserved during write_coreboot_table(). These reservations were being added to cbmem after the call to write_coreboot_table(). In the non-dynamic cbmem case this sequence is fine because cbmem area is a fixed size and is already reserved. For the dynamic cbmem case that no longer holds by the nature of the dynamic cbmem. Change-Id: I9aa44205205bfef75a9e7d9f02cf5c93d7c457b2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2897 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-26coreboot table: use memrange libraryAaron Durbin
Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Ic667df444586c2b5b5f2ee531370bb790d683a42 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2896 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-26Revert "samsung/exynos5: add resource functions for the display port"David Hendricks
This reverts commit 9427ca151e44644238b1b52138894195a9f5175f Looks like we were a bit too anxious to see this one get in. The devicetree.cb change seems to have broken things. coreboot memory table: 0. 0000000050000000-000000005000ffff: RESERVED 1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES 2. 0000014004000000-00000140044007ff: RESERVED Before this patch: coreboot memory table: 0. 0000000040000000-00000000bfefffff: RAM 1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES Change-Id: I618e4f1976265d56cfd6a61d0c5736c55a0f3cec Reviewed-on: http://review.coreboot.org/2914 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-26ARMv7: Drop XIP relocation code for romstageStefan Reinauer
It was never used, because we pushed romstage_null into the CBFS instead of romstage_xip. It's not surprising this worked, but it was a crude hack. Get rid of all the intermediate objects that are not needed. This could probably be further simplified to use the default cbfs mechanism in our build system instead of having a specific rule for romstage, but that's for another day. Change-Id: I492ca2015ec81e13499fcd8dd331371f46a31c78 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2912 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-26samsung/exynos5: add resource functions for the display portRonald G. Minnich
This does NOT turn on the graphics. The device tree has been changed enough so that, at the very least, the correct functions are called at the correct time, with the correct paramaters. We decided to yank the I2C entries as they did not obvious function and might not even have been correct. Not working, seemingly, but we need to add a 4M resource for memory, and it seems it needs to be fixed at the address shown. This address was chosen from current hardware. We realized that the display code should be part of the cpu -- that's how the hardware works! Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2615 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-26armv7: add new dcache and MMU setup functionsDavid Hendricks
This adds new MMU setup code. Most notably, this version uses cbmem_add() to determine the translation table base address, which in turn is necessary to ensure payloads which wipe memory can tell which regions to wipe out. TODOs: - Finish cleaning up references to old cache/MMU stuff - Add L2 setup (from exynos_cache.c) - Set up ranges dynamically rather than in ramstage's main(). Change-Id: Iba5295a801e8058a3694e4ec5b94bbe9a69d3ee6 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2877 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-25AMD Inagua: add GEC firmware, document Broadcom BCM57xx Selfboot Patch formatJens Rottmann
The Broadcom BCM5785 GbE MAC integrated in the AMD Hudson-E1 requires a secret sauce firmware blob to work. As Broadcom wasn't willing to send us any documentation (or a firmware adapted to our Micrel PHY) I had to figure out everything by myself in many weeks of hard detective work. In the end we had to settle for a different solution, the modified firmware I devised for the Micrel KSZ9021 PHY on our early FrontRunner-AF prototypes is no longer needed for the production version. However the information contained here might be very useful for others who'd like to use a competing PHY instead of Broadcom's 50610, so it should not get lost. And of course the unmodified, but now in large parts documented Selfboot Patch is needed to get Ethernet on AMD Inagua. The code introduced here should make the Hudson's internal MAC usable without having to add the proprietary firmware blob. - At least in theory. Unfortunately we've been unable to actually test this patch on Inagua, therefore the broadcom_init() call in mainboard.c was left commented out. If you have the hardware and can confirm it works please enable it. The fun thing is: as Broadcom refused to do any business with us at all, or send us any documentation, we never had to sign an NDA with them. This leaves me free to publish everything I have found out. :-) Change-Id: I94868250591862b376049c76bd21cb7e85f82569 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2831 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-23dynamic cbmem: fix memconsole and timestampsAaron Durbin
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM rely on EARLY_CBMEM_INIT. This isn't true in the face of DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT. Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem implementation when COLLECT_TIMESTAMPS is selected. Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2895 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23resources: introduce reserved_ram_resource()Aaron Durbin
mmio_resource() was previously being used for reserving RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute. Instead, be more explicit for those uses with reserved_ram_resource(). bad_ram_resource() now calls reserved_ram_resource(). Those resources are marked as cacheable but reserved. The sandybridge and haswell code were relying on the implementation fo the MTRR algorithm's interaction for reserved regions. Instead be explicit about what ranges are MMIO reserved and what are RAM reserved. Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2886 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23x86: mark .textfirst as allocatable and executableAaron Durbin
When the linking of ramstage was changed to use an intermeidate object with all ramstage objects in it the .textfirst section was introduced to keep the entry point at 0. However, the section was not marked allocatable or executable. Nor was it marked as @progbits. That didn't cause an issue on its own since .textfirst was directly called out in the linker script. However, the rmodule infrastructure relies on all the relocation entries being included in the rmodule. Without the proper section attributes the .rel.textfirst section entries were not being included in the final ramstage rmodule. Change-Id: I54e7055a19bee6c86e269eba047d9a560702afde Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2885 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23relocatable ramstage: fix linkingAaron Durbin
The ramstage is now linked using an intermediate object that is created from the complete list of ramstage object files. The rmodule code was developed when ramstage was linked using an archive file. Because of the fact that the rmodule headers are not referenced from any other object the link could start by specifying the rmodule header object for ramstage. That, however, is not the case as all ramstage objects are included in the intermediate linked object. Therefore, the ramstage_module_header.ramstage.o object file needs to be removed from the object list for the ramstage rmodule. Change-Id: I6a79b6f8dd1dbfe40fdc7753297243c3c9b45fae Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2884 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23vboot module: fix compilation issuesAaron Durbin
There were 3 things stopping the vboot module from being compiled: 1. The vboot_reference code removed in the firmware/arch/$(ARCH)/include directory. This caused romcc to fail because romcc fails if -I<dir> points to non-existent directory. 2. The rmodule API does not have the no-clearing-of-bss variant of the load function. 3. cbfs API changes. Change-Id: I1e1296c71c5831d56fc9acfaa578c84a948b4ced Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2881 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23x86: expose console_tx_flush in romstageAaron Durbin
The vboot module relied on being able to flush the console after it called vtxprintf() from its log wrapper function. Expose the console_tx_flush() function in romstage so the vboot module can ensure messages are flushed. Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2882 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23rmodule: align ld script with latest x86 ld scriptAaron Durbin
The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23cbfs: fix relocation ramstage compiler errorsAaron Durbin
There were some cbfs calls that did not get transitioned to the new cbfs API. Fix the callsites to conform to the actual cbfs, thus fixing the copilation errors. Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2880 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22Unify setting i82801e LPCKyösti Mälkki
Make it more similar to i82801d LPC init. Change-Id: I7b32747ee8012c220c8628994d749999c144b716 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2545 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
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-22Add support for ASUS F2A85-M boardRudolf Marek
The patch is based on Thatcher board. So far it boots Linux (3.2/3.7), internal network adapter works, AHCI works. External PCI/PCIe slots works too. Power management/ACPI seems to work. Internal VGA works with dumped ROM (VGA/DVI), but lacks GART. PCI pref devices are being relocated by Linux, reason unknown. This is a good start. USB and XHCI untested but visible. Change-Id: I1869aecb2634d548b00b3c9139517d6a0e0c9817 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/2038 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-22Fix compilation of Intel LynxPoint based boardsStefan Reinauer
The haswell patches that verified correctly were not yet submitted, but verified correctly. However they still used romcc_io.h which was dropped in another patch earlier today. With a lot of development happening in parallel, this is unfortunately nothing that the gerrit 2.6 Rebase If Necessary submit type could have fixed. Change-Id: Ifef9ae05b22c408e78d6cff37defd68e4ed91ed9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2876 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-22Asrock E350M1: Use SPD read code from F14 wrapperJens Rottmann
Changes: - Get rid of the E350M1 mainboard specific code and use the platform generic function wrapper that was added in change http://review.coreboot.org/#/c/2497/ AMD f14: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb - Add the ASF init that used to be in the SPD read code into mainboard_enable() Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: I08c2aebc62facc14f94400ee1ad188901ba73f19 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2875 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-19 16:01:22 +0000