The first dword in FirmwareTN has been changed from 0xa0009 to 0xa000e.
The FirmwareTNHeader is not called by any one in latest PI. It seems to
be useless for now.
Change-Id: Ic7a20e0bcca8de0b56c7bc5d01e0ce86347bde21
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/7844
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
This allows the chromeos header and functions to be included
without needing to guard with #if CONFIG_CHROMEOS.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Original-Change-Id: I523813dc9521d533242ae2d2bc822eb8b0ffa5e2
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196265
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit b78ccada9a01f54a60993dfc2c618201d31df9ad)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ic2f7127966da716e114336c30829a6403d82e180
Reviewed-on: http://review.coreboot.org/7843
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Set VB_INIT_FLAG_SW_WP_ENABLED according to the status returned by an
optional platform / mainboard function vboot_get_sw_write_protect().
BUG=chrome-os-partner:26777
TEST=Manual on Rambi with all patches in sequence:
`crossystem sw_wpsw_boot` prints 0
`flashrom --wp-enable` and reboot
`crossystem sw_wpsw_boot` prints 1
BRANCH=Rambi
Original-Change-Id: Ifb852d75cc106d10120cfee0a396b0662282051a
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190096
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c4668fc8a9ab31d9cf876b3d9ad3405756d4d683)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Idace325439958f6b490d2e6705d55e95305c4b2a
Reviewed-on: http://review.coreboot.org/7750
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
As is the case in commit:
3312ed7 amd/agesa/f1?/Lib/amdlib.c: Integer overflow in loop construct
The semantics of this loop relies on an integer overflow in Index >=0
that implies a return value of (UINT8)-1 which around wraps to 0xFF, or
VOLT_UNSUPPORTED.
Also fix an infinite loop.
Change-Id: Iced3eff3ae7b8935db3bdd6147372cf3b540883c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7676
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
If EFS is enabled and vboot didn't tell us it's going to use the display, we
can skip initializing it and save some boot time.
BUG=chrome-os-partner:27094
TEST=Built and booted on nyan without EFS in recovery mode and normal mode.
Built and booted on nyan with EFS in recovery mode and normal mode. Verified
that in normal mode with EFS the display initialization was skipped and boot
time was essentially the same as when display initialization was simply
commented out.
BRANCH=None
Original-Change-Id: I1e2842b57a38061f40514407c8fab1e38b75be80
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/192544
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a672d18c3570e6991a1c1c0089697112a4cd71d0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I95e8bd7a447876174305f755cc632365ed6f5a30
Reviewed-on: http://review.coreboot.org/7734
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove '__attribute__((optimize("Os")))' as it is unlikely to be
necessary as it is not used in other families that have the same
code and only hides deeper issues.
Change-Id: Ica890812ebc2fb659b9c3e46b40cf3f6534b3cf2
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/7689
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Clang complains:
"implicit truncation from 'int' to bitfield changes value from -1 to 15"
-1 is define in 'c11std 6.3.1.3p2' as:
[Signed and unsigned integers] Otherwise, if the new type is unsigned,
the value is converted by repeatedly adding or subtracting one
more than the maximum value that can be represented in the new type
until the value is in the range of the new type.60)
FOOTNOTE.60 The rules describe arithmetic on the mathem...
This is "0xFF" on Mullins and "0xF" in this case. Clang seems to
complain about this two's complement in a bitfield as being truncated.
As the bitfield is 4 bits wide, (a maximum of 15 decimal), we set the
field as '0x0F'. Ideally this field /should/ be set to 'UINT8_MAX' however
we still have silly truncation warnings.
Change-Id: Ib7476d453ffd932bb911e638117cf9f56f71f269
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7719
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Depending on the platform the underlying regions vboot requires
may not be accessible through a memory-mapped interface. Allow
for non-memory-mapped regions by providing a region request
abstraction. There is then only a few touch points in the code to
provide compile-time decision making no how to obtain a region.
For the vblocks a temporary area is allocated from cbmem. They
are then read from the SPI into the temporarily buffer.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted a rambi with vboot verification.
Original-Change-Id: I828a7c36387a8eb573c5a0dd020fe9abad03d902
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190924
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit aee0280bbfe110eae88aa297b433c1038c6fe8a3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia020d1eebad753da950342656cd11b84e9a85376
Reviewed-on: http://review.coreboot.org/7709
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Following the same reasoning as commit
ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
Change-Id: I8fbb318daacf64a14a71022705eb040a01c34fa8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7699
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Following the same reasoning as commit
ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
Change-Id: I7798b689db3e582649eb4af4ccd1877bb1d49063
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7698
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Topology Extensions Support (bit 54 of 0xC0011005) applies to
PACKAGE_TYPE_FS1r2 also. Rids us of:
"Re-enabling disabled Topology Extensions Support"
showing up in dmesg.
Change-Id: Id123fa9632936c150cf1aebc4d34b404a4398ead
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7671
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
The contents of these files were guarded by a check for the _MSC_VER
macro, which we don't use.
Change-Id: Ic595c8e6284c54e1449cf21e0cebee8c9ce7c682
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7670
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Missing IOMMU support is missing from the libagesa Makefile, it also
lacks a header with type-signature and a few bad typecast issues.
Change-Id: I7f2ad2104de9baaa66dbb6ffeb0f2b4d35fa5c16
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Co-Author: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/7642
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Right now, coreboot code using AGESA headers can only build if all the
AGESA path are given to the compiler via the "-I" option. This is sub-
optimal, as it requires us to have every AGESA source directory
specified as a compiler include path. This pollutes our global include
paths.
We restrict the compiler include paths to only allow "AGESA_ROOT/" and
"AGESA_ROOT/Include". We then modify the AGESA headers to specify
non-local include files relative to "AGESA_ROOT/Include".
We use the convention that includes relative to the directory of the
header are included as "path/to/header.h", while includes relative to
AGESA_ROOT are included as <path/to/header.h>.
This change allows building coreboot code based on AGESA with the
limited subset of include paths, but does not allow AGESA itself to
build with this restricted subset.
Change-Id: I31102273c8caa8d6b1d80774bfd35711825bec03
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5424
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
TL;DR ASCII art that sucks, remove it.
Change-Id: I424736b040fe019bba6155de76903225a266760d
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7641
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We don't actually use nor support these as our implementation
makes use of gcccar.inc. They maybe useful as a reference for
history so lets keep them in version history.
Change-Id: I388251dead449dde14283e57db39c37982d947b2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7596
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
No need to mark Makefiles, C files or devicetrees
executable.
Change-Id: Ide3a0efc5b14f2cbd7e2a65c541b52491575bb78
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7618
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Minor change in Kconfig to remove "/" defined in
FSP_VENDORCODE_HEADER_PATH and update the path in Makefile.inc.
Change-Id: Ic19ab9560aabe307d45b560f167874383cc920aa
Signed-off-by: Fei Wang <wangfei.jimei@gmail.com>
Signed-off-by: FEI WANG <wangfei.jimei@gmail.com>
Reviewed-on: http://review.coreboot.org/5894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
For the moment we make use of Trinity f15tn AGESA for Richland
f15rl support until we have properly worked out the discrepancies.
Adds RL-A1 Richland stepping cpuid to F15TnLogicalIdTables lookup.
We later wish to merge f15tn and f15rl support into the AGESA in
any case.
Change-Id: Ia9070d4e392ce7eb912771d1c7b3ef1440f8e8a8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7559
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Baytrail Gold3 FSP adds a couple of parameters in UPD_DATA_REGION
making platform more configurable via devicetree.cb
Update the UPD_DATA_REGION structure and pass settings to FSP
Add Baytrail Gold2 and earlier FSP backward compatible, as Gold3
FSP changes UPD_DATA_REGION struct
Change-Id: Ia2d2d0595328ac771762a84da40697a3b7e900c6
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/7334
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
To backport features introduced with recent Chromebooks and/or Intel
boards in general, heavy work on the AMD AGESA platform infrastructure
is required. With the AGESA PI available in binary form only, community
members have little means to verify, debug and develop for the said
platforms.
Thus it makes sense to fork the existing agesawrapper interfaces, to give
AMD PI platforms a clean and independent sandbox. New directory layout
reflects the separation already taken place under 3rdparty/ and vendorcode/.
Change-Id: Ia730f0e45e7c1bdfc0c91e95eb6729a77773e2b9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7388
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
To backport features introduced with recent Chromebooks and/or Intel
boards in general, heavy work on the AMD AGESA platform infrastructure
is required. With the AGESA PI available in binary form only, community
members have little means to verify, debug and develop for the said
platforms.
Thus it makes sense to fork the existing agesawrapper interfaces, to give
AMD PI platforms a clean and independent sandbox. New directory layout
reflects the separation already taken place under 3rdparty/ and vendorcode/.
Change-Id: Ib60861266f8a70666617dde811663f2d5891a9e0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7149
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reduce inconsequential differences between fam15 and
fam15tn to better prepare for possible merger.
Change-Id: I016aa1a4cc45553d51190988d48c8a54cfd85f5a
Signed-off-by: Sara Lelliott <sara@jupitercrash.org>
Reviewed-on: http://review.coreboot.org/7503
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Sync up these 'Porting.h' headers to include fixes from each
family on botched-up typedef's for primitive data types.
Fix corresponding breakage introduced by typecasts in
mainboards.
Change-Id: I003b155cc6c860f6b0cd75667083634a04814473
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7512
Tested-by: build bot (Jenkins)
Found an extra bracket that appears it should not be there.
Change-Id: I66b7967833afd25f12bd4eaaf6419a6ed3ad544b
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/7515
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The vboot implementation previously assumed that ramstage would
be a relocatable module. Allow for ramstage not being a relocatable
module.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built nyan with vboot.
Original-Change-Id: Id3544533740d77e2db6be3960bef0c129173bacc
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190923
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 756ee3a6987097c65588c8784ee9653fd6e735e4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I813b07e1bec75640ad4066aca749ba8dccec31d4
Reviewed-on: http://review.coreboot.org/7220
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being
selected allow for calling vboot_verify_firmware()
with an empty implementation. This allows for one not to
clutter the source with ifdefs.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded
call to vboot_verify_firmware().
Original-Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/172711
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit c1e0e5c7b39c947b2a0c237b4678944ab86dd780)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Conflicts:
src/vendorcode/google/chromeos/chromeos.h
Change-Id: Iaaa3bedbe8de701726c28412e7eb75de0c58c9c9
Reviewed-on: http://review.coreboot.org/7394
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Version 0.9 contains a fix for a security issue. A more
detailed changelog is not available.
Change-Id: I1a66c9da900f89ba9b4c13f3457582278d3793e2
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/7293
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Tested-by: build bot (Jenkins)
Apply commit 283ba78415 to f14 (literally, plus one adaptation).
Change-Id: Ieea47470e5852ec8a46596ce23a2d18444618624
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7361
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Apply commit 283ba78415 to f12 (literally, plus one adaptation).
Change-Id: Ied7891806e269320caf968cae3de3dc792c5f8fd
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7312
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
The static library builder for the stub that interfaces to the
AGESA binary does not include config.h and kconfig.h, so any
header file changes that depend on Kconfig variables fail. Force
these two system headers to be included in the build of any AGESA
stub files.
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Change-Id: I2e8d38fa5aa21cc31b995ee3abe68ab3c3c55a68
Reviewed-on: http://review.coreboot.org/6979
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
Copied (and unmodified) the minimal bits from ChromeOS libVPD:
https://chromium.googlesource.com/chromiumos/platform/vpd
Old-Change-Id: Id75d1bfd16263ac1b94c22979f9892cf7908d5e6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187411
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
(cherry picked from commit a10ca23686299f3fd5b639631242cadaa2ca9e8a)
vendorcode: Update ChromeOS VPD Parser.
Merge recent changes in ChromeOS VPD that allows non-memory-mapped firmware
to load VPD easier and faster (ref:
https://chromium-review.googlesource.com/188134 ).
Old-Change-Id: I3ee0b89c703f476f3d77cdde52cc7588724f7686
Reviewed-on: https://chromium-review.googlesource.com/188743
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 03f4d521a7fa711b963b0e1822e92eac16a691b1)
vendorcode: Access to ChromeOS VPD on default CBFS media.
The new function "cros_vpd_gets(key, buf, size)" provides an easy and quick way
to retrieve values in ChromeOS VPD section.
Old-Change-Id: I38e50615e515707ffaecdc4c4fae65043541b687
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187430
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
(cherry picked from commit bcd3832c06e8ed357c50f19396da21a218dc4b39)
Squashed 3 related commits for a ChromeOS VPD parser.
Change-Id: I4ba8fce16ea123c78d7b543c8353ab9bc1e2aa9f
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6959
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Drop a lot of u-boot-isms and share common TIS API
between I2C driver and LPC driver.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I43be8eea0acbdaef58ef256a2bc5336b83368a0e
Reviewed-on: https://chromium-review.googlesource.com/175670
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3fc8515b9dcef66998658e1aa5c020d22509810c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6855
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
Add all of the PI source that will remain part of coreboot to
build with a binary AGESA PI BLOB. This includes the gcc
makefiles, some Kconfig, and the AGESA standard library
functions.
Change vendorcode Makefile and Kconfig so that they can compile
AMD library files and use headers from outside the coreboot/src
tree.
The AGESA dispatcher is built using its own rules rather than
generic library generation rules in coreboot/Makefile and
coreboot/Makefile.inc. The AGESA source files are initially
copied from whereever they live into coreboot/build/agesa.
They are compiled from there. The binary PI directory has a
mandatory structure that places the AGESA BLOB into the same
directory as the support headers. These will nominally be
placed in the 3rdparty directory in coreboot.org.
The copy commands that were added to the the vendorcode
Makefile.inc ensure that only one thread will operate on each
source file by using a macro to generate the copy targets.
After the change, each copy target will operate on exactly one
source file.
Due to API issues, coreboot has no way to control the IMC to set up
fan control. Set a Kconfig flag that removes the ability to install
an IMC BLOB into CBFS.
Change-Id: I050b72a19086aaeba6cb65ce165297b10e3cfc45
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6595
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
This patch renames the x86 way of doing things to
explicitly mention CMOS (which is not available on
our ARM platforms) and adds an implementation to
get VBNV through the Chrome EC. We might want to
refine this further in the future to allow VBNV
in the EC even on x86 platforms. Will be fixed when
that appears. Also, not all ARM platforms running
ChromeOS might use the Google EC in the future, in
which case this code will need additional work.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901
Reviewed-on: https://chromium-review.googlesource.com/167540
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 8df6cdbcacb082af88c069ef8b542b44ff21d97a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6616
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The absf files contain the modifications to the default settings in
the FSP. They are used as input files for Intel's 'Binary Configuration
Tool' (BCT) along with the FSP.bin file to generate customized FSP
binaries.
The Minnow Max absf files set up the values for the soldered down
memory. This requirement will go away with the release of the next
Bay Trail FSP, and the memory settings will be configurable at
runtime.
Change-Id: Id72545d78a7e82d9a5090710a9c7a8a9b1e81208
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6432
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Provide functionality to create dynamic classes based on program name and
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class. Also, compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6426
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
On x86 VbExGetTimer() uses rdtsc. However, on all
other platforms, let's just use coreboot's monotonic timers.
Change-Id: I0cd359f298be33776740305b111624147e2c850d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169620
(cherry picked from commit e910bb17522d5de42c0fc3cc945278e733fa2553)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6534
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On ARM the SPI flash is not memory mapped. Use the CBFS
interface to map the correct portion.
Change-Id: I8ea9aa0119e90a892bf777313fdc389c4739154e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169781
Reviewed-by: David Hendrix <dhendrix@chromium.org>
(cherry picked from commit a263d3717e82c43fe91e7c4e82d167e74bf27527)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6522
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Without the inclusion of 'fsptypes.h' the order of inclusion becomes
tentative.
Change-Id: I6360e4ebac6c414c380a19ef69d39d658ea203bd
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6423
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
We already have these macros define in 'stdlib.h'. Make good use of them
here to avoid redefinition conflicts of the pre-processor depending on
header inclusion ordering. This has the nice side-effect of syncing up
AGESA families in this particular regard.
Change-Id: Icf911629a4a1a82b01062fe16af4c8f812b05717
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6199
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Implement the fix for the erratum #712. - Processor May Hang During Graphics Memory Controller
Sequencing
The processor may hang during a graphics memory controller (GMC) sleep state transitioning. The failure may
be processor specific and may be sensitive to temperature.
Potential Effect on System:
System hang.
Suggested Workaround:
BIOS should set D18F2x408_dct[1:0] bit 31 = 1b.
See Publication # 48931 Revision: 3.08
Change-Id: I4346fd4ef3cf554ffdaaad5ab6fc84e73532e885
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/6216
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This is an extra file that is included in the Intel GSP release.
It's got a coreboot header on it, isn't used, and looks very
platform specific.
I'm not sure where it belongs, but it doesn't belong in vendorcode.
I've sent the contacts at Intel an email letting them know that this
file should probably be removed from their FSP release and is getting
removed here.
Change-Id: I5ac6649235846ce5716bb180af29a5e422f4cce3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5809
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The 'm' (a memory reference) constraint makes little sense here since we
are talking about a fs relative read, rather 'ir' (immediate or
register) constraint is more sensible.
N.B. The 'p' constraint allows anything which fits the form of an address
calculation where the 'ir' constraint is just a register /xor/
immediate. Hence would produce better code here however, unfortunately,
clang does not currently support it properly.
The %b and %w constraints are also redundant and only hide errors.
The functions writefsword() and writefsdword() should use ir instead of
iq. iq is unnecessarily restrictive (it is only required for writing
bytes).
The cld in stosb is redundant (and the constraints are unnecessarily
complicated). Note that The ABI guarantees that the direction flag is
cleared. i.e. eax, ecx, edx are caller-saved, returned value in eax,
eax+edx, st0, yaddayadda, direction flag cleared. In fact bad things can
happen if you set it in some asm and do not clear it until the end of
the asm.
Line wrap these extraneously long lines found with these particular functions.
Many thanks to Christoph Mallon <christoph.mallon@gmx.de> from #llvm for
helping me with this.
Change-Id: Iaf3ad65791640e1060a2029e7ebb043f57b338a9
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The semantics of this loop relies on an integer overflow in Index >=0
that implies a return value of (UINT8)-1 which around wraps to 0xFF, or
VOLT_UNSUPPORTED.
Change-Id: I44d68973d0a80093350b2a8a4d3b46bfbb57917a
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5801
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The typedef'ed BIT_FIELD_NAME enum is type unsigned. The parameter
'FieldName' is decleared with type BIT_FIELD_NAME and thus the redudant
comparison of unsigned enum expression >= 0 is always true.
BIT_FIELD_NAME is declared in vendorcode/amd/agesa/f14/Proc/Mem/mm.h
Change-Id: Id2f03596c44b68e861e939f3528256d4b08c45ce
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5757
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The conditional comparison in the for-loop construct with the constant
300000 has an index incrementor of type 'UINT16' (aka 'unsigned short')
which is always true.
Change-Id: I932c168742163be4038728fb40833231a447fa78
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5799
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
- Duplicate declaration of GetFspReservedMemoryFromGuid
- Corrupt line that was only compiled for a southbridge that no
board in coreboot currently uses.
(thanks for Mike Hibbett <mhibbett@ircona.com> for pointing this out)
Change-Id: I847e807272acbaa93c87a89c0d2f94829c9121e6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/5798
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
The function GfxPowerPlayLocateTdp() sets MinDeltaSclk to a maximum
sentinel value and checks DeltaSclk in a loop to minimize MinDeltaSclk.
However, MinDeltaSclk incorrectly self-assigns.
Change-Id: Id01c792057681516bba411adec268769a3549aa8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5752
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Change-Id: I31632948ce69b2d1ff63b6c920016ed6fdf9e2f8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5760
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I1d801b9d8387e267feeb95563e55910b30ebbc34
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5790
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
After moving out -m32 from CC_*, 64bit compilers need
CFLAGS_* in more places to handle everything in 32bit
as appropriate.
Change-Id: I692a46836fc0ba29a3a9eb47b123e3712691b45d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5789
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
They don't exactly add clarity, but increase the risk
they're used at some obscure place.
Change-Id: Ic74f72dae3f9b7eb2343cb5c51bc44c888e1276c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5787
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
They're _not_ part of the compiler binary, so they have
no place in $(CC_*)
Change-Id: I1e1c3c0be6f75629450a824ea834e1614d48ed9b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5785
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
With the upcoming CC/CFLAGS/CPPFLAGS split,
romcc gets more CPPFLAGS, and it's picky about
directories actually existing.
Change-Id: Ib9c525296e5be0c8ace935ab8096bc98206cbcc1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5784
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
No need to first define X86_32 and then replace every
single use of it with its lower cased equivalent.
Just start out with the lower case versions in the first
place.
Change-Id: I1e771ef443db1b8d34018d19a64a9ee489cd8133
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5767
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
There are a couple of places where CPPFLAGS are
pasted into CFLAGS, eliminate them.
Change-Id: Ic7f568cf87a7d9c5c52e2942032a867161036bd7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5765
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Rename INCLUDES to CPPFLAGS since the latter is more
commonly used for preprocessor options.
Change-Id: I522bb01c44856d0eccf221fa43d2d644bdf01d69
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5764
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This feature is no longer specific to ChromeOS builds.
Change-Id: If27d4dc7caff8a551b5b325cdebdd05c079ec921
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5641
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
A global flag oprom_is_loaded was used to indicate to
U-boot that VGA option ROM was loaded and run, or that
native VGA init was completed on GMA device.
Implement this feature without dependency to CHROMEOS option
and replace use of global variable oprom_is_loaded with call
to gfx_get_init_done().
Change-Id: I7e1afd752f18e5346dabdee62e4f7ea08ada5faf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4309
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Following the same reasoning as commit
ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
Change-Id: I8b78c462f4963fbb3a40d739196529fffedccb4c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5441
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Up until now, we were building AGESA by specifying each AGESA source
file and adding it to the list of romstage and ramstage source files.
As a result, we were compiling each AGESA source twice, despite the
fact that it does not depend on the stage we're in.
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
We still keep the practice of specifying every single AGESA directory
as an include dir and adding the AGESA CFLAGS to our global CFLAGS;
this is needed due to the way AGESA builds.
Change-Id: I9b23264129d1c08cb67cabc31d15a68d43ed7624
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5430
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
These are the .h and .c files from Intel that support interaction
with the FSP. These have been modified from the FSP distribution
only to strip trailing whitespace.
Intel® Firmware Support Package for Intel® Atom™ Processor C2000
Product Family (Formerly Rangeley)
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/fsp
Change-Id: I9ed94cb92909c3681cc88bf10b85a9ba25e8fc55
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5457
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
These are the .h and .c files from Intel that support interaction
with the FSP. These have been modified from the FSP distribution
only to strip trailing whitespace.
Intel® Atom™ processor E3800 product family (formerly Bay Trail)
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/fsp
Change-Id: I0fa64dbaf640493cdb5e670e8d213a49d9e7dcfb
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5456
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are the .h and .c files from Intel that support interaction
with the FSP. These have been modified from the FSP distribution
only to strip trailing whitespace.
Intel® Firmware Support Package for Intel® Xeon® E3-1125C v2,
E3-1105C v2, Intel® Pentium® Processor B925C, and Intel® Core™
i3-3115C Processors for Communications Infrastructure with
Intel® Communications Chipset 89xx Series Platform Controller Hub
(formerly Crystal Forest Refresh: Ivy Bridge Gladden and Cave Creek
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/fsp
Change-Id: Ib76e89b2d2f6407cf55a5a664da989c7a7e0eb23
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5455
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Other FSPs have more than just the initial fsphob.c source file.
Add any .c files in the srx directory to the ramstage build.
Change-Id: I5118bdcca44935b579809c4fc9566ab7914a6e4b
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/5454
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The ROM address range is set up in the LPC PCI device, register 0x6c.
Coreboot already sets that up correctly in the bootblock, however
AGESA overrides that to 0xffffff00, which will always map the ROM from
0xff000000. This may conflict with other devices which are assigned
address space in that range.
If a device is assigned a range between 0xff000000 and the real ROM
base, accesses to that device will be diverted to the system ROM,
regardless of how other BARs are set up. Since we already need to set
up the ROM address range in the bootblock, before calling AGESA, just
remove the override from AGESA.
Note that not all AGESA versions override this mapping.
Change-Id: I592e5d087ed830c9604a04a356912c7654ce56d2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5467
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Do not expose console_tx_flush() to ChromeOS as that function
is part of lower-level implementation.
Change-Id: I1e31662da88a60e83f8e5d307a4b53441c130aab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5347
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5257
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A payload can be loaded either from a vboot region or from cbfs.
Provide a common place for choosing where the payload is loaded
from. Additionally, place the logic in the 'loaders' directory
similarly to the ramstage loader infrastructure.
Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5296
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A comparison with a two's complement in gcccar.inc has dubious
GAS/AT&T notation. Clang miss-parses 0x-1 as an invalid hexadecimal
number.
Change-Id: I88baa5c2513f062ff309df05916a3832b9bd9bb1
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5277
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The arm architectures have a stage_exit() function
which takes a void * pointer as an entry point. Provide
the same API for x86. This can make the booting paths
less architecture-specific.
Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5086
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It is inappropriate for chipset code to be redefining
types -- especially NULL to a non-pointer type. There's
only one non-straight forward change. A condition
being checked was '!ptr_type == NULL' (0 as int). That
check is actually 'ptr_type != NULL'.
Change-Id: Iab5733e5a573baba6fec94e0c955ba4fad72c836
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5088
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The AGESA resumes the GPP ports in the romstage using FchInitResetGpp(),
which does FchGppPortInitS3Phase() for S3 resume. The PreInitGppLink()
looks into CMOS to figure out what ports to just force to Gen1 or
Gen2 PCIe. Then boot continues and in the ramstage the rest of GPP
init is executed. There is a problem that nobody sets properly the
PortDetected flags in the S3 path. As the consequence FchGppDynamicPowerSaving()
thinks the GPP port is not enabled and shut downs it.
The best fix would be also to remove the CMOS dependency which
might be some left over, because AGESA does not use CMOS much for
anything else. There could be also some way how to pass the GPP state
structure from romstage to ramstage possibly via hudson/resume.c
but I don't know how to do that. Similar problem is that the "late"
stage of init again "forgets" the PortDetected state.
This fix fixes the resume issue on Asus F2A85-M. With this patch applied
both GPP ports (used as PCIe x1 and internal ethernet) are working again
after resume.
Change-Id: Idaf609043abb09441c6790504d66d23e0637588f
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/4671
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being
selected allow for calling vboot_verify_firmware()
with an empty implementation. This allows for one not to
clutter the source with ifdefs.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded
call to vboot_verify_firmware().
Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172711
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4879
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The Virtual Recovery switch flag needs to be set in coreboot since
it is passed through directly to VBOOT layer by depthcharge.
Rather than add a new config option we can assume that devices with
EC Software Sync also have a virtual recovery switch and set the
flag appropriately.
BUG=chrome-os-partner:25250
BRANCH=all
TEST=build and boot on rambi, successfully enter developer mode
Change-Id: Id067eacbc48bc25a86887bce8395fa3a9b85e9f2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5061
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4897
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
As some of the standard definitions were shuffled around
chromeos started failing to build. Correct this.
Change-Id: I9927441ccb2d646e8b3395e6e9f8e8166de74ab0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4844
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Number one reason to use cbfs_get_file was to get file length.
With previous patch no more need for this.
Change-Id: I330dda914d800c991757c5967b11963276ba9e00
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4674
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
When using RW firmware path the proper recovery reason can
be retrieved from the shared data region. This will result
in the actual reason being logged instead of the default
"recovery button pressed" reason.
1) build and boot on falco
2) crossystem recovery_request=193
3) reboot into recovery mode, check reason with <TAB>
4) reboot back into chromeos
5) check event log entry for previous recovery mode:
25 | 2013-07-15 10:34:23 | Chrome OS Recovery Mode | Test from User Mode
Change-Id: I6f9dfed501f06881e9cf4392724ad28b97521305
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61906
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4368
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The bug is hard to find. We were adding the feature of fan control. We
met some strange things which could not be explained. Like, sometimes
adding printk let the error disappear. Then we traced the code by hardware
debug tool (HDT). It turned out the data in stack was overwritten.
The values of AccessWidthxx are
{ AccessWidth8 = 1,
AccessWidth16,
AccessWidth32,}
For the case of AccessWidth8, we only need to access the index/data
once. But ReadECmsg and WriteECmsg did the loop twice, 1 more time
than they are supposed to do. The data in stack next to "Value" would
be overwritten.
For all the cases, the code should be
OpFlag = OpFlag & 0x7f;
switch (OpFlag) {
case 1: /* AccessWidth8 */
OpFlag = 0;break;
case 2: /* AccessWidth16 */
OpFlag = 1;break;
case 3: /* AccessWidth32 */
OpFlag = 3;break;
case 4: /* AccessWidth64 */
OpFlag = 7;break;
default:
error;
}
Actually, the caller only takes AccessWidth8 as the parameter. We can ignore other
cases for now.
That is an AGESA bug. AMD's AGESA team own this code. They have given the
response that they are going to update this in next release. I presume let them
decide the proper way to fix that. Before that, I change the code as little
as possible to make it run without crash.
Change-Id: I566f74c242ce93f4569eedf69ca07d2fb7fb368d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4297
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Add support for Sandybridge and Ivybridge using the Intel FSP.
The FSP is different enough to warrant its own source files.
This source handle the majority of FSP interaction.
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4015
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to make the proper decision on loading the
option rom or not the recovery mode setting needs to be
known. Normally this is detected by asking the EC,
but if recovery is requested with crossystem then the EC
does not know about it. Instead we need to check the
output flags from VbInit().
Change-Id: I09358e6fd979b4af6b37a13115ac34db3d98b09d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57474
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4223
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Since we are using VBNV to determine if developer mode is
active we do not need the messy OPROM hook magic any longer.
Change-Id: I1b9effef3ef2aa84e916060d8e61ee42515a2b7c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57473
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4222
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Those building Chromebook firmware from coreboot git might be more
interested in building without ChromeOS extras.
Change-Id: I2f176d059fd45bf4eb02cc0f3f1dcc353095d0ce
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3977
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In order to make the proper decision on loading the
option rom or not the developer mode setting needs to be
known. Under early firmware selection it is possible to know
the state of developer mode by a flag in out flags. Use this
flag when early firmware selection is being employed to determine
if developer mode is enabled or not.
Change-Id: I9c226d368e92ddf8f14ce4dcde00da144de2a5f3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57380
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4218
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
- Disable EC software sync for now
- Report correct EC active firmware mode
- Force enable developer mode by default
- Set up PCH generic decode regions in romstage
- Pass the oprom_is_loaded flag into vboot handoff data
Change-Id: Ib7ab35e6897c19455cbeecba88160ae830ea7984
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4169
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes an earlier patch that caused the VGA option ROM to be loaded by
coreboot even in normal mode when it isn't needed.
Change-Id: Ie0a331a10fff212a2394e7234a0dbb37570607b7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48173
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4125
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Compile was failing with the following error:
In file included from src/vendorcode/google/chromeos/vboot_handoff.h:22:0,
from src/vendorcode/google/chromeos/chromeos.c:22:
vboot_reference/firmware/include/vboot_api.h:388:18: error: unknown type name 'size_t'
src/vendorcode/google/chromeos/chromeos.c: In function 'vboot_get_payload':
src/vendorcode/google/chromeos/chromeos.c:50:23: error: 'NULL' undeclared (first use in this function)
Change-Id: I13f9e41ef6a4151dc65a49eacfa0574083f72978
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48289
Reviewed-on: http://review.coreboot.org/4131
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The platform initialization (PI) code v1.0.0.7 for Kabini has some
enhancements like ECC DIMM support, new CPU microcode rev 0700010B, FCH
bug fix (RTC) and so on.
Use the name Kabini instead of Kerala everywhere.
Note, the former PI code was indeed version v1.0.0.0 instead of v0.0.1.0
as used in `AGESA_VERSION_STRING`.
Change-Id: I186de1aef222cd35ea69efa93967a3ffb8da7248
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3935
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Northbridge code includes these headers, so they all need to
have the same name to allow different combinations of northbridge
and southbridge. This changes the sb900 names to match sb700 &
sb800, and points agesa/family12 and amd/torpedo to the new file
names.
Change-Id: I7a654ce9ae591a636a56177f64fb8cb953b4b04f
Signed-off-by: Corey Osgood <corey.osgood@gmail.com>
Reviewed-on: http://review.coreboot.org/3825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
src/southbridge/amd/agesa/hudson/Kconfig config default value,
mainboard Kconfig config value for specific mainboard.
bit 1,0 - pin 0
bit 3,2 - pin 1
bit 5,4 - pin 2
bit 7,6 - pin 3
Change-Id: I54a87cf734685515a3e1850838ca7d94387172ce
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3879
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Instead of returning 0 on success and -1 on error, return the decompressed
size of the data on success and 0 on error. The decompressed size is useful
information to have that was being thrown away in that function.
Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Copied from a similar commit for Family 10h AGESA [1]
Remove the fourth argument in the comments. Luckily the compiler,
at least gcc, warns about a wrong number of arguments, and therefore
no incorrect code resulted from the wrong documentation.
[1] 07e0f1b AMD AGESA: Fix argument list for `PCIE_DDI_DATA_INITIALIZER` in comments
[2] fc47bfa Revert "AMD f14 vendorcode: Fix warning"
Change-Id: I3806e368a823e4a40d22e99b91bf3598d9ed2f15
Signed-off-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3840
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
This is the same patch as an earlier one applied to family 15 [1].
Static analysis often flags case statements that do not include
a terminating "break;" statement. Eclipse's CODAN is an example
of this. This changelist modifies amdlib.c to terminate
case statements with "break;".
[1] e44a89f amd/agesa/f15/Lib/amdlib.c: Add missing breaks ...
Change-Id: Ibd1ae6f2b52fde07de3d978d174975f4d93647ab
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3839
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Add CONST modifiers to read-only pass-by-reference function
parameters in AGESA. This allows the use of "const" modifiers
on the declaration of lookup tables that are pass-by-reference.
These will be used to identify tables that are copied onto the
HEAP but don't need to be.
This same change was made for AMD Trinity APUs (Family15tn) [1].
[1] 283ba78 AGESA: Add "const" modifier to function parameters
Change-Id: I2bdd9fc5e027e938de9df0f923b95da934bb48dc
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3837
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This changelist was cherry-picked from merged community code
for Parmer [1] and the paths modified so that the Parmer
modification is applied against Olive Hill.
[1] 0086162 AMD SATA: Correct _them implement_ ... in comments
Change-Id: I9849e9a75dacfde15331c4200d72343a59036f14
Signed-off-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3841
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Static analysis often flags case statements that do not include
a terminating "break;" statement. Eclipse's CODAN is an example
of this. This changelist modifies amdlib.c to terminate
case statements with "break;".
Change-Id: I3d43acaf64e2e2d9717421cb547fec35e582cf8b
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3539
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change is mostly type casts to eliminate compile time
warnings. These specific changes are mostly cherry-picked from
AMD Family 14 code and, as such, contain artifacts copied over
from F14. For example, there are a number of UINT64 casts that
are commented out rather than removed. This is to maintain
consistency between AGESA versions. Ultimately, this is in
preparation for turning on warnings as errors for AMD Family 15
server parts.
Change-Id: Ic73d0b6ebab18d97015a9dd1130aff4e5e432fb7
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3525
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
fam15 vendorcode (src/vendorcode/amd/agesa/f15tn) was licensed under the
AMD software license agreement. Change this license to 3-clause BSD.
Change-Id: I7cab09bb58ef7cd24602628e2278672d577214a2
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add CONST modifiers to read-only pass-by-reference function
parameters in AGESA. This allows the use of "const" modifiers
on the declaration of lookup tables that are pass-by-reference.
These will be used to identify tables that are copied onto the
HEAP but don't need to be.
Change-Id: Ie1187a427804fddf47b935a110ad23931a3447a9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's possible that the vbnv global variables may be accessed
in romstage after cache-as-ram is torn down. Therefore use
the cache-as-ram migration API. Wrappers were written to
wrap the API to keep the existing code as close as possible.
Change-Id: Ia1d8932f98e00def0a44444a1ead0018a59d3d98
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3234
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
build-snow got broken when the snow makefile improved. So fix it.
While we're at it, create a script like the update-microcode
scripts that gets the bl1. I thought about making this a common
script but the various names and paths always evolve, leaving
me thinking it's not worth it. This script is just a
piece of the snow build script.
Change-Id: I65c0f8697a978c62fe12533c4f0152d14dbaefda
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3238
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Fix Warning:
cpuFeatureLeveling.c:265, GNU Compiler 4 (gcc), Priority: Normal
cast to pointer from integer of different size [-Wint-to-pointer-cast]
with an intermediate cast to (intptr_t)
Change-Id: I3bfd2ea1e797632316675338789dabef8f73ba64
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3126
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes 3 warnings in the Proc/Common directory:
AmdS3Save.c:250, GNU Compiler 4 (gcc), Priority: Normal
AmdS3LateRestore.c:123, GNU Compiler 4 (gcc), Priority: Normal
cast from pointer to integer of different size [-Wpointer-to-int-cast]
Fixed with a second cast to (intptr_t)
AmdInitReset.c:153, GNU Compiler 4 (gcc), Priority: Normal
statement with no effect [-Wunused-value]
Fixed by commenting the line out as it is in the other families code.
Change-Id: Ib35ec466671712af01568b7c2a18ee138fe883c0
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3125
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The following command was used to correct all occurences of this typo.
$ git grep -l "them implem" | xargs sed -i 's/them implem/then implem/'
Change-Id: Iebd4635867d67861aaf4d4d64ca8a67e87833f38
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Because pointers can be 32bit or 64bit big,
using them in the coreboot table requires the
OS and the firmware to operate in the same mode
which is not always the case. Hence, use 64bit
for all pointers stored in the coreboot table.
Guess we'll have to fix this up once we port to
the first 128bit machines.
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3115
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
When looking into possible reasons for a proposed revert [1], I noticed
that the comments use four arguments for `PCIE_DDI_DATA_INITIALIZER`,
but the actual definition only uses three.
$ git grep -A1 PCIE_DDI_DATA_INITIALIZER # manually squeeze whitespace in output
[…]
--
src/vendorcode/amd/agesa/f10/AGESA.h:#define PCIE_DDI_DATA_INITIALIZER(mConnectorType, mAuxIndex, mHpdIndex ) \
src/vendorcode/amd/agesa/f10/AGESA.h-{mConnectorType, mAuxIndex, mHpdIndex}
--
src/vendorcode/amd/agesa/f10/AGESA.h: * PCIE_DDI_DATA_INITIALIZER (ConnectorType
src/vendorcode/amd/agesa/f10/AGESA.h- * },
--
src/vendorcode/amd/agesa/f10/AGESA.h: * PCIE_DDI_DATA_INITIALIZER (ConnectorType
src/vendorcode/amd/agesa/f10/AGESA.h- * }
--
[…]
So remove the fourth argument in the comments. Luckily the compiler,
at least gcc, warns about a wrong number of arguments, and therefore
no incorrect code resulted from the wrong documentation.
[1] http://review.coreboot.org/#/c/3077/
Change-Id: I3e5a02c66a23af1eb2d86be8dbc7aaa3e5cea05e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3080
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Spell RAID correctly in comments. Found with the following command.
$ git grep -i riad
Change-Id: I68e8476d885a88df589d25f88cc158d71eb04e07
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3081
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
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>
There were 3 things stopping the vboot module from being
compiled:
1. The vboot_reference code removed in the firmware/arch/$(ARCH)/include
directory. This caused romcc to fail because romcc fails if -I<dir>
points to non-existent directory.
2. The rmodule API does not have the no-clearing-of-bss variant of the
load function.
3. cbfs API changes.
Change-Id: I1e1296c71c5831d56fc9acfaa578c84a948b4ced
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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)
The coreboot include were not being passed correctly when
building vboot_reference. The paths being included were of the
src/<dir> form. However, vboot_reference lives in
src/../vboot_reference. That coupled with the recursive make
call made vboot_reference not see coreboot's header files.
Fix this by appending ../ to coreboot's default include paths.
Change-Id: I73949c6f854ecfce77ac36bb995918d51f91445e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2860
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot_handoff structure contians the VbInitParams as well as the
shared vboot data. In order for the boot loader to find it, the
structure address and size needs to be obtained from the coreboot
tables.
Change-Id: I6573d479009ccbf373a7325f861bebe8dc9f5cf8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2857
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch implements support for vboot firmware selection. The vboot
support is comprised of the following pieces:
1. vboot_loader.c - this file contains the entry point,
vboot_verify_firmware(), for romstage to call in order to perform
vboot selection. The loader sets up all the data for the wrapper
to use.
2. vboot_wrapper.c - this file contains the implementation calling the vboot
API. It calls VbInit() and VbSelectFirmware() with the data supplied
by the loader.
The vboot wrapper is compiled and linked as an rmodule and placed in
cbfs as 'fallback/vboot'. It's loaded into memory and relocated just
like the way ramstage would be. After being loaded the loader calls into
wrapper. When the wrapper sees that a given piece of firmware has been
selected it parses firmware component information for a predetermined
number of components.
Vboot result information is passed to downstream users by way of the
vboot_handoff structure. This structure lives in cbmem and contains
the shared data, selected firmware, VbInitParams, and parsed firwmare
components.
During ramstage there are only 2 changes:
1. Copy the shared vboot data from vboot_handoff to the chromeos acpi
table.
2. If a firmware selection was made in romstage the boot loader
component is used for the payload.
Noteable Information:
- no vboot path for S3.
- assumes that all RW firmware contains a book keeping header for the
components that comprise the signed firmware area.
- As sanity check there is a limit to the number of firmware components
contained in a signed firmware area. That's so that an errant value
doesn't cause the size calculation to erroneously read memory it
shouldn't.
- RO normal path isn't supported. It's assumed that firmware will always
load the verified RW on all boots but recovery.
- If vboot requests memory to be cleared it is assumed that the boot
loader will take care of that by looking at the out flags in
VbInitParams.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as well
by choosing the RO path.
Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I4aba6cc490ab24c6db345c0c5a64a6a9985ed0ab
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/2864
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
One might wonder what a board named 'build' does. Rename the file to
build-snow. The fact that it is in a directory with google in the name
should be enough to identify the vendor.
Change-Id: I0b473cdce67d56fc6b92032b55180523eb337d66
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2766
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
AGESA code has wrong definition of CR0_PE bit (1 instead of 0).
PE [Protected Mode Enable] is 0 bit in CR0 register
(If PE=1, system is in protected mode, else system is in real mode)
Bit 1 is MP [Monitor co-processor]
(Controls interaction of WAIT/FWAIT instructions with TS flag in CR0)
System uses CR0_PE define, but I didn't expect any consequences because of this bug.
Change-Id: I54d9a8c0ee3af0a2e0267777036f227a9e05f3e1
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2591
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
_RDMSR instruction loads the contents of a 64-bit model specific register (MSR)
specified in the ECX register into registers EDX:EAX.
The EDX register is loaded with the high-order 32 bits of the MSR
and the EAX register is loaded with the low-order 32 bits.
EDX:EAX = MSR[ECX]
So bit 49 will be contained in EDX register.
Buggy code instead of bit 49 (CombineCr0Cd) sets bit [49-32=17] (PfcStrideDis).
PfcStrideDis bit disables stride prefetch generation. This leads to memory
bandwidth loss.
_________
Supermicro H8QGI board
After applying this change i observed huge memory bandwidth increase in tests
that runs on small amount of cores. But unfortunately it doesn't affect
overall bandwidth results on 4P system with 48 cores.
So i think that in this system leading limiting factor is
AMD HT-ASSIST feature (Probe filter).
But right now it is not working. System stucks in Linux boot. I have done
some experiments and figured out that stuck happens when system have cores in
compute unit (CU) other than CU with BSC (boot strap core).
CU is two cores (primary and seconary) that shares some things (L2 cache, FPU ...)
So with probe filter i can boot Linux with one (BSC)
or two (BSC + secondary core in its CU) cores.
And with this configuration i can see memory bandwidth on 1 core (or two cores)
close to original bios.
Change-Id: I5a95f5b753d600c70d3c93d36fecc687610c61cd
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2588
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
These were not separable or it would have been two CLs.
Enable CHROMEOS configure option on snow. Write gpio support code for
the mainboard. Right now the GPIO just returns hard-wired values for
"virtual" GPIOs.
Add a chromeos.c file for snow, needed to build.
This is tested and creates gpio table entries that our hardware can use.
Lots still missing but we can now start to fill in the blanks, since
we have enabled CHROMEOS for this board. We are getting further into
the process of actually booting a real kernel.
Change-Id: I5fdc68b0b76f9b2172271e991e11bef16f5adb27
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2467
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add brackets around initializer in #define for
PCIE_DDI_DATA_INITIALIZER to fix the warning:
PlatformGnbPcie.c:89, GNU Compiler 4 (gcc), Priority: Normal
missing braces around initializer [-Wmissing-braces]
This warning happens for Inagua and South Station
Change-Id: I7d8f742dd8335b704b0493aa6e9eaebc3cc50b1e
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2495
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add needed prototypes to .h files.
Remove unused variables and fix types in printk statements.
Add #IFNDEFs around #DEFINEs to keep them from being defined twice.
Fix a whole bunch of casts.
Fix undefined pre-increment behaviour in a couple of macros. These now
match the macros in the F14 tree.
Change a value of 0xFF that was getting truncated when being assigned
to a 4-bit bitfield to a value of 0x0f.
This was tested with the torpedo build.
This fixes roughly 132 of the 561 warnings in the coreboot build
so I'm not going to list them all.
Here is a sample of the warnings fixed:
In file included from src/cpu/amd/agesa/family12/model_12_init.c:35:0:
src/include/cpu/amd/amdfam12.h:52:5: warning: redundant redeclaration of 'get_initial_apicid' [-Wredundant-decls]
In file included from src/cpu/amd/agesa/family12/model_12_init.c:34:0:
src/include/cpu/amd/multicore.h:48:5: note: previous declaration of 'get_initial_apicid' was here
src/northbridge/amd/agesa/family12/northbridge.c:50:10: warning: no previous prototype for 'get_node_pci' [-Wmissing-prototypes]
src/northbridge/amd/agesa/family12/northbridge.c: In function 'get_hw_mem_hole_info':
src/northbridge/amd/agesa/family12/northbridge.c:302:13: warning: unused variable 'i' [-Wunused-variable]
src/northbridge/amd/agesa/family12/northbridge.c: In function 'domain_set_resources':
src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat]
src/northbridge/amd/agesa/family12/northbridge.c:587:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'device_t' [-Wformat]
src/northbridge/amd/agesa/family12/northbridge.c:716:1: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat]
In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0,
from src/northbridge/amd/agesa/family12/northbridge.c:38:
src/vendorcode/amd/agesa/f12/AGESA.h:1282:0: warning: "TOP_MEM" redefined [enabled by default]
In file included from src/northbridge/amd/agesa/family12/northbridge.c:34:0:
src/include/cpu/amd/mtrr.h:31:0: note: this is the location of the previous definition
In file included from src/mainboard/amd/torpedo/agesawrapper.h:31:0,
from src/northbridge/amd/agesa/family12/northbridge.c:38:
src/vendorcode/amd/agesa/f12/AGESA.h:1283:0: warning: "TOP_MEM2" redefined [enabled by default]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetNumberOfComplexes':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:99:19: warning: operation on 'ComplexList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfPcieEnginesList':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:126:20: warning: operation on 'PciePortList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetLengthOfDdiEnginesList':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:153:19: warning: operation on 'DdiLinkList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c: In function 'PcieInputParserGetComplexDescriptorOfSocket':
src/vendorcode/amd/agesa/f12/Proc/GNB/Modules/GnbPcieConfig/PcieInputParser.c:225:17: warning: operation on 'ComplexList' may be undefined [-Wsequence-point]
src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PciePhyServices.c:246:1: warning: no previous prototype for 'PcieFmForceDccRecalibrationCallback' [-Wmissing-prototypes]
In file included from src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/F12PcieComplexConfig.c:58:0:
src/vendorcode/amd/agesa/f12/Proc/GNB/PCIe/Family/LN/LlanoComplexData.h:120:5: warning: large integer implicitly truncated to unsigned type [-Woverflow]
And fixed a boatload of these types of warning:
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c: In function 'HeapGetBaseAddress':
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:687:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:694:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:701:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:702:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:705:23: warning: assignment makes integer from pointer without a cast [enabled by default]
src/vendorcode/amd/agesa/f12/Proc/CPU/heapManager.c:709:21: warning: assignment makes integer from pointer without a cast [enabled by default]
Change-Id: I97fa0b8edb453eb582e4402c66482ae9f0a8f764
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2348
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Add a prototype to a .h file
Remove an unused file (GppHp.c) from the build by deleting it from the
makefile. I left the file since this is vendorcode. This is the code
for PCIe hotplug.
Inside GppHp.c, make functions not called from outside static.
This obviously isn't important since the file isn't used, but for
the sake of the cleanup I thought I'd go ahead with it...
This was tested with the torpedo build.
This fixes these warnings:
src/vendorcode/amd/cimx/sb900/Dispatcher.c: In function 'LocateImage':
src/vendorcode/amd/cimx/sb900/Dispatcher.c:193:38: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/cimx/sb900/Usb.c:740:1: warning: no previous prototype for 'XhciA12Fix' [-Wmissing-prototypes]
src/vendorcode/amd/cimx/sb900/GppHp.c:65:1: warning: no previous prototype for 'sbGppHotPlugSmiProcess' [-Wmissing-prototypes]
src/vendorcode/amd/cimx/sb900/GppHp.c: In function 'sbGppHotPlugSmiProcess':
src/vendorcode/amd/cimx/sb900/GppHp.c:76:5: warning: implicit declaration of function 'SbStall' [-Wimplicit-function-declaration]
src/vendorcode/amd/cimx/sb900/GppHp.c: At top level:
src/vendorcode/amd/cimx/sb900/GppHp.c:101:1: warning: no previous prototype for 'sbGppHotUnplugSmiProcess' [-Wmissing-prototypes]
src/vendorcode/amd/cimx/sb900/GppHp.c:134:1: warning: no previous prototype for 'sbGppHotplugSmiCallback' [-Wmissing-prototypes]
src/vendorcode/amd/cimx/sb900/GppHp.c: In function 'sbGppHotplugSmiCallback':
src/vendorcode/amd/cimx/sb900/GppHp.c:158:5: warning: implicit declaration of function 'outPort80' [-Wimplicit-function-declaration]
Change-Id: I5a1a20eeb81e1f4d59e3e3192f081e11d8506f56
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2349
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This will make the build script wipe out more flash memory content.
Our image is a bit bigger now that we're testing with payloads, so
this is just added paranoia to prevent weird surprises caused by not
flashing the full image.
Change-Id: I31969922079e96886573d9d802266eb0052277cd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2352
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Added casts and a couple of #ifdefs to fix the warnings in the
vendorcode/amd/agesa/f14 codebase. This will allow us to re-enable
'all warnings being treated as errors' in boards such as Persimmon
that are using this code. That change will follow.
These are the warnings that are fixed by this patch:
src/vendorcode/amd/agesa/f14/Legacy/Proc/hobTransfer.c: In function 'CopyHeapToTempRamAtPost':
src/vendorcode/amd/agesa/f14/Legacy/Proc/hobTransfer.c:219:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f14/Legacy/Proc/hobTransfer.c: In function 'CopyHeapToMainRamAtPost':
src/vendorcode/amd/agesa/f14/Legacy/Proc/hobTransfer.c:372:30: warning: comparison between pointer and integer [enabled by default]
src/vendorcode/amd/agesa/f14/Legacy/Proc/hobTransfer.c:381:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/cpuApicUtilities.c: In function 'ApUtilSetupIdtForHlt':
src/vendorcode/amd/agesa/f14/Proc/CPU/cpuApicUtilities.c:863:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/cpuApicUtilities.c:872:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/cpuMicrocodePatch.c: In function 'LoadMicrocode':
src/vendorcode/amd/agesa/f14/Proc/CPU/cpuMicrocodePatch.c:211:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c: In function 'HeapManagerInit':
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:167:52: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:183:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c: In function 'HeapGetBaseAddress':
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:669:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:676:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:683:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:684:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:687:23: warning: assignment makes integer from pointer without a cast [enabled by default]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:691:21: warning: assignment makes integer from pointer without a cast [enabled by default]
src/vendorcode/amd/agesa/f14/Proc/CPU/heapManager.c:696:3: warning: return makes pointer from integer without a cast [enabled by default]
In file included from src/mainboard/amd/persimmon/agesawrapper.h:30:0,
from src/northbridge/amd/agesa/family14/northbridge.c:36:
src/vendorcode/amd/agesa/f14/AGESA.h:1132:0: warning: "TOP_MEM" redefined [enabled by default]
In file included from src/northbridge/amd/agesa/family14/northbridge.c:34:0:
src/include/cpu/amd/mtrr.h:31:0: note: this is the location of the previous definition
In file included from src/mainboard/amd/persimmon/agesawrapper.h:30:0,
from src/northbridge/amd/agesa/family14/northbridge.c:36:
src/vendorcode/amd/agesa/f14/AGESA.h:1133:0: warning: "TOP_MEM2" redefined [enabled by default]
In file included from src/northbridge/amd/agesa/family14/northbridge.c:34:0:
src/include/cpu/amd/mtrr.h:34:0: note: this is the location of the previous definition
Verified on persimmon.
Change-Id: I1671b191c72dfc1d63ada41126ae3418bc8f86ae
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2293
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Steven Sherk <steven.sherk@se-eng.com>
Enable 'all warnings being treated as errors' in thatcher and parmer.
Fixed the following warnings on parmer / thatcher:
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:
In function 'GetGlobalCpuFeatureListAddress':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:291:14:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:
In function 'SaveDeviceContext':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:245:18:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:309:16:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuPostInit.c:
In function 'GetPstateGatherDataAddressAtPost':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuPostInit.c:235:10:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/TN/mntn.c:
In function 'MemNInitNBDataTN':
src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/TN/mntn.c:353:32:
warning: assignment from incompatible pointer type [enabled by default]
src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/TN/mntn.c:363:23:
warning: assignment from incompatible pointer type [enabled by default]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:
In function 'GetGlobalCpuFeatureListAddress':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:291:14:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:
In function 'SaveDeviceContext':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:245:18:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:309:16:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
In file included from src/northbridge/amd/agesa/family15tn/northbridge.c:37:0:
src/vendorcode/amd/agesa/f15tn/AGESA.h:1547:0:
warning: "TOP_MEM" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:31:0:
note: this is the location of the previous definition
src/vendorcode/amd/agesa/f15tn/AGESA.h:1548:0:
warning: "TOP_MEM2" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:34:0:
note: this is the location of the previous definition
In file included from src/northbridge/amd/agesa/family15tn/northbridge.c:41:0:
src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuRegisters.h:378:0:
warning: "LOCAL_APIC_ADDR" redefined [enabled by default]
src/include/cpu/x86/lapic_def.h:9:0: note:
this is the location of the previous definition
In file included from src/mainboard/amd/parmer/BiosCallOuts.h:24:0,
from src/mainboard/amd/parmer/mainboard.c:28:
src/vendorcode/amd/agesa/f15tn/AGESA.h:1547:0:
warning: "TOP_MEM" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:31:0:
note: this is the location of the previous definition
src/vendorcode/amd/agesa/f15tn/AGESA.h:1548:0:
warning: "TOP_MEM2" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:34:0: note:
this is the location of the previous definition
Change-Id: Iecea28232f1761401cf09f7d2a77d3fbac2f5801
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2171
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In the AGESA routine GfxInitSview() called in the S3save path,
the IO Space bit was getting cleared from the command register.
This kept seabios from initializing the video bios. If the vbios
was loaded by coreboot, this routine was skipped, allowing seabios
to initialize vbios as well. I have modified the routine to save
and restore the command register instead of clearing the IO Space
bit.
Change-Id: I756b0606adbc47da96780308c911852e39f547c7
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2172
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The Number of Ports register says that it should be set to the maximum
number of ports supported by the silicon. AGESA was setting this to be
the number of enabled ports. If port 1 was the only port with a drive,
this value got set to 0, indicating 1 port. This causes SeaBIOS to only
look at port 0 and quit, never finding the drive on port 1.
Dave Frodin: I also verified that this patch allows a SATA drive plugged
into port 2 to be detected without a device in port 1.
Change-Id: I5d49e351864449520e3957bbb07edf0f3ec2fd47
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2165
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Please, don't just add random directories for a single file because
it seems convenient. There already is a chromeos directory, that should
be used.
Change-Id: I625292cac4cbffe31ff3e3d952b11cd82e4b151e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2137
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ACPI code:
The ACPI code is not currently being compiled in by default, but
assuming that it will be at some point, I'm fixing the loop that
waits for the IMC to respond after sending it a command. The
loop now exits after 500ms, similar to the function in agesa.
Agesa Code:
a 16 bit variable will always be less than 100000. Change to
be a 32 bit variable.
Change-Id: I9430ef900a22d056871b744f3b1511abdfea516e
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2119
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Success return value in DMI functions GetDmiInfoMain(..) and GetType4Type7Info(...) of AGESA vendorcode is "Flag = TRUE".
This results in a failure of init late function:
"agesawrapper_amdinitlate failed: 1"
It happens because TRUE = 1 = AGESA_UNSUPPORTED.
Replacing TRUE with AGESA_SUCCESS (= 0) fixes this problem.
Only family f15tn does not have such bug.
This patch just replaces TRUE with AGESA_SUCCESS, but maybe all DMI functions should be copied from Trinity family?
Tested on Supermicro H8QGI board with 4 AMD Opteron 6234 processors (f15).
Change-Id: I51bf91333c088a825b92d4a44d1ebe4380c8026c
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2070
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Add configuration for AMD's IMC ROM and fan registers for cimx/sb800
platforms.
- Allows user to add the IMC rom to the build and to configure the
location of the "signature" between the allowed positions.
- Allows for no fan control, manual setup of SB800 Fan registers, or
setup of the IMC fan configuration registers.
- Register configuration is done through devicetree.cb. No files need
to be added for new platform configuration.
- Initial setup is for Persimmon, but may be extended to any cimx/sb800
platform.
Change-Id: Ib06408d794988cbb29eed6adbeeadea8b2629bae
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1977
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Marc Jones <marcj303@gmail.com>
- Add mainboard_smi.c from arch/x86/Makefile if it's there
- Add mainboard's chromeos.c from the chromeos Makefile
Change-Id: I3f80e2cb368f88d2a38036895a19f3576dd9553b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1835
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This prepares the way for vboot to inform coreboot when it needs the VGA
Option ROM loaded. Coreboot can't always know when it's needed (with
keyboard-based dev-mode, coreboot can't tell if we're in dev-mode or not).
By the time we get to U-Boot, it's too late, so we need two extra bits - one
for vboot to tell coreboot to load the Option ROM and another for coreboot
to let vboot know it's been done.
This change sets up the communication, but doesn't act on it just yet.
Even with this CL we always load the VGA Option ROM, so there's nothing to
test. There should be no user-visible change.
Change-Id: Ic4e9673a3707b6605064f4879bb3e74d4412322f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: http://review.coreboot.org/1822
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The MRC cache code, as implemented, in some cases uses configuration
settings for MRC cache region, and in some cases - the values read
from FMAP. These do not necessarily match, the code should use FMAP
across the board.
This change also refactors mrccache.c to limit number of iterations
through the cache area and number of fmap area searches.
Change-Id: Idb9cb70ead4baa3601aa244afc326d5be0d06446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1788
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The RO_FMAP base moved from 0x5f0000 to 0x610000.
Also update Kconfig default and add a descripton so
the default can be changed by boards.
Change-Id: I0caad0ce6e6f19750dbbf042a5a489b558f62b96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1705
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Now that we have FMAP support in coreboot use it to find the
offset in flash for ELOG to use.
If coreboot has elog configured with a smaller size then use
that over the FMAP size. This is because I set aside a 16KB
region in the FMAP but we only use 4KB of it to keep the impact
to boot/resume speed to a minimum.
FMAP: Found "FMAP" version 1.0 at ffe10000.
FMAP: base = 0 size = 800000 #areas = 32
FMAP: area RW_ELOG found
FMAP: offset: 3f0000
FMAP: size: 16384 bytes
FMAP: No valid base address, using 0xff800000
ELOG: base=0x003f0000 base_ptr=0xffbf0000
ELOG: MEM @0x00190ad8 FLASH @0xffbf0000
ELOG: areas are 4096 bytes, full threshold 3072, shrink size 1024
Change-Id: I3d826812c0f259d61f41b42797c58dd179f9f1c8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1706
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Until now, the MRC cache position and size was hard coded in Kconfig.
However, on ChromeOS devices, it should be determined by reading the
FMAP.
This patch provides a minimalistic FMAP parser (libflashmap was too
complex and OS centered) to allow reading the in-ROM flash map and
look for sections.
This will also be needed on some partner devices where coreboot will
have to find the VPD in order to set up the device's mac address
correctly.
The MRC cache implementation demonstrates how to use the FMAP parser.
Change-Id: I34964b72587443a6ca4f27407d778af8728565f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1701
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Current ExecuteFinalHltInstruction function doesn't work well.
(at least in configuration
Supermicro board with Orochi AMD Opteron processors (model OS6234WKTCGGU))
System reboots when trying to halt core 2,4,6,8 or 10
(OS6234WKTCGGU is 12 core processor)
Based on this information, i think that code doesn't really work with
f15 compute unit (CU) system.
Replacing ExecuteFinalHltInstruction function with
analogous function from f15tn family code fix this problem.
Both functions written from the same cahalt.asm file, but f15tn version
seems more completed
Change-Id: I3942abcdf21f1b86a44c01cc477714e44a40b9cf
Signed-off-by: Kostr <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/1569
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
src/vendorcode/amd/agesa/f15/Porting.h has some conflicted typedef with
src/include/cpu/amd/common/cbtypes.h. These conflicted defines can lead to errors.
Change-Id: Idad0794018bf0bd0e4e52a5aa062a12766d56c8e
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1592
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Something about HD audio was scrubbed. Take it back.
Change-Id: I0be96fd103f3ebd4e8c7ef09a184b71aa34ee3fd
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1427
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Recent changes in EC/Vboot/U-boot have completely broken
the logging of developer and recovery modes.
Recovery mode may not be in VBNV, so if that is zero and
yet we are in recovery mode then assume it is there because
the button/key was pressed.
Since there may not be any actual developer mode switch
we look if option rom is loaded and the system is not
in recovery mode and consider that as developer mode.
Change-Id: I70104877b24de477217e1ff5b3a019aef22343ec
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If a Chrome OS device is in developer mode log an event.
When the device is in recovery mode also log an event
and provide the recovery reason.
Enable developer mode and trigger recovery mode and
verify that the events are logged:
238 | 2012-06-23 17:31:56 | Chrome OS Developer Mode
239 | 2012-06-23 17:31:56 | Chrome OS Recovery Mode | User Requested from Developer Screen
Change-Id: I14d41f44e04fd91340569617c7314da7e35a154f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1321
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The default return value should be AGESA_SUCCESS, which is zero. If it was set as TRUE,
the AGESA wrapper would think it was AGESA_UNSUPPORTED. That would make no sense. And it
would produce ASSERT warning in AGESA wrapper.
On my parmer board, with Engine sample processor, it can not create the correct DMI table.
Routine initlate will return AGESS_ERROR.
------Serial message---------
ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 427
DmiTable:100123c3, AcpiPstatein: 10010126, AcpiSrat:0,AcpiSlit:0, Mce:100111ba, Cmc:1001127c,Alib:1001ccd4, AcpiIvrs:0 in agesawrapper_amdinitlate
agesawrapper_amdinitlate failed: 5
-----------------------------
I believe the processor with acceptable name string will create the right DMI.
Change-Id: Ie86955cf9affffc964a7c9f4a2c63077ef2030de
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1350
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
coreboot used to pass some information to u-boot in the coreboot table
and other information in a modified flat device tree. Since the FDT code
was never upstreamed and removed from our tree, u-boot was changed to
get the information it needs from the coreboot table alone. However,
in the process of this change only the vboot shared data structure was
passed on by coreboot, so when u-boot tried to update the ChromeOS
specific ACPI entries, it would accidently overwrite the vboot data.
This patch passes on the ChromeOS specific ACPI data structure instead
of the vboot shared data. Another change to u-boot will teach it how
to get to the vboot shared data from there.
Change-Id: Ifbb64eafc0d9967887b4cdeebf97d0c4ce019290
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1282
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The only difference in this code on all our platforms is the array
describing the GPIOs. Hence, only keep that array in the mainboard
ChromeOS directory and move everything else to generic ChromeOS ACPI
code.
Change-Id: I9fc75842af64530c1255bea1c5f803c5316d6da6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1278
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Originally, on ChromeBooks, coreboot would provide a modified
u-boot device tree (FDT) to u-boot in CBMEM. However, u-boot
can now create all the information it needs from the coreboot
table and add it to its device tree itself. This means we can
drop this (anyways unused) code.
Change-Id: I4ab20bbb8525e7349b18764aa202bbe81958d06a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1052
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Remove all the repeated sections of code in cbtypes.h and place it
in a common location. Add include dir in vendor code's Makefile.
Change-Id: Ida92c2a7a88e9520b84b0dcbbf37cd5c9f63f798
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/912
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
For legacy free AMD systems, the #define LEGACY_FREE cannot
currently be overridden. This patch allows the platform_cfg.h
to override that. (I know we want to get away from that, but
for now...)
Also allow BIOS_SIZE to be overridden on SB700 cimx based
platforms.
Change-Id: I570115248bcbc686062bfb66acb56208240b847a
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1018
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Change source file modes from 755 to 644
The following files have been grepped for changes:
*.c
*.h
*Kconfig*
*Makefile*
Change-Id: I275f42ac7c4df894380d0492bca65c16a057376c
Signed-off-by: Alec Ari <neotheuser@ymail.com>
Reviewed-on: http://review.coreboot.org/1023
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
string.h is required to build with the reference toolchain.
Change-Id: I9fd8d2ea8fc676d3502989cbcc7aefe3b2d738b6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/935
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change the ExecuteFinalHltInstruction to assembly code. so we can make
sure the code can run stackless.
Change-Id: I783ced6cf7c5bc29c12a37aef29077e610d8957d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Zheng Bao