summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-03-30armv7: import updated cache/MMU stuff from corebootDavid Hendricks
This imports the newest cache and MMU code from coreboot. This time it's so new that it hasn't even been checked in to coreboot. However, this version at least allows DMA to work properly for the MSHC driver. So even if we rebase a few more times, this version is at least a step in the right direction. Note: This omits the stuff that sets up dcache policy since libpayload should not need to worry about that and it depends on cbmem stuff. Change-Id: Idd42b083e8019634aaaa44d5bf5b51db6c3912f5 Signed-off-by: David Hendricks <dhendrix@google.com> Reviewed-on: http://review.coreboot.org/2975 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-03-30armv7: import new cache maintenance API from corebootDavid Hendricks
This imports the new cache maintenance API from coreboot at commit bba8090. This is a BSD-licensed implementation which exposes cache maintenance opertaions necessary for payloads for things such as DMA transfers. Change-Id: I554676db89517bebc6edae4f7ab7e5882e6f986d Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2974 Tested-by: build bot (Jenkins)
2013-03-30x86: Drop BOARD_HAS_FADTKyösti Mälkki
There is a wildcard rule to include mainboard/fadt.c. Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2940 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-30inteltool: Add Cougar/Panther Point IDs to rootcmplx.cNico Huber
This adds the PCI IDs of Intel's Cougar Point and Panther Point platform controller hubs (PCH) to the dumping of the root complex configuration under the root complex base address (RCBA). Those PCHs are handled exactly as the older ICHs which can be seen in [1] and [2]. I've tested dumping with an H77 PCH. NM70 is missing in [1]. Therefore, I didn't add it here. [1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet Document-Number: 324645-006 [2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) - Datasheet Document-Number: 326776-003 Change-Id: I2296caae57e614171300362d41715deecec77762 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/2986 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-30AMD Hudson boards: Use `hudson.h` for `pm_ioread` and delete `pmio.h`Paul Menzel
Unfortunately, an unneeded mainboard specific `pmio.h` was created when merging the AMD Parmer and Thatcher ports. Rudolf used the header from a more generic location southbridge/amd/agesa/hudson/hudson.h doing the the ASUS F2A85-M port, but did not delete the `pmio.h` now unused `pmio.h` header file. So adapt AMD Parmer and Thatcher to use the Hudson one as done for the ASUS F2A85-M and delete the now unused mainboard specific header file `pmio.h` to avoid duplication. Change-Id: I961cd145ebc3b83e31c638ac453ac95ee19c18db Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2958 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-30ASRock E350M1: irq_tables.c: Include `cpu/amd/amdfam14.h` for `get_bus_conf`Paul Menzel
When building the ASRock E350M1, the following warning is shown. $ make # on Jenkins (build server) […] CC mainboard/asrock/e350m1/irq_tables.ramstage.o src/mainboard/asrock/e350m1/irq_tables.c: In function 'write_pirq_routing_table': src/mainboard/asrock/e350m1/irq_tables.c:64:2: warning: implicit declaration of function 'get_bus_conf' [-Wimplicit-function-declaration] […] Including the header file `cpu/amd/amdfam14.h` declaring the function addresses this warning. The same change was done in the following commit for the AMD Persimmon board. commit d7a696d0f229abccc95ff411f28d91b9b796ab74 Author: efdesign98 <efdesign98@gmail.com> Date: Thu Sep 15 15:24:26 2011 -0600 Persimmon updates for AMD F14 rev C0 Reviewed-on: http://review.coreboot.org/137 Change-Id: I40b5735feb7116961ca0c4d6940ec55cdf42d3c6 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2956 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-30ASRock E350M1: get_bus_conf.c: Include `agesawrapper.h` for ↵Paul Menzel
`agesawrapper_amdinitlate` When building the ASRock E350M1, the following warning is shown. $ make # on Jenkins (build server) […] CC mainboard/asrock/e350m1/get_bus_conf.ramstage.o src/mainboard/asrock/e350m1/get_bus_conf.c: In function 'get_bus_conf': src/mainboard/asrock/e350m1/get_bus_conf.c:82:3: warning: implicit declaration of function 'agesawrapper_amdinitlate' [-Wimplicit-function-declaration] […] Including the header file `agesawrapper.h` declaring the function `agesawrapper_amdinitlate` fixes this warning. All AMD Family 14 based boards already include that header file. For example for the board AMD Persimmon the following patch fixed this warning. commit d7a696d0f229abccc95ff411f28d91b9b796ab74 Author: efdesign98 <efdesign98@gmail.com> Date: Thu Sep 15 15:24:26 2011 -0600 Persimmon updates for AMD F14 rev C0 Reviewed-on: http://review.coreboot.org/137 Change-Id: I695420b7071e07cb7d4667b2479b9a26ea13723d Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2955 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-30ASRock E350M1: PlatformGnbPcie.c: Do not return anything for void return typePaul Menzel
When building the ASRock E350M1, the following warning is shown. $ make # on Jenkins (build server) […] CC mainboard/asrock/e350m1/PlatformGnbPcie.romstage.o CC mainboard/asrock/e350m1/agesawrapper.romstage.o CC mainboard/asrock/e350m1/buildOpts.romstage.o src/mainboard/asrock/e350m1/PlatformGnbPcie.c: In function 'OemCustomizeInitEarly': src/mainboard/asrock/e350m1/PlatformGnbPcie.c:131:5: warning: 'return' with a value, in function returning void [enabled by default] […] The function signature is (the return type might not be part of this though [1]), VOID OemCustomizeInitEarly ( IN OUT AMD_EARLY_PARAMS *InitEarly ) so do not return anything. All other AMD Family 14 boards already have the correct code. For example following commit fixed this for AMD Persimmon. commit d7a696d0f229abccc95ff411f28d91b9b796ab74 Author: efdesign98 <efdesign98@gmail.com> Date: Thu Sep 15 15:24:26 2011 -0600 Persimmon updates for AMD F14 rev C0 Reviewed-on: http://review.coreboot.org/137 [1] http://cboard.cprogramming.com/cplusplus-programming/117286-what-exactly-function-signature.html Change-Id: Ie60246bd9bb8452efd096e6838d8610f6364a6aa Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2954 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-30armv7: change some unsigned ints to uint32_tDavid Hendricks
Use register-sized types in case the inline assembler doesn't do so automatically. Change-Id: I3202ba972ef2548323fe557f45dc4b0b1cf6c818 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2983 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29armv7: remove loop from dcache_mmu_disable()David Hendricks
dcache_mmu_disable() no longer needs to have its own iterative loop to select each cache level of cache since dcache_clean_invalidate_all() does that now. Change-Id: I5ca273f98943981b943c1c1622f4574d7133fb50 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2967 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29snow: explicitly configure L2 cacheDavid Hendricks
This adds a call to explicitly configure L2 cache (though defaults should be set correctly). Change-Id: I120e29c986918c2904a0332e46fcf9f1c5380d85 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2950 Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29exynos5250: Add function for configuring L2 cacheDavid Hendricks
This adds a new function to configure L2 cache for the exynos5250 and deprecates the old function. Change-Id: I9562f3301aa1e2911dae3856ab57bb6beec2e224 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2949 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-29AMD CIMx SB800: Update Kconfig help texts to new SATA mode defaultPaul Menzel
In the following commit commit ee5c111755ac4acc6dfb6e10a4e271211e149a39 Author: Paul Menzel <paulepanter@users.sourceforge.net> Date: Tue Mar 12 12:41:40 2013 +0100 AMD CIMx SB800: Enable AHCI mode for SATA controller by default Reviewed-on: http://review.coreboot.org/2661 I forgot to update the help texts to the new SATA mode default. Do so now. Additionally note that help texts for `choice` do not seem to be shown. Change-Id: I17f401633a2136efca2b21a621482e0724ff9f04 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2936 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29superiotool: Allow to override Makefile variables `CC`, `INSTALL` and `PREFIX`Paul Menzel
This way for example a different compiler can easily be used. CC=clang make Change-Id: I50b83554fd4826d00d87e60a30eb1f6a88834397 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2935 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-29armv7: update sync barrier usage in dcache_op_set_way()David Hendricks
This moves the dsb() before the loop to sync any outstanding memory accesses, and adds an isb() after the loop to ensure all outstanding instructions are completed. Change-Id: I1a11b39f104ae780370cfd2db3badcf4e91dc017 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2929 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29wtm2: auto-select CACHE_ROMAaron Durbin
The WTM2 board has a fairly static configuration. As such it's been tested to properly handle CACHE_ROM given the number of MTRRs the boards' CPUs supports. Change-Id: Ic67cd1eebce580003dc6b6655cac2b2a92dd1b5f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2964 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29AMD Inagua: Kconfig: Remove `WARNINGS_ARE_ERRORS` to treat warnings as errorsPaul Menzel
Now that the AMD Inagua builds without any warnigs, remove the config option `WARNINGS_ARE_ERRORS` set to no by default from the file `Kconfig` so warnings are treated as errors to prevent code from being added in the future introducing warnings. Change-Id: I0b58bd74b06dc54d180b16d6a207354b5fea0d0f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2953 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29AMD Inagua: broadcom.c: Add missing prototype for `broadcom_init()`Paul Menzel
Building the AMD Inagua board, the following warning is thrown. CC mainboard/amd/inagua/get_bus_conf.ramstage.o src/mainboard/amd/inagua/broadcom.c:319:6: warning: no previous prototype for 'broadcom_init' [-Wmissing-prototypes] This warning was introduced by commit 3926b4c5. commit 3926b4c520e74da9dc22e3d136a8a178483e0d25 Author: Jens Rottmann <JRottmann@LiPPERTembedded.de> Date: Fri Mar 1 19:41:41 2013 +0100 AMD Inagua: add GEC firmware, document Broadcom BCM57xx Selfboot Patch format Reviewed-on: http://review.coreboot.org/2831 Adding the prototype to `broadcom.c` and removing it from `mainboard.c` fixes the warning. Change-Id: I1da0c4e972e129047dd8230d573f1c43fd71eb20 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2952 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29inteltool: Support GPIO registers on Cougar/Panther PointNico Huber
This adds the GPIO register definitions for Intel's Cougar Point and Panther Point platform controller hubs (PCH). All information is taken from the public specifications in [1] and [2]. I've tested it with an H77 PCH. NM70 is missing in [1]. Therefore, I didn't add it here. [1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet Document-Number: 324645-006 [2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) - Datasheet Document-Number: 326776-003 Change-Id: I31711e24f852e68b3c113e3bd9243dc7e89ac197 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/2961 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29inteltool: Add definitions for Cougar/Panther Point PCI IDsNico Huber
This adds correspondings #defines for the PCI IDs of the LPC device on Intel's Cougar Point and Panther Point platform controller hubs. Those will be used more in later commits. I've checked all those IDs against the specification updates [1] and [2]. [1] Intel 6 Series Chipset and Intel C200 Series Chipset Specification Update Document-Number: 324646-019 [2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) Family - Datasheet Specification Update Document-Number: 326777-010 Change-Id: Ibef5a30d283c568c345eb8d8149723e7a3049272 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/2960 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-29libpayload: add x86 ROM variable MTRR supportAaron Durbin
On x86, coreboot may allocate a variable range MTRR for enabling caching of the system ROM. Add the ability to parse this structure and add the result to the sysinfo structure. An example usage implementation would be to obtain the variable MTRR index that covers the ROM from the sysinfo structure. 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: I3bfe2028d8574d3adb1d85292abf8f1372cf97fa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2920 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-28crossgcc: Fix building with texinfo-5.xNico Huber
If you have a recent version of texinfo installed, building the reference toolchain fails with the following error: (in util/crossgcc/build-gcc/crossgcc-build.log) [...]/gcc-4.7.2/gcc/doc/cppopts.texi:806: @itemx must follow @item Looks like a warning-became-an-error problem in texinfo, to me. Fix that by making every erroneous @itemx an @item. Change-Id: I685ae1ecfee889b7c857b148cfab7411a10e7ecd Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/2939 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Idwer Vollering <vidwer@gmail.com>
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-27cbfstool: Add update-fit commandAaron Durbin
Add support for filling in the Firmware Interface Table. For now it only supports adding microcode entries. It takes 2 options: 1. Name of file in cbfs where the mircocode is located 2. The number of empty entries in the table. Verified with go firmware tools. Also commented out updating microcode in the bootblock. When romstage runs, the CPUs indicate their microcode is already loaded. Change-Id: Iaccaa9c226ee24868a5f4c0ba79729015d15bbef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2712 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-27cbfstool: Fix cbfs_image.cStefan Reinauer
- The read-only structures are const now - cosmetic fixes - put { on a new line for functions - move code after structures Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2922 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
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-26libpayload: Fix prototype warnings in PDCursesStefan Reinauer
This fixes the following PDCurses warnings: CC curses/pdcurses-backend/pdcsetsc.libcurses.o curses/pdcurses-backend/pdcsetsc.c: In function 'PDC_curs_set': curses/pdcurses-backend/pdcsetsc.c:17:9: warning: implicit declaration of function 'serial_cursor_enable' [-Wimplicit-function-declaration] curses/pdcurses-backend/pdcsetsc.c:22:9: warning: implicit declaration of function 'video_console_cursor_enable' [-Wimplicit-function-declaration] CC curses/pdcurses-backend/pdcutil.libcurses.o curses/pdcurses-backend/pdcutil.c:30:6: warning: no previous prototype for 'curses_enable_serial' [-Wmissing-prototypes] curses/pdcurses-backend/pdcutil.c:35:6: warning: no previous prototype for 'curses_enable_vga' [-Wmissing-prototypes] curses/pdcurses-backend/pdcutil.c:40:5: warning: function declaration isn't a prototype [-Wstrict-prototypes] curses/pdcurses-backend/pdcutil.c:45:5: warning: function declaration isn't a prototype [-Wstrict-prototypes] Change-Id: If0d4d475d3006f1a77f67ec46c6bdf4ee2906981 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2908 Reviewed-by: Dave Frodin <dave.frodin@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26libpayload: Fix type issuesStefan Reinauer
There were a number of type issues in libpayload that sneaked in with 903f8e0. - size_t and ssize_t were conflicting with gcc builtins - some stdint types were used in libpayload but not defined in our stdint.h With this patch it's possible to compile libpayload with the reference toolchain again. Change-Id: Idd5ccfdd9f3536b36bceca2d101e7405883b10bc Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2903 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26libpayload: fix size_t handlingStefan Reinauer
libcbfs was using printf for size_t typed variables. However, printf did not support printing those. This patch fixes the issue, removing the warning when compiling ram_media.c libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat] libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat] Change-Id: Iaf6e723f9a5b0a61a39d3125036fee9853e37ba8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2904 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26libpayload: Fix const warnings in keyname() and termname()Stefan Reinauer
The keyname() and termname() functions were creating a whole lot of warnings of the style curses/PDCurses-3.4/pdcurses/keyname.c:41:9: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] This patch fixes them. Change-Id: Iae3c4e5201b48c2d2033cac48577e0462a34f309 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2905 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-26libpayload: Fix variable shadowing in PDCursesStefan Reinauer
PDCurses has a function called overlay() and also uses overlay as a variable name in some functions. This patch fixes the ambiguity that caused warnings like curses/PDCurses-3.4/pdcurses/overlay.c: In function '_copy_win': curses/PDCurses-3.4/pdcurses/overlay.c:51:39: warning: declaration of 'overlay' shadows a global declaration [-Wshadow] In file included from curses/PDCurses-3.4/curspriv.h:16:0, from curses/PDCurses-3.4/pdcurses/overlay.c:3: curses/PDCurses-3.4/curses.h:1014:9: warning: shadowed declaration is here [-Wshadow] Change-Id: I907653df0c8bb32c98bdcbc6476e94d2da6e0e90 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2906 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-26libpayload: Fix missing prototype warning for Xinitscr()Stefan Reinauer
Xinitscr is only used internally in PDCurses, unless XCURSES is defined. This patch fixes a warning that is produced because of that. Change-Id: I211f75717276cf028e0b435f328d1687d3536eb7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2907 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-26libpayload: Fix unused function warning in EHCI stackStefan Reinauer
The function dump_qh() was added a while back but never used. Hide it behind USB_DEBUG so it doesn't cause warnings when not debugging the USB stack. Change-Id: Idb3c7bb214895ef82676d181836a578bf161e8e0 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2909 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
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-25libpayload: Fix Config.in warningStefan Reinauer
PDcurses is already default. Hence drop the additional attempt that is not supported by Kconfig. Config.in:123:warning: defaults for choice values not supported Change-Id: I12cb5ea0bef2f146cf237c7a3cc9293a600d736b Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2902 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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-25libpayload: fix use-after-free in usb_exit()Mathias Krause
The controller's shutdown function free()s the controller structure so we shouldn't access it any more after calling shutdown. As all controllers detach themself, i.e. unchain themself from usb_hcs, just keep iterating over usb_hcs until it's NULL. Change-Id: Ie85caba0f685494c3fe04c550a5a14bc4158a94e Signed-off-by: Mathias Krause <minipli@googlemail.com> Reviewed-on: http://review.coreboot.org/2900 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-03-25libpayload: EHCI - detach controller in ehci_shutdown()Mathias Krause
It shouldn't be used any more as we're about to free() the memory behind the controller -- therefore detach it. Change-Id: I875322a9940570c51d412a7f3bfb6af4ea3b3764 Signed-off-by: Mathias Krause <minipli@googlemail.com> Reviewed-on: http://review.coreboot.org/2899 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.huber@secunet.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-23xcompile: honor LINKER_SUFFIX variableAaron Durbin
In commit e820e5cb3aed810fa9ba6047ce9b8bf352335e32 titled "Make xcompile support multiple architectures" the LINKER_SUFFIX variable was introduced to bypass gold if the bfd linker was available. However, the LINKER_SUFFIX wasn't honored when the compiler evironment variables were set. Fix the original intention. Change-Id: I608f1e0cc3d0bea3ba1e51b167d88c66d266bceb Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2879 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-22libpayload: Add comments on virtual pointers in lib_sysinfoNico Huber
After another incident related to virtual pointers in lib_sysinfo (and resulting confusion), I decided to put some comments on the matter into the code. Remember, we decided to always use virtual pointers in lib_sysinfo, but it's not always obvious from the code, that they are. See also: 425973c libpayload: Always use virtual pointers in struct sysinfo_t 593f577 libpayload: Fix use of virtual pointers in sysinfo Change-Id: I886c3b1d182cba07f1aab1667e702e2868ad4b68 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/2878 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-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)
2013-03-22FrontRunner/Toucan-AF: Use SPD read code from F14 wrapperJens Rottmann
Changes: - Get rid of the LiPPERT FrontRunner-AF and Toucan-AF 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: I4ee5e1bc34f4caee20615c48248d4f7605c09377 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/2874 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-22libpayload: initial test case + tiny "framework"Patrick Georgi
This adds a test case for using CBFS images that reside in RAM and a Makefile to run it (and maybe other tests in the future). The test concerns an issue in libcbfs when using x86 style CBFS images in non-canonical locations (eg. when loading CBFS images for processing). Use with "make run" inside the tests directory. Change-Id: I1af3792a1451728ff9594ba7f0410027cdecb59d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2623 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22cbfstool: Fix initial empty space in image creation.Hung-Te Lin
When calculating initial CBFS empty entry space, the size of header itself must be not included (with the reserved space for entry name). This is a regression of the old cbfstool size bug. Before this fix, in build process we see: OBJCOPY cbfs/fallback/romstage_null.bin W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... And checking the output binary: cbfstool build/coreboot.pre1 print -v -v DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes) DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30 W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00. coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64 Name Offset Type Size (empty) 0x0 null 261296 DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0 After this fix, no more alerts in build process. Verified to build successfully on x86/qemu and arm/snow configurations. Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2731 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22Unify coreboot table generationStefan Reinauer
coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-22wtm2: build-time dev and recovery settingsAaron Durbin
It's helpful to switch back and forth for developer and recovery settings while testing boards. The wtm2 board currently doesn't have gpios which dynamically seelect that. Might as well make it easy to change the value for each setting with one define. The original defaults are kept. Change-Id: I7b928c592fd20a1b847e4733f4cdef09d6ddad4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2861 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22vboot: pass correct coreboot include pathsAaron Durbin
The coreboot include were not being passed correctly when building vboot_reference. The paths being included were of the src/<dir> form. However, vboot_reference lives in src/../vboot_reference. That coupled with the recursive make call made vboot_reference not see coreboot's header files. Fix this by appending ../ to coreboot's default include paths. Change-Id: I73949c6f854ecfce77ac36bb995918d51f91445e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2860 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22haswell: Add microcode for ULT C0 stepping 0x40651Duncan Laurie
Change-Id: I53982d88f94255abdbb38ca18f9d891d4bc161b0 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2858 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: add vboot_handoff to coreboot tablesAaron Durbin
The vboot_handoff structure contians the VbInitParams as well as the shared vboot data. In order for the boot loader to find it, the structure address and size needs to be obtained from the coreboot tables. Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2857 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22haswell: vboot path support in romstageAaron Durbin
Take the vboot path in romstage. This will complete the haswell support for vboot firmware selection. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: Ie2b0a34e6c5c45e6f0d25f77a5fdbaef0324cb09 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2856 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22haswell boards: support added chromeos functionAaron Durbin
The get_write_protect_state() function was added to the chromeos API that needs to be supported by the boards. Implement this support. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: Ifd213be25304163fc61d153feac4f5a875a40902 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2855 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22romstage: add support for vboot firmware selectionAaron Durbin
This patch implements support for vboot firmware selection. The vboot support is comprised of the following pieces: 1. vboot_loader.c - this file contains the entry point, vboot_verify_firmware(), for romstage to call in order to perform vboot selection. The loader sets up all the data for the wrapper to use. 2. vboot_wrapper.c - this file contains the implementation calling the vboot API. It calls VbInit() and VbSelectFirmware() with the data supplied by the loader. The vboot wrapper is compiled and linked as an rmodule and placed in cbfs as 'fallback/vboot'. It's loaded into memory and relocated just like the way ramstage would be. After being loaded the loader calls into wrapper. When the wrapper sees that a given piece of firmware has been selected it parses firmware component information for a predetermined number of components. Vboot result information is passed to downstream users by way of the vboot_handoff structure. This structure lives in cbmem and contains the shared data, selected firmware, VbInitParams, and parsed firwmare components. During ramstage there are only 2 changes: 1. Copy the shared vboot data from vboot_handoff to the chromeos acpi table. 2. If a firmware selection was made in romstage the boot loader component is used for the payload. Noteable Information: - no vboot path for S3. - assumes that all RW firmware contains a book keeping header for the components that comprise the signed firmware area. - As sanity check there is a limit to the number of firmware components contained in a signed firmware area. That's so that an errant value doesn't cause the size calculation to erroneously read memory it shouldn't. - RO normal path isn't supported. It's assumed that firmware will always load the verified RW on all boots but recovery. - If vboot requests memory to be cleared it is assumed that the boot loader will take care of that by looking at the out flags in VbInitParams. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2854 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22rmodule: add vboot rmodule typeAaron Durbin
For completeness add a vboot rmodule type since vboot will be built as an rmodule. Change-Id: I4b9b1e6f6077f811cafbb81effd4d082c91d4300 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2853 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22timestamp: add vboot check pointsAaron Durbin
It's desirable to measure the vboot firmware selection time. Therefore add vboot check points to the timestamp ids. Change-Id: Ib103a9e91652cf96abcacebf0f211300e03f71fd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2852 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-03-22cbmem: add vboot cmbem idAaron Durbin
The vboot firmware selection from romstage will need to pass the resulting vboot data to other consumers. This will be done using a cbmem entry. Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2851 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>