Add SOUTHBRIDGE_INTEL_COMMON_RESET for all Intel platforms that used to
perform a "system reset" in their hard_reset() implementation. Replace
all duplicate CF9 reset implementations for these platforms.
Change-Id: I8e359b0c4d5a1060edd0940d24c2f78dfed8a590
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This code is not used at all any longer. Remove it.
BUG=b:69614064
Change-Id: I362280f876a335c0cc1c5691b86f5b27e3b5e2c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Baytrail SoC has a bug where in some cases the DisplayPort can hang
leading to a non-working display (it just stays black). To avoid this
hang, a patch was introduced in 02/2016
(1c3b1112fa - fsp_baytrail: Fix a possible hanging DisplayPort)
but per default not switched on so that each
mainboard can decide if it wants to use this patch or not.
Recently a new case of this bug was reported by Benoit Sansoni
(benoit.sansoni@kontron.com) and he requested to enable this fix per
default as it costs him a lot of time to find the cause and even the
already available fix in coreboot. To avoid this effort for someone
else in the future we can enable this fix per default as no negative
side effects are known and it is now tested at Siemens and at
Kontron on different mainboards with success.
As the goal is to enable this code permanently the config switch is not
longer needed and is removed.
Change-Id: I15bd682218d0dc887945cc91ee3e5488945a6355
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/18109
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
To include gfx.c in ramstage, there is a Kconfig option
(FSP_BAYTRAIL_GFX_INIT) which can be activated on demand.
Unfortunately, the "$"-character is missing so that this switch is
never active.
Change-Id: I0c3c562b3caca53ac6510c2c5dc30e7f606f5ad0
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/14532
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change fixes LPSS ACPI mode. Previously, enabling ACPI mode would
result in unusable devices, as the resources were set to 0 and the devices
were disabled.
lpss.c was copied from intel/baytrail with a few minor adjustment for the
different config structure.
ACPI mode requires setting PcdLpssSioEnablePciMode==LPSS_PCI_MODE_DISABLE
and applying the patch that disables clearing gnvs.
https://review.coreboot.org/#/c/14040/
This doesn't handle the case where the FSP has PcdLpssSioEnablePciMode
set to disable and the devicetree set to default.
Change-Id: I12fffea3820ed948defe7a4f11af6b6363402560
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14042
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This change properly assigns resources to the LPE (Low Power Engine for
Audio) and enables ACPI mode.
lpe.c was copied from intel/baytrail with a few minor adjustment for the
different config structure.
ACPI mode requires setting LpeAcpiModeEnable=LPE_ACPI_MODE_ENABLED and
applying the patch that disables clearing gnvs.
https://review.coreboot.org/#/c/14040/
Change-Id: I3fff9aa158bde88e571082642d4f985a5ae1976e
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/14041
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On some devices it can happen that DisplayPort TX lanes
do not work properly if the power gate setup is omitted.
If that happens, DisplayPort training will fail and therefore
DisplayPort channel will not work. Both ports are affected.
It seems that not every CPU shows this effect
and those that are affected tend to fail more often in a cold
environment.
With this fix a board that originally shows this failure
was running for over 1000 power cycles without issues.
Change-Id: Ia266674490a1bee63a85b38d1dc949dcdf683cbc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13743
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is to match the layout of the non-fsp baytrail to make comparisons
easier and possibly remove duplicate files.
Change-Id: I9a94842d724ab3826de711d398227e7bdc1045ff
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/12686
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The microcode for Bay Trail that's in the blobs repo is for the
M and D chip variants only. The fsp_baytrail directory is for
Bay Trail I chip variants, and will not boot if the M/D microcode
is used. The microcode for the I variant is supplied as part
of the Bay Trail FSP package.
Change-Id: I5493deb1626dc3cf037053e13e092f5a1143a13a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Load microcode to APs when performing baytrail_init_cpus. The updated
fsp1_0 driver calls TempRamInit API with a dummy microcode, so FSP
will not handle the microcode load.
Change-Id: I7b7c0f43da0d149048ae5a8fd547828f42de04fd
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/12095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using a copiler to compile something that's already a binary is pretty
stupid. Now that Stefan converted most microcode in blobs to a plain
binary, use the binary version.
Change-Id: Iecf1f0cdf7bbeb7a61f46a0cd984ba341af787ce
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11607
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of selecting the Kconfig option and adding the subdir
entry within each chipset auto include the common/firmware
directory as it's guarded by HAVE_INTEL_FIRMWARE.
BUG=chrome-os-partner:43462
BRANCH=None
TEST=Built glados.
Change-Id: I166db67c41b16c4d9f0116abce00940514539fa5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11734
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Add the common/firmware subdir to the baytrail & fsp_baytrail
makefiles and remove the code it replaces.
- Update baytrail & fsp_baytrail Kconfigs to use the common code.
- Update the IFD Kconfig help and prompts for the TXE vs ME.
- Whittle away at the CBFS_SIZE defaults. All the fsp_baytrail
platforms have their own defaults.
Change-Id: I96a9d4acd6578225698dba28d132d203b8fb71a0
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10647
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
This change switches all SOC vendors and southbridges
to be autoincluded by Makefile.inc, rather than having to be
mentioned explicitly in soc/Makefile.inc or in
soc/<vendor>/Makefile.inc.
This means, vendor and SOC directories are now "drop
in", e.g. be placed in the coreboot directory hierarchy
without having to modify any higher level coreboot files.
The long term plan is to enable out of tree components to be
built with a given coreboot version (given that the API did not
change).
Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9799
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a driver wich can handle the internal I2C controllers
of Baytrail SoC. This driver is not suitable for the
SMBus controller.
Change-Id: I841c3991a2fb0f8b92b8e59ec02d62f5866f5bdf
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/8401
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The name was always obscure and confusing. Instead define cbmem_top()
directly in the chipset code for x86 like on ARMs.
TODO: Check TSEG alignment, it used for MTRR programming.
Change-Id: Ibbe5f05ab9c7d87d09caa673766cd17d192cd045
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7888
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
- Build gpio.c into romstage
- Add functions to translate the GPIO # to a pad #, then return the
value read from the GPIO.
- Add functions to configure the GPIO - Function, Pull up/down, pull
strength, Input/Output, and Output level.
Change-Id: Ic37dfc9a74a598023bdf797d31087428adec176a
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7796
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@gmx.net>
While similar to the Bay Trail-M/D code based on the MRC, there are
many differences as well:
- Obviously, uses the FSP instead of the MRC binaries.
- FSP does additional hardware setup, so coreboot doesn't need to.
- Different microcode & microcode loading method
- Uses the cache_as_ram.inc from the FSP Driver
- Various other changes in support of the FSP
Additional changes that don't have to to with the FSP vs MRC:
- Updated IRQ Routing
- Different FADT implementation.
This was validated with FSP:
BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd
SHA256: d29eefbb33454bd5314bfaa38fb055d592a757de7b348ed7096cd8c2d65908a5
MD5: 9360cd915f0d3e4116bbc782233d7b91
Change-Id: Iadadf8cd6cf444ba840e0f76d3aed7825cd7aee4
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5791
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
