fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read
the fmap header first to calcurate the size of the fmap. Then, we read flash
again exactly as much as the discovered fmap.
BUG=none
BRANCH=ToT
TEST=Booted Storm and Peppy. Built all current boards.
Change-Id: Iaa50c1bc3401c77b433af11406d4b9d2e4e722e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 755ff66ab0a4d05e6d5410c11a6badb9fcb77a0d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64
Original-Reviewed-on: https://chromium-review.googlesource.com/231685
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9556
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Before the change to use vb2_api.h, coreboot needed to know where to
find the vboot2 header files. Now those are all included by
vb2_api.h, so coreboot doesn't need to know about
firmware/2lib/include (and in fact, the 2lib directory is about to go
away).
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
Original-Change-Id: I7f69ca9cf8d45c325219efceca0cb8d1340f7736
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233223
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit b4d4a2da1c8b5a5f8f8da51f009227d3a616b096)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I4006f38835ea0f927142a8133bc24caaf2b7a214
Reviewed-on: http://review.coreboot.org/9447
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Original-Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233051
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit df55e0365de8da85844f7e7b057ca5d2a9694a8b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I999af95ccf8c326f2fd2de0f7da50515e02ad904
Reviewed-on: http://review.coreboot.org/9446
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Apparently our initial submission of 16K was a little too generous for
the vboot2 work buffer, and I hear that we should also be well within
bounds for 12K. This patch reduces the minimum asserted by memlayout so
some of our low-mem boards can get a few more kilobytes back for
discretionary spending. Also changes the required minimum alignment to 8
since that's what the current vboot code aligns it to anyway, and add a
warning comment to make it clearer that this is a dangerous number
people should not be playing with lightly.
BRANCH=None
BUG=None
TEST=Built and booted on Pinky.
Original-Change-Id: Iae9c74050500a315c90f5d5517427d755ac1dfea
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232613
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 64e972f10363451cd544fdf8642bd484463703bc)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I362b8c33cf79534bb76bd7acda44d467563fe133
Reviewed-on: http://review.coreboot.org/9445
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
PHYSICAL_REC_SWITCH is set n by default and y for panther and stumpy.
BUG=none
BRANCH=ToT
TEST=Built nyan_blaze using vboot1/2. Built falco, lumpy, nyan,
blaze, parrot, rambi, samus, storm, pinky with default configuration.
panther and stumpy are not tested because they currently don't build on ToT.
Original-Change-Id: Ic45f78708aaa7e485d2ab459fd1948524edb412f
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227940
Original-Reviewed-on: https://chromium-review.googlesource.com/229602
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit edb2ba347b48887ffe450586af0351e384faad59)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I277f665cd4f3e1c21745cdc5c7a2cfe148661abe
Reviewed-on: http://review.coreboot.org/9444
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The architectiure check in fmap.c is in fact used to delineate between
platforms where SPI flash is mapped to memory address space and where
it needs to be accessed through CBFS.
In fact cosmos board uses an ARM SOC which also maps SPI flash to
processor address space, this will have to be addressed when that
SOC's support is introduced, for now let's just presume that all but
X86 platforms require CBFS layer to access fmap.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Original-Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226180
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit b3c04f84504380066c54a6dec93781a4f25a5fc6)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I3a0a70fe583b69b1c9cd8729817bd7062126e1a9
Reviewed-on: http://review.coreboot.org/9436
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch adds functions looking in the VPD for WiFi calibration
data, and if found, copying the calibration blobs into CBMEM.
Two possible key names templates are used: wifi_base64_calibrationX
and wifi_calibrationX, where X is replaced by the WiFi interface
number. Up to four interfaces can be provisioned.
The calibration data will be retrieved from CBMEM by the bootloader
and placed into the device tree before starting the kernel.
The structure of the WiFi calibration data CBMEM entry is defined
locally: it is a concatenation of the blob names and their contents.
Each blob is padded as necessary to make sure that the size divisible
by four.
To make sure that the exactly required amount of memory is allocated
for the CBMEM entry, the function first scans the VPD, caching the
information about the available blobs and calculating their combined
size.
Then the required size CBMEM entry is allocates and the blobs are
copied into it.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=when this function is called, and the VPD includes calibration
data blobs, the WIFI entry shows up in the list of CBMEM entries
reported by coreboot.
Original-Change-Id: Ibe02dc36ff6254e3b9ad0a5bd2696ca29e1b2be3
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225271
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 9fe185ae5fdc1a896bf892b498bff27a3462caeb)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia60f0c5c84decf9854426c4f0cb88f8ccee69046
Reviewed-on: http://review.coreboot.org/9435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Adds option FORCE_AM1_SOCKET_SUPPORT to disable
package type mismatch check between cpu and northbridge.
Default agesa for kabini doesn't know about AM1 socket
so it returns FALSE, that stops memory config code.
With this hack current agesa version supports the AM1 socket.
Change-Id: I99e9cec5cd558087092cf195094df20489f6d3b5
Signed-off-by: Sergej Ivanov <getinaks@gmail.com>
Reviewed-on: http://review.coreboot.org/9291
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
The new API allows to find VPD objects in the VPD cache. There is no
need for the caller to allocate or free the per object memory.
The existing API (cros_vpd_gets) now uses the new function as well.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that MAC addresses still show up in the device tree on
the booted storm device
Change-Id: Id06be315981cdaa2285fc1ec61b96b62b1178a4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 99a34344448a5521cee8ad3918aefb1fde28417d
Original-Change-Id: I6c0b11bb844d6235930124d642da632319142d88
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225258
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/9403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Retrieval of the MAC address from the VPD is a Chrome OS specific
feature, required just on one platform so far. There is no need to
look for the MAC address in the VPD on all other Chrome OS boards.
BRANCH=storm
BUG=chromium:417117
TEST=with the upcoming patch applied verified that MAC addresses still
show up in the device tree on storm
Change-Id: If5fd4895bffc758563df7d21f38995f0c8594330
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fb4906ac559634321a01b4814f338611b9e98b2b
Original-Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223796
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9398
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache
right now, your system will try and fail to validate the FMAP signature
at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the
memcmp() to potentially invalid memory, and also adds an error message
to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS
cache space.
BUG=None
TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message.
Original-Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222899
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 0ed3c0c2b63be0d32e8162faf892e41cef1f1f23)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I20ccac83bff4a377caca6327d0e21032efff44c1
Reviewed-on: http://review.coreboot.org/9373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provide finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42
Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219172
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9304
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Drop the inner underscore for consistency. Follows the
commit stated below.
Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-on: http://review.coreboot.org/9290
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
this adds a driver for vboot to read and write nvdata in spi flash.
it's assumed that flash contents are erased to 1-bits and write
operations can only change 1-bits to 0-bits.
when all nvram space is used, the driver will erase the whole block
and start the next write from the beginning.
BUG=chrome-os-partner:32774
BRANCH=ToT
TEST=Built for cosmos.
Change-Id: I40858f847151aa0770e1101e905476d270550f60
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 09713828b7b0cabd13a08de3f34e32bc4dbef4a4
Original-Change-Id: Ia9049f342b21fa4c289cb7b9254ab89ec1ef1699
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226525
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9229
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Introduce generic-$(type)-ccopts and $(class)-generic-ccopts
to declare compiler flags that apply to all files of a certain
type or of a certain class. Then use them.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I655688e82a0cc5bad89b6f55dc217b9f66b64604
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9114
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I5405c0ee6bee203281e723feaecaee57fad8f6cb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Includes moved into $(CPPFLAGS_*), so add that to VBOOT_CFLAGS.
Shift vboot build parameters from the environment to be make parameters,
and use $(MAKE) instead of make to fix non-Linux build systems.
Change-Id: I5aee9935ab36ad571fbcf9f6fa8d8ace2bac16b3
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8703
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
In order to display a "update in progress" screen on devices with
a slow EC or PD chip it may be necessary to also load the VGA
Option ROM when doing EC software sync.
This adds config options for VBOOT_EC_SLOW_UPDATE which simply sets
a flag in the input parameters that is already handled by vboot.
It also adds a config option for VBOOT_OPROM_MATTERS which is a bit
more tricky in that it sets a flag in input parameters, but also
needs to keep track of the option rom being loaded and pass that
flag into VbInit as well.
Since VbInit will clear the NV bit for option rom loaded the check
that is done in vboot_wants_oprom() needs to first compare against
the vboot handoff copy of the input flags.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Original-Change-Id: Ic2b34bf9e7c6cc5498413fa1b8dff6e6207c9d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223831
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 7d7aa89238efb5081885f9386c8e872fc96f573f)
Change-Id: Ib7fb24e6e80e1f7e836bc62246ab9b3e056fd73d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
this change makes coreboot initialize kernel space and backup space in the tpm
when no firmware space is found in the tpm.
BUG=chrome-os-partner:32410
TEST=Forced factory initialization and verified it went through without errors.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I777e3cb7004870c769163827543c83665d3732b9
Original-Reviewed-on: https://chromium-review.googlesource.com/220412
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit d8c0c407bf0fed60d76441ada7bedd36f6fc3a38)
Change-Id: Icc3779125262b4499e47781991ebbf584abf074a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change makes prevent execution from falling through to unverified
code when hard_reset is not implemented. it also includes a few touch-ups.
BUG=None
TEST=Booted Veyron Pinky. Verified firmware selection in the log.
BRANCH=None
Original-Change-Id: I9b02ab766172a62c98b434c29f310bc4a44f342d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219625
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit d1f5207d83d2247b55f2bb9d02ac843305fc3ded)
Change-Id: I99dd5a2ca3a5369accb14408ea9d266bf60e7132
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Original-Reviewed-on: https://chromium-review.googlesource.com/212365
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Note: This purposefully is probably broken in vendorcode/google/chromeos
as I'm just trying to set a base for dropping more patches in. The vboot
paths will have to change from how they are currently constructed.
(cherry picked from commit 4fa17395113d86445660091413ecb005485f8014)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9117434ce99695f9b7021a06196d864f180df5c9
Reviewed-on: http://review.coreboot.org/8881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change reduces the code duplication of the bootblock and the romstages for
Nyans.
BUG=none
TEST=Built Nyan, Big, and Blaze. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: dnojiri@chromium.org (Daisuke Nojiri)
Original-Change-Id: Ieb9dac3b061a2cf46c63afb2f31eb67ab391ea1a
Original-Reviewed-on: https://chromium-review.googlesource.com/214050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit f3413d39458f03895fe4963a41285f71d81bcf5f)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I912f63b12321aa26a7add302fc8a6c4e607330ef
Reviewed-on: http://review.coreboot.org/8880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This introduces a new kconfig variable to select the VBNV backing
store explicitly instead of inferring it from CPU/SoC architecture.
x86 platforms have historically relied only on CMOS to store VBNV
variables, while ARM-based platforms have traditionally relied on
the EC. Neither of those solutions are going to scale well into
the future if/when CMOS disappears and we make ARM-based systems
without an EC.
BUG=chrome-os-partner:29546
BRANCH=none
TEST=compiled for nyan_blaze and samus
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I4a8dadfb6bb666baf1ed4bec98b29c145dc4a1e7
Original-Reviewed-on: https://chromium-review.googlesource.com/213877
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit d088fc71b2e2b45e826d3dedb8e536ad58b8d296)
Change-Id: Iea325a8c4d07055143e993d89b827f86b8312330
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
rmodules ccopts contain information about specific arch like armv4,v7. Hence, it
is important to include them in VBOOT_CFLAGS
BUG=None
BRANCH=None
TEST=Compiles correctly for armv4 in rush
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id:
Original-Change-Id: I8f5509f753e28046678c3782d6f0b6210559f798
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209979
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit ca9f2f86ff1bc445abf5f97f61c04b6eccbd3e25)
Change-Id: I6cd7c47f33cf897d8ee96e7154222b3bfbe5221f
Reviewed-on: http://review.coreboot.org/8775
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to more cleanly apply upcoming changes some files
will need to do a dance.
Change-Id: Ib50670743c10221785447490190ecdbff8c764fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8654
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203033
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I44dacc10214351992b775aca52d6b776a74ee922
Reviewed-on: http://review.coreboot.org/8055
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
If devicetree.cb has GPP port off, really disable it before even
trying to do link training.
Change-Id: I810945da28d86768e88249dc4d29a50ad9f9959b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8385
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Rangeley POST-GOLD 2 FSP added PCIe ports de-emphasis configuration
by UPD input. Update UPD_DATA_REGION structure for matching up this
FSP change.
PcdCustomerRevision is a debugging aid that will be output to debug
message in FSP. When needed, it can be customized by BCT tool for tracking
BCT configurations.
Change-Id: I6d4138c9d8bbb9c89f24c77f976dbc760d626a9b
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/8107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
To maintain consistancy with southbridge/amd/agesa/hudson rename
pi/avalon to pi/hudson in advance of adding support for the
base hudson southbridge.
Change-Id: Icff8c4c06aae2d40cbd9e90903754735ac3510c3
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8251
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
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.
This fix changes the makefile so that 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 now has a mandatory structure that places the AGESA
BLOB into the same directory as the support headers. These will
nominally be placed in the amd directory in SageBIOS or the
3rdparty directory in coreboot.org.
Change-Id: I56788cd197159939b64c7d16c1d32418f8cc2197
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/5967
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
vboot2 abtracts tpm storage as some 'secure' space. Thus, it's firmware's
responsibility to handle vboot specific operations with tpm. This CL just copies
related files from vboot_reference so that we can see how code was modified in
the next CL. Note rollback_index.c/h were renamed to antirollback.c/h.
TEST=none
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I1792a622058f70a8fcd3c4037547539ad2870420
Original-Reviewed-on: https://chromium-review.googlesource.com/206462
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2ae188b29242bf09c5e79e31f98b330a30bf7b93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5fa5a636003e8472127194e961fea4309489b1d9
Reviewed-on: http://review.coreboot.org/8164
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Doing reset while VBERROR_TPM_REBOOT_REQUIRED occured.
BUG=chromium:389568
TEST=Manual force VBERROR_TPM_REBOOT_REQUIRED returned from VbInit()
and system will reboot.
Original-Change-Id: I9d7c4b3a380a931a728f792b4013b3b9bf65dfae
Original-Signed-off-by: Kevin Cheng <kevin.cheng@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/206337
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 32728dd9fc43a95d6f763a85f9cc7a660a66b175)
Original-Reviewed-on: https://chromium-review.googlesource.com/206948
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 1ea5e233386d236ce20f3d1695fac3a1bc49d4bd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib93fdf7b22918f563d3e29207a75fc831bee186a
Reviewed-on: http://review.coreboot.org/8163
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Original-Reviewed-on: https://chromium-review.googlesource.com/204522
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit a6bce0cbed34def60386f3d9aece59e739740c58)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I63ddfbf463c8a83120828ec8ab994f8146f90001
Reviewed-on: http://review.coreboot.org/8160
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This reverts the revert commit 5780d6f387
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit 320647abda, because it
introduced the following regression.
$ LANG=C make V=1
Warning: no suitable GCC for arm.
Warning: no suitable GCC for aarch64.
Warning: no suitable GCC for riscv.
/bin/sh: --: invalid option
Usage: /bin/sh [GNU long option] [option] ...
/bin/sh [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
make: -print-libgcc-file-name: Command not found
It also introduced trailing whitespace.
Change-Id: I50ec00a38e24c854fa926357cd24f9286bf4f66f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8223
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains, compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I42b2b3854a24ef6cda2316eb741ca379f41516e0
Reviewed-on: http://review.coreboot.org/8159
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
When included for the CAR transition, this was causing the error:
error: invalid storage class for function 'DebugDeadLoop'
Change-Id: Idf37a8104b4468b40c29c8cbe9a40f7a357a4f17
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8193
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This adds a generic helper function for adding boot reason in the
ChromeOS case. If vboot is enabled, it will use information passed
in via the vboot handoff table in cbmem to determine mode and
reason in the case of recovery.
BUG=chromium:373467
BRANCH=nyan
TEST=built along with follow-up CL and booted on Big under various
modes, verified entry was added to eventlog with "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I50a7aa6d55eb46413fe9929e732d6eb18c758d4b
Original-Reviewed-on: https://chromium-review.googlesource.com/199690
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 961c0bd1dd5512b1c2feb2ed4391bf507900eb7a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6ae4e2a891966d2d1de7d37dcc551383e94e4d75
Reviewed-on: http://review.coreboot.org/7991
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add the empty weak function clear_recovery_mode_switch().
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set, turning the
device off and on again with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Original-Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Original-Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197780
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Sheng-liang Song <ssl@google.com>
Original-Tested-by: Sheng-liang Song <ssl@google.com>
(cherry picked from commit 18908bb64cef34ca41812814817ef887961bed34)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I71ca9f3ea8d816c865375ec66a0603ca211f23ae
Reviewed-on: http://review.coreboot.org/7895
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Length arguments for VbExTpmSendReceive have type uint32_t but it calls function
which expects size_t. This change converts uint32_t to size_t on call and
size_t to uint32_t on return.
BUG=None
BRANCH=None
TEST=Booted Nyan Big to Linux
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I1971488baae2d060c0cddec7749461c91602a4f9
Original-Reviewed-on: https://chromium-review.googlesource.com/198016
(cherry picked from commit 6830747eb47568f2a2b494624522d37d8945c030)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I20741759e7bbd60dd7044c532287d6b55047e19a
Reviewed-on: http://review.coreboot.org/7894
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
If the kernel does not properly handle the TPM and send it a
TPM_SaveState command before suspend then it will not be in
the correct state on resume. In order to easily detect this
case add a new post code for TPM failure and use it in the
vboot resume path.
BUG=chromium:371105
TEST=Build and boot on wtm2.
Original-Change-Id: I412520b521387a8e18ad1c6f5a64b39cdd5c88ec
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199371
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit ff2f0dc56c1a783295710f81567af02729fe1da2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5baf894fd72922acd79d191e5485ae8ef7e0d559
Reviewed-on: http://review.coreboot.org/7936
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
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>
Daisuke Nojiri