| Age | Commit message (Collapse) | Author |
|---|
|
link(google chromebook pixel) is an intel machine.
Change-Id: I9d40f1e945021d8e190879477cd12be7d0262733
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3085
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This removes the wait_ms argument from the dp_controller_init(). The
only delay involved is a constant 60ms delay that happens if
everything else goes well. This delay is derived from the LCD spec
so there's no reason it should be baked into the controller code.
(This patch also has the side-effect of fixing a bug where we were
delaying on an undefined value for wait_ms).
Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
|
|
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5:
commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5
Author: Patrick Georgi <patrick.georgi@secunet.com>
Date: Tue Apr 9 15:41:23 2013 +0200
siemens/sitemp_g1p1: Make ACPI report the right mmconf region
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It sneaked in without it's dependencies and, therefore, broke the build for
all amdk8 targets. Paul Menzel already commented on the issue in [1]. It
also doesn't look like the dependencies would be pulled soon [2].
[1] http://review.coreboot.org/#/c/3047/
[2] http://review.coreboot.org/#/c/2662/
Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3063
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
1). Thatcher PCIE x8 slot is reverse order.
Although the PCIE slot is x16, it actually uses 8 lanes(15:8).
Because the PCIE slot is configured by PortList[0], fix this item can enable the slot.
A x1 PCIE network adapter works well in this slot.
2). Fix DdiList to detect DP monitor or HDMI monitor.
GPIO50 can be used to detect DP0/HDMI0 monitor.
If GPIO50 is 1, it is DP monitor. If GPIO50 is 0, it is HDMI monitor.
GPIO51 can be used to detect DP1/HDMI1 in the same way.
3). Disable unused PCIE port and clean up code in PlatformGnbPcie.c and devicetree.cb.
PCIE port 3 and 7 are not used in Thatcher.
Change-Id: I8524b6fc1b6cdc03ba92e7191186bfb0986767c8
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3011
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Split the Persimmon DSDT into common code areas.
For example, split the Southbridge specific code into
the Southbridge directory and CPU specific code into
the CPU directory. Also adding the superio.asl file
to the Persimmon DSDT tree. This file is empty for
the moment but will be necessary in the future. I have
also emptied the thermal.asl file in the mainboard
directory because it does not seem to perform as
intended (fan control does not change when it is
brought back into the code base) and it has been
inside a '#if 0' statement for a long time. Removing
it until it is decided that it is actually necessary.
This change was verified in three different ways:
1. Visual comparison of the compiled DSDT pulled from the
Persimmon after booting into Linux using the ACPI tools
acpidump, acpixtract, and iasl. The comparison was done
between the DSDT before and after doing the split work.
This test is somewhat difficult considering the expanse
of the changes. Blocks of code have been moved, and
others changed.
2. Linux logs were dumped before and after the DSDT split.
Logs dumped and compared include dmesg and lspci -tv.
Neither log changed significantly between the two compare
points.
3. The test suite FWTS was run on the Coreboot build both
before and after doing the DSDT split with the command
'sudo fwts -b -P -u'. The flag -b specifies all batch jobs,
-P specifies all power tests, and -u specifies utilities.
Interactive jobs were not run as most of them consist of
laptop checks. Again, there were no significant changes
between the two endpoints.
These tests lead me to believe that there was no change in
the functionality of the ACPI tables apart from what is
known and expected.
This patch is the first of a series of patches to split the DSDT.
The ASRock patch was merged before this one and breaks the ASROCK
E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/).
Please be aware of this dependency when pulling these patches.
Other patches that depend on this patch are
'AMD Fam14: Split out the AMD Fam14 DSDT'
(http://review.coreboot.org/#/c/3051/)
and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC'
(http://review.coreboot.org/#/c/3052/)
Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3048
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
We need these to be inputs so they can be read when populating the coreboot
tables. It seems like a good idea to do this early to ensure that the input
gate capacitance has had a chance to charge, and if we decide to use
actually use that information during the ROM stage to do earlier RW
firmware selection.
It is not guarded by a ChromeOS config variable because those lines are
always intended to be input GPIOs, regardless of whether we're running
ChromeOS or not.
Change-Id: Id76008931b5081253737c6676980a1bdb476ac09
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3067
Tested-by: build bot (Jenkins)
|
|
Change-Id: I34097f878291367b28962048190e11ccaacfc514
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3066
Tested-by: build bot (Jenkins)
|
|
This is the same split as was done on the Persimmon.
Change-Id: I25bd63f23417b7926232f07eaaa7917170af9d60
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/3050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
ACPI reported the entire space between top-of-memory and some
(relatively) arbitrary limit as useful for MMIO. Unfortunately
the HyperTransport configuration disagreed. Make them match up.
Other boards are not affected since they don't report any region
for that purpose at all (it seems).
Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add basic edp support to the ramstage. Not working.
Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
|
|
This is a simpler device tree that is also more correct,
and has graphics settings as well.
Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3053
Tested-by: build bot (Jenkins)
|
|
This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.
- i2c_read() and i2c_write() functions updated to take bus number
as an argument.
- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
i2c_write(). If a chip needs special handling we should take care
of it elsewhere, not in every low-level i2c driver.
- All the confusing bus config functions eliminated. No more
i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
is handled automatically when the caller does a transaction and
specifies the desired bus number.
- i2c_probe() eliminated. We're not a command-line utility.
- Let the compiler place static variables automatically. We don't need
any of this fancy manual data placement.
- Remove dead code while we're at it. This stuff was ported early on
and much of it was left commented out in case we needed it. Some
also includes nested macros which caused gcc to complain.
- Clean up #includes (no more common.h, woohoo!), replace debug() with
printk().
Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:
- We only need to expose i2c_read() and i2c_write() in our public API.
Everything else is board/chip-dependent and should remain hidden
away.
- i2c_read and i2c_write functions will take bus number as an arg
and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
error and end up cluttering the code since the user needs to save
the old bus number, set the new one, do the read/write, and restore
the old value (3 added steps to do a simple transaction).
- Stop setting default values for board-specific things like SPD
and RTC bus numbers (as if we always have an SPD or RTC on I2C).
- Death to all the trivial inline wrappers. And in case there was any
doubt, we really don't care about the MPC8xx. Though if we did then
we would not pollute the public API with its idiosyncrasies.
Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Originally developed by LiPPERT and after the acquisition marketed as
'LiPPERT by ADLINK', the plan is now to streamline both boards into the
ADLINK naming scheme. But AFAIK a few have already been sold and as of
this writing the website still advertises the old names. And in any case
the veteran LX products will continue to be sold by ADLINK under their
original names.
So create CONFIG_VENDOR_ADLINK, currently only telling users to look under
LiPPERT (however any future boards will be added here).
Further add an explanation to CONFIG_VENDOR_LIPPERT, and in the Mainboard
model selection show both names.
Change-Id: Iaafa88533ef4cce33243293c3d55754e7e93d003
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3046
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This moves highly board-specific code out from the Exynos5250
power_init() into Snow's romstage.c. There's no reason the CPU-
specific code should care about which PMIC we are using and
which bus it is on.
Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This was a first pass at display port support, we have
realized that it was ultimately a bad path. The display
hardware is intimately tied into a specific cpu and
mainboard combination, and the code has to be elsewhere.
The devicetree formatting is ugly, but it matters not:
it's changing soon.
Change-Id: Iddce54f9e7219a7569315565fac65afbbe0edd29
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3029
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
`broadcom_init()`"
Commit 5d741567 added a prototype to broadcom.c to fix a warning. This part
is fine.
It also changed mainboard.c to #include broadcom.c. But broadcom.c is
already in Makefile.inc, now building will fail because the linker gets
broadcom_init() twice.
Undo the change to mainboard.c but keep the change to broadcom.c.
Change-Id: Ieccc098f477ffacccf4174056998034a220a9744
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/3012
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
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)
|
|
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)
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
Convert the existing haswell code to support reloctable ramstage
to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as
this option is a hard requirement for relocatable ramstage.
Aside from converting a few new API calls, a cbmem_top()
implementation is added which is defined to be at the begining of the
TSEG region. Also, use the dynamic cbmem library for allocating a
stack in ram for romstage after CAR is torn down.
Utilizing dynamic cbmem does mean that the cmem field in the gnvs
chromeos acpi table is now 0. Also, the memconsole driver in the kernel
won't be able to find the memconsole because the cbmem structure
changed.
Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Force link speed on these platforms to 3 Gbps to defeat buggy SATA
drives.
Change-Id: Ia38a7c486fb1f4469cd67ca5244bbf61f877d556
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2823
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This makes use of the new functions from pmutil.c that take
care of the differences between -H and -LP chipsets.
It also adds support for the LynxPoint-LP GPE0 register block
and the SMI/SCI routing differences.
The FADT is updated to report the new 256 byte GPE0 block on
wtm2/wtm2 boards which is too big for the 64bit X_GPE0 address
block so that part is zeroed to prevent IASL and the kernel
from complaining about a mismatch.
This was tested on WTM2. Unfortunately I am still unable to get an
SCI delivered from the EC but I suspect that is due to a magic
command needed to put the EC in ACPI mode. Instead I verified that
all of the power management and GPIO registers were set to expected
values.
I also tested transitions into S3 and S5 from both the kernel and
by pressing the power button at the developer mode screen and they
all function as expected.
Change-Id: Ice9e798ea5144db228349ce90540745c0780b20a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2816
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Changes:
- Get rid of the h8scm mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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: I575221039ad65a59ae0f93397ef1038b669e81c7
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Changes:
- Get rid of the dinar mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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.
- select_socket() and restore_socket() were created from code that
was removed from AmdMemoryReadSPD() in dimmSpd.c. The functionality
is specific to the dinar mainboard configuration and was therefore
split from the generic read SPD functionality.
Change-Id: I1e4b9a20dc497c15dbde6d89865bd5ee7501cdc0
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2830
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Changes:
- Get rid of the s8226 mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I1eaf64986ef4fa3f89aed2b69d3f9c8c913f726f
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2827
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Changes:
- Get rid of the h8qgi mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2777/
AMD Fam15: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
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.
- select_socket() and restore_socket() started by duplicating
sp5100_set_gpio() and sp5100_restore_gpio(), which were in
dimmSpd.c. In addition to renaming the functions to more
specifically state their purpose, some cleanup and magic number
reduction was done.
Change-Id: I346ebd8399d4ba3e280576e667fdc62fa75a63b8
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This code is taken from an EDID reader written at Red Hat.
The key function is
int decode_edid(unsigned char *edid, int size, struct edid *out)
Which takes a pointer to an EDID blob, and a size, and decodes it into
a machine-independent format in out, which may be used for driving
chipsets. The EDID blob might come for IO, or a compiled-in EDID
BLOB, or CBFS.
Also included are the changes needed to use the EDID code on Link.
Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This is a new state machine. It is more programmatic, in the
case of auxio, and has much more symbolic naming, and very few
"magic" numbers, except in the case of undocumented settings.
As before, the 'pre-computed' IO ops are encoded in the iodefs
table. A function, run, is passed and index into the table and
runs the ops.
A new operator, I, has been added. When the I operator is hit,
run() returns the index of the next operator in the table.
The i915lightup function runs the table. All the AUX channel ops
have been removed from the table, however, and are now called as
functions, using the previously committed auxio function.
The iodefs table has been grouped into blocks of ops, which end in
an I operator. As the lightup function progresses through startup,
and the run() returns, the lightup function performs aux channel
operations.
This code is symbolic enough, I hope, that it will make haswell
graphics bringup simpler.
i915io.c, and the core of the code in i915lightup.c, were
programatically generated, starting with IO logs from the DRM
startup code in the kernel. It is possible to apply the tools that
do this generation to newer IO logs from the kernel.
Change-Id: I8a8e121dc0d9674f0c6a866343b28e179a1e3d8a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add a new operator, P, for the state machine, meaning
implement a palette fill.
Implement a function (palette) that fills the palette when the
P operator is hit.
This replaces 256 lines in the state machine table with 1.
Change-Id: I67d9219fe7de0ecf1fb9faf92130c00c9f5f8e88
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/2835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For full integration of FUI into coreboot, we need aux channel
communcations. The intel_dp.c is a file taken from Linux and is
used for aux channel comms. This file has been cut down to work
with coreboot. For now it is associated with the link mainboard
until we get a better handle on how this all fits together. This
code is almost certainly usable on other platforms in the long term.
But one step at a time.
Change-Id: I7be4c56e0a7903f3901ac86e12b28f3bdc0f7947
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/2834
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This adds a new API for cache maintenance operations. The idea is
to be more explicit about operations that are going on so it's easier
to manage branch predictor, cache, and TLB cleans and invalidations.
Also, this adds some operations that were missing but required early
on, such as branch predictor invalidation. Instruction and sync
barriers were wrong earlier as well since the imported API assumed
we compield with -march=armv5 (which we don't) and was missing
wrappers for the native ARMv7 ISB/DSB/DMB instructions.
For now, this is a start and it gives us something we can easily use
in libpayload for doing things like cleaning and invalidating dcache
when doing DMA transfers.
TODO:
- Set cache policy explicitly before re-enabling. Right now it's left
at default.
- Finish deprecating old cache maintenance API.
- We do an extra icache/dcache flush when going from bootblock to
romstage.
Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This fixes a trivial error with the recovery mode GPIO index.
Change-Id: I7290c1e23cdddaf91c9021d4e4252c0c772b6eab
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2825
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
A fix to eliminate warnings when building romstage files with ChromeOS
compilers
Change-Id: Ia5d7bbdde3aa3439fd493f5795f2cc2bf4c4c187
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2781
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Having this header file in the mainboard directory breaks
the dinar build on cygwin because the header file in the
dinar mainboard is used instead of the correct header file
src/vendorcode/amd/cimx/sb700/OEM.h. The build probably works
fine on Linux systems because, due to case-sensitivity, Oem.h
will not match the #include "OEM.h" statement in
src/southbridge/amd/cimx/sb700/Platform.h.
The Oem.h file in the dinar mainboard is not used by any other
source files, and the defines in the dinar mainboard are duplicated
by defines in the correct OEM.h file. Therefore, the file can be
safely removed.
Change-Id: I81b97eca8116d63644d335edc3bb51f90c7094d9
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2776
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
This commit pulls in all the common logic for romstage into
the Haswell cpu directory. The bits specific to the mainboard
still reside under their respective directories. The calling
sequence bounces from the cpu directory to mainboard then back
to the cpu directory. The reasoning is that Haswell systems use
cache-as-ram for backing memory in romstage. The stack is used to
allocate structures. However, now changes can be made to the
romstage for Haswell and apply to all boards.
Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2754
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It was found that the Haswell reference code was smashing through the
stack into the reference code's heap implementation. The reason for this
is because our current CAR allocation is too small. Moreover there are
quite a few things to coordinate between 2 code bases to get correct.
This commit separates the CAR into 2 parts:
1. MRC CAR usage.
2. Coreboot CAR usage.
Pointers from one region can be passed between the 2 modules, but one
should not be able to affect the others as checking has been put into
place in both modules.
The CAR size has effectively been doubled from 0x20000 (128 KiB) to
0x40000 (256KiB). Not all of that increase was needed, but enforcing
a power of 2 size only utilizes 1 MTRR.
Old CAR layout with a single contiguous stack with the region starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| MRC global variables |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+
| ROM stage stack |
| |
| |
+---------------------------------------+
| MRC Heap 30000 bytes |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
There was some hard coded offsets in the reference code wrapper to start
the heap past the console buffer. Even with this commit the console
can smash into the following region depending on what size
CONFIG_CONSOLE_CAR_BUFFER_SIZE is.
As noted above This change splits the CAR region into 2 parts starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+
| MRC Region |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| ROM stage stack |
| |
| |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE,
which represents the expected stack usage for the romstage. A marker
is checked at the base of the stack to determine if either the stack
was smashed or the console encroached on the stack.
Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2752
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is causing a hang in depthcharge. For now just disable
this port.
Change-Id: I87a6db2d8361588e82eee640c74cea690115bed5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2764
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Rather than have to repeat this bit in every mainboard.
Also, remove the reset of the RTC power status from here.
We had done this in TOT for current platforms but did not
carry it back to emeraldlake2 where this branched from.
If we clear the status here then we don't get an event
logged later which can be important for the devices that
do not have a CMOS battery.
Change-Id: Ia7131e9d9e7cf86228a285df652a96bcabf05260
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2683
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We're happy to announce coreboot support for the "Stout"
Chromebook, a.k.a Lenovo X131e Chromebook.
Change-Id: I9b995f8d0dd48e41c788b7c3d35b4fac5840e425
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2636
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is mostly a copy of Whitetip Mountain 1 with specific GPIO
map for this Customer Reference Board (CRB).
This mainboard currently has basic funcionality and is able to
boot a Linux Kernel but many of the new Haswell ULT specific
devices are not yet enabled.
Change-Id: I999452d86f00a2c245fa39b1b76080f6a3b1e352
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2725
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.
The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.
Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.
Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Lots of things are still placeholder and need work.
Due to the useful GPIOs being run to either the EC or the SIO1007
I have hard coded developer mode on and recovery mode off.
Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'
By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`. PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge. However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.
This is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/
Change-Id: I5184df8deb7b5d2e15404d689c16c00493eb01aa
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2736
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
This is the same chagne as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/
Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
This is the same change as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/
Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
This is the same change as made to Persimmon in
Change-ID If8d86f:
http://review.coreboot.org/#/c/2726/
Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'
By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`. PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge. However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.
This is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/
Change-Id: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2737
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/
Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/
Change-Id: I2701d915338294bdade2ad334b22a51db980892e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
This is the same change made to Persimmon with Change-ID
I149428:
http://review.coreboot.org/#/c/2684/
Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Adding the 'WordBusNumber' macro to the PCI0
CRES ResourceTemplate in the Persimmon DSDT.
This sets up the bus number for the PCI0 device
and the secondary bus number in the CRS method.
This change came in response to a 'dmesg' error
which states:
'[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS'
By adding the 'WordBusNumber' macro, ACPI can set
up a valid range for the PCIe downstream busses,
thereby relieving the Linux kernel from "guessing"
the valid range based off _BBN or assuming [0-0xFF].
The Linux kernel code that checks this bus range is
in `drivers/acpi/pci_root.c`. PCI busses can have
up to 256 secondary busses connected to them via
a PCI-PCI bridge. However, these busses do not
have to be sequentially numbered, so leaving out a
section of the range (eg. allowing [0-0x7F]) will
unnecessarily restrict the downstream busses.
This is the same change as made to Persimmon with
change-id I44f22:
http://review.coreboot.org/#/c/2592/
Change-Id: I9017a7619b3b17e0e95ad0fe46d0652499289b00
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
I am removing the _INI method from the AZHD device because
it does not seem to do anything and causes errors in the
FWTS[1] (Firmware Test Suite) test 'method'. The INI
method performs device specific initialization and is
run when OSPM loads a description table. It must only
access OperationRegions that have been indicated as
available by the _REG (Region) method. We do not have a
_REG method and during my testing, I added a REG method
but it did not seem to make a difference in the PCI
register space. The bit fields defined as NSDI (Disable
No Snoop), NSDO (Disable No Snoop Override), and NSEN
(Enable No Snoop Request) do not ever get written from
their default values. And writing to these bit fields
does not seem to be necessary because I did not notice
any change in audio functionality.
In an effort to clean up as many FWTS errors as possible,
I propose removing this method altogether. I have seen no
change in operation (audio works with and without this
method) and there does not seem to be any change in lspci
or dmesg.
FWTS information can be found here:
[1]: https://wiki.ubuntu.com/Kernel/Reference/fwts
Change-Id: If8d86f959822d528c44ab011a851659d486289b5
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The _OSC method is used to tell the OS what capabilities
it can take control over from the firmware. This method
is described in chapter 6.2.9 of the ACPI spec v3.0.
The method takes 4 inputs (UUID, Rev ID, Input Count,
and Capabilities Buffer) and returns a Capabilites
Buffer the same size as the input Buffer. This Buffer
is generally 3 Dwords long consisting of an Errors
Dword, a Supported Capabilities Dword, and a Control
Dword. The OS will request control of certain
capabilities and the firmware must grant or deny control
of those features. We do not want to have control over
anything so let the OS control as much as it can.
The _OSC method is required for PCIe devices and dmesg
checks for its existence and issues an error if it is
not found.
Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It's no longer required.
Change-Id: I621226a3bdfba9bc8edfd6e511a5337ae603ae19
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2723
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
The current code is attempting to convert from an invalid
starting temperature. Since we aren't sure where the temperature
will come from yet just return a static value.
This stops the kernel from going to S5 on boot because it
thinks the temperature is too high.
Change-Id: I433fa407e545458344af5842b353df5bc71bfdad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2679
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This option is not required for haswell. Enabling the option doesn't
do anything aside from complicate mtrr calculation. Therefore, remove
it.
Change-Id: I897523ff7d3606eb89961674c2eb3d384e584857
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2678
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This commit adds support for the deveveloper, recovery,
and write protect querying. It just uses jumpers on the
Basking Ridge board.
Noted ability to togggle jumpers results in toggling the
respective modes.
Change-Id: Iac189a1fa0245654591e2e9075380db422a329a0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2676
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
While looking at the Basking Ridge schematic I noticed some changes
and wanted to make sure they were reflected in the GPIO map.
Change-Id: I686653c164314ae9f68c42331d2f950751411d4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2675
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The baskingridge has a non-zero alt_gp_smi_en value in the
devicetree.cb file. It has just to be determined which GPI
pins should trigger an SMI on basking ridge. Without this change
the board would hang during boot (presumably through a SMI flood).
No more hangs once the value is zero.
Change-Id: I9704071bb7966bd3d0bbbc4aafede3f42d829b17
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2673
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The Grays Reef CRB is deprecated by order of Intel. Basking Ridge
is the new hotness. Therefore, rename graysreef to basking ridge.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I203497e165d8efc99d3438c4c548140a6e9cc649
Reviewed-on: http://review.coreboot.org/2672
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Some of the Lynx Point ids were off. Correct those and make
the pei data BAR fields consistent with the others.
Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2622
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The CS5536 companion device has three different power domains.
* working domain
* standby domain
* RTC domain
When the system is "off" only the standby domain is powered.
MFGPT[7:6] are member of the standby power domain.
MFGPT7 is used to control the backlight of the device and so the
timer gets used and configured during system boot. If the system
does a reboot the timer stays configured and the Linux driver
can not use it:
"ot200-backlight: ot200-backlight.0: MFGPT 7 not availale"
The cs5535-mfgpt has a function to hard-reset all MFGPTs but the
system hangs after the first access to a MFGPT register - cause
unknown.
/*
* This is a sledgehammer that resets all MFGPT timers. This is required by
* some broken BIOSes which leave the system in an unstable state
* (TinyBIOS 0.98, for example; fixed in 0.99). It's uncertain as to
* whether or not this secret MSR can be used to release individual timers.
* Jordan tells me that he and Mitch once played w/ it, but it's unclear
* what the results of that were (and they experienced some instability).
*/
static void reset_all_timers(void)
{
uint32_t val, dummy;
/* The following undocumented bit resets the MFGPT timers */
val = 0xFF; dummy = 0;
wrmsr(MSR_MFGPT_SETUP, val, dummy);
}
After playing around with this undocumented MSR it looks like I only
need to set bit 7 to free the MFGPT7.
BTW, all MFGPT[0:5] will be reset during pll_reset().
Change-Id: I54a8d479ce495b0fc2f54db766a8d793bbb5d704
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2527
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Even though this is under the graysreef board it really
applies to the Basking Ridge board. A subsequent patch will
rename graysreef to baskingridge.
The GPIO pins were updated to reflect the Basking Ridge schematics
as well as the DIMM spd addresses and USB over current pins.
Change-Id: Ice4e05f5203de3024cd463dfccf0bcfec1e247c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2632
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a FIXME about checking a MCHBAR register that isn't setup yet.
Also, remove revision updating because I can't find anything in the
docs that suggest this is required for haswell.
Change-Id: Ia8a6e08f82e18789e31c6c2ec2c1d63740c18dc4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2631
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The intel-framework code has an updated pei_data structure.
Use the new structure and revision. Also, remove the scrambler
seed saving in CMOS since that appears to be handled in the saved
data from the reference code.
Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2630
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Grays Reef is one of Intel's CRBs for the Haswell processor. The
platform is named Shark Bay.
GPIOs were the main focus so IRQ routing and ACPI still needs to be
further looked at.
Change-Id: Ie94b7af66f772714992a92612c76ca93b9b27088
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2621
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change the OSC method to actually grant control of
PCIe capabilities to the OS instead of granting no
control. I believe the logic was backwards in the
original commit. Bits should be set when granting
control and cleared when not granting control. By
setting the return value to 0x00, we effectively
tell the OS that it cannot control any PCIe
capability. See section 6.2.9 of the ACPI spec
version 3.0 for more information.
This edit is a duplication of the OSC method that
is in the src/southbridge/intel/bd82x6x/pch.asl
file.
Change-Id: Id2462ab12203afceb9033f24d06b4dfbf2236d2e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2714
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This enables branch prediction. We can probably find a better place
to do this, but for now we'll do it in snow's romstage main().
Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2701
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Since commit »Drop redundant CHIP_NAME in mainboard.c« (a93c3fe7) [1]
`CHIP_NAME` is unneeded for mainboards as the name is composed
automatically in `src/devices/root_device.c` from the strings in
Kconfig.
Unfortunately the ports for Google Butterfly, Link and Parrot as
as well as IEI PM-LX2-800-R10 introduced CHIP_NAME again. So drop
it again too.
[1] http://review.coreboot.org/1635
Change-Id: Ice7577a2a5c6070e196f2647c440b7a8e140e27e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2708
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Call the power_init() function. We appear to have forgotten about it
when deprecating lowlevel_init_subsystems(), but it didn't seem to
cause problems until we got to doing more interesting stuff recently.
There are some clean-ups to do from the original code, such as not
attempting to configure I2C from PMIC code, which we'll get around
to in follow-up patches.
(Credit to Gabe for spotting this)
Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2699
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
