| Age | Commit message (Collapse) | Author |
|---|
|
Now that the ASRock E350M1 builds without any warnings, 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: Idfecfb1434158969334a4b37972b5fc6fd76e72a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3014
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
When building the ASRock E350M1, the following warnings are shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/buildOpts.romstage.o
In file included from src/mainboard/asrock/e350m1/buildOpts.c:294:0:
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:6: warning: "DDR1333_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2071:40: warning: "DDR1866_FREQUENCY" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:5: warning: "TIMING_MODE_AUTO" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2089:31: warning: "TIMING_MODE_SPECIFIC" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:5: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2113:33: warning: "QUADRANK_UNBUFFERED" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:5: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
src/vendorcode/amd/agesa/f14/Include/PlatformInstall.h:2127:28: warning: "POWER_DOWN_BY_CHIP_SELECT" is not defined [-Wundef]
[…]
Adding the corresponding defines as done for AMD Persimmon in
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
addresses the warnings.
Change-Id: Id311b2dacdba5f2e6b4d834e43db0310213a35f9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2962
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On certain architectures such as x86 the bootstrap processor
does most of the work. When CACHE_ROM is employed it's appropriate
to ensure that the caching enablement of the ROM is disabled so that
the caching settings are symmetric before booting the payload or OS.
Tested this on an x86 machine that turned on ROM caching. Linux did not
complain about asymmetric MTRR settings nor did the ROM show up as
cached in the MTRR settings.
Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds configuration of SerialIO devices in the Lynxpoint-LP
chipset. This includes DMA, I2C, SPI, UART, and SDIO controllers.
There is assorted magic setup necessary for the devices and
while it is similar for each device there are subtle differences
in some register settings.
These devices must be put into "ACPI Mode" in order to take
advantage of S0ix. When in ACPI mode the allocated PCI BARs
must be passed to ACPI so it can be relayed to the OS. When
the devices are in ACPI mode BAR0+BAR1 is saved into ACPI NVS
and then updated and returned when the OS calls _CRS.
Note that is is not entirely complete yet. We need to update
the IASL compiler in our build environment to support ACPI 5.0
in order to be able to pass the FixedDMA entries to the kernel.
There are also no ACPI methods defined yet to do D0->D3->D0
transitions for actually entering/exiting S0ix states.
This is hard to test right now because our kernel does not support
any of these devices in ACPI mode. I was able to build and test
the upstream bleeding-edge branch of the linux-pm git tree. With
that tree I was able to enumerate and load the driver for the
DesignWare I2C driver and attempt to probe the I2C bus -- although
there are no devices attatched.
I am also able to see the resources from ACPI in /proc/iomem get
reserved properly in the kernel.
Change-Id: Ie311addd6a25f3b7edf3388fe68c1cd691a0a500
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2971
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This enables all of the SerialIO devices and sets the flag
to put them in ACPI mode.
Change-Id: I7436c47d26028e95bbefafc320854c7cc34a4d44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2972
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This bit offset is incorrect and should only be set based
on another bit in a different register.
Change-Id: I6037534236e3a4a5d15e15011ed9b5040b435eaf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2973
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I did not check what was once after the 'and'.
Change-Id: I9f3f725bec281a94abdb2eeb692a96fecdebcc0c
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/2999
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The TPM code wasn't previously honoring MOCK_TPM=1. Because of this,
boards with TPMs that didn't handle S3 resume properly would cause a
hard reset. Allow one to build with MOCK_TPM=1 on the command line so
that S3 can still work.
Change-Id: I9adf06647de285c0b0a3203d8897be90d7783a1e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2976
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The new enable_pm1() function was doing 2 things wrong:
1. It was doing a RMW of the pm1 register. This means we were
keeping around the enables from the OS during S3 resume. This
is bad in the face of the RTC alarm waking us up because it would
cause an infinite stream of SMIs.
2. The register size of PM1_EN is 16-bits. However, the previous
implementation was accessing it as a 32-bit register.
The PM1 enables should only be set to what we expect to handle in the
firmware before the OS changes to ACPI mode.
Change-Id: Ib1d3caf6c84a1670d9456ed159420c6cb64f555e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2978
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Previously southbridge_smm_init() was provided that did both
the clearing of the SMM state and enabling SMIs. This is
troublesome in how haswell machines bring up the APs. The BSP
enters SMM once to determine if parallel SMM relocation is possible.
If it is possible the BSP releases the APs to do SMM relocation.
Normally, after the APs complete the SMM relocation, the BSP would then
re-enter the relocation handler to relocate its own SMM space.
However, because SMIs were previously enabled it is possible for an SMI
event to occur before the APs are complete or have entered the
relocation handler. This is bad because the BSP will turn off parallel
SMM save state. Additionally, this is a problem because the relocation
handler is not written to handle regular SMIs which can cause an
SMI storm which effectively looks like a hung machine. Correct these
issues by turning on SMIs after all the SMM relocation has occurred.
Change-Id: Id4f07553b110b9664d51d2e670a14e6617591500
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Put the ASL snippet for inclusion in the DSDT under the `acpi/`
folder as it is done for the other Super I/O devices.
$ find src/superio/ -name *asl
src/superio/ite/it8772f/acpi/superio.asl
src/superio/smsc/mec1308/acpi/superio.asl
src/superio/smsc/sio1007/acpi/superio.asl
src/superio/winbond/w83627hf/devtree.asl
As there are no users of this file yet, no other adaptations need
to be made.
Change-Id: Id10cd8897592b780c9fd3bd6b45ada4cf1fcf33e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2937
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c:64:12: warning: unused variable 'dev' [-Wunused-variable]
[…]
Removing the variable `dev` addresses the 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: I83f4630cb6ab1e4c95d04b4e8423850ed1858e45
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2965
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mptable.ramstage.o
src/mainboard/asrock/e350m1/mptable.c: In function 'smp_write_config_table':
src/mainboard/asrock/e350m1/mptable.c:58:3: 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: I7912571fa57f6512b10fc9b5845427fcb6eb50c0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When building the ASRock E350M1, the following warning is shown.
$ make # on Jenkins (build server)
[…]
CC mainboard/asrock/e350m1/mainboard.ramstage.o
src/mainboard/asrock/e350m1/mainboard.c: In function 'mainboard_enable':
src/mainboard/asrock/e350m1/mainboard.c:63:2: warning: implicit declaration of function 'pm_iowrite' [-Wimplicit-function-declaration]
[…]
This warning was introduced by moving the initialization of the
ASF registers using `pm_iowrite` to `mainboard.c` in
commit db6c5bfd8bdef4489e7fec533cb2ca8ae6c24cf3
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Thu Mar 21 22:21:28 2013 +0100
Asrock E350M1: Use SPD read code from F14 wrapper
Reviewed-on: http://review.coreboot.org/2875
and is fixed by including `southbridge/amd/cimx/cimx_util.h`
declaring `pm_iowrite`.
Note, that the other AMD SB800 based boards seem to use the
header file `southbridge/amd/sb800/sb800.h`, so no warning is shown
for those. But since the CIMx SB800 code is used, the routines
from the CIMx directory are more appropriate to declare these functions.
So delete the commented out include line for this header too.
Change-Id: I179aad5157c5a91294339a3e7b6c4c1715c6f099
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2957
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Auto-select marking the graphics memory as write-combining.
Change-Id: Icf61c5cbd129a97a106f0aaeca4e010d4799b4b8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2981
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Auto-select marking the graphics memory as write-combining.
Change-Id: I0b913f0b318bf57275643d3cfb5bc54ca8a005f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2982
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The pci device code was probing and loading the option rom before
it did the S3 resume check for VGA option roms. Instead move this
check before probing and loading so that we don't unnecessarily
do work.
Change-Id: If2e62d0c0e4b34b4f1bcd56ebcb9d3f54c6d0d24
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2979
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
It makes much more sense to use CONFIG_USE_OPTION_TABLE instead
of CONFIG_HAVE_CMOS_DEFAULT. As we want to read the used
debug_level from our CMOS. This change makes it possible to
change log_debug via nvramtool and make use of the new
value after a reboot/poweroff.
CONFIG_HAVE_CMOS_DEFAULT does have an other meaning
Change-Id: I438dd01a2b4171dba2b73f2001511c71f4317725
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
When calculating the offsets of the various binary blobs within the
coreboot.rom file, we noticed that using mawk as the awk tool instead
of using gawk led to build issues. This was finally traced to the
maximum value of the unsigned long variables within mawk - 0x7fff_ffff.
Because we were doing calculations on values up in the 0xffxxxxxx
range, these numbers would either be turned into floating point values
and printed using scientific notation, or truncated at 0x7fff_ffff.
To fix this, we print the values out as floating point, with no decimal
digits. This works in gawk, mawk, and original-awk and as the testing
below show, seems to be the best way to do this.
printf %u 0xFFFFFFFF | awk '{printf("%.0f %u %d", $1 , $1 , $1 )}'
mawk: 4294967295 2147483647 2147483647
original-awk: 4294967295 2147483648 4294967295
gawk: 4294967295 4294967295 4294967295
The issue of %d not matching gawk and original-awk has been reported
to ubuntu.
In the future, I'd recommend that whenever awk is used, a format is
specified. It doesn't seem that we can count on the representation
being the same between the different versions.
Change-Id: I7b6b821c8ab13ad11f72e674ac726a98e8678710
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2628
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reclaims space in ACPI NVS by removing unused fields and
adds new fields for SerialIO BARs which will be used to communicate
the allocated resources to ACPI.
Change-Id: I002bf396cf7b495bc5b7e54b741527e507aff716
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2969
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This enables the TPM device in ACPI tables so the OS is able
to probe for the TPM without needing it be force loaded.
Change-Id: I21e660ac1c12e3e1341cf266cf8f0bf03763df5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2968
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
`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>
|
|
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>
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
