Add support for 100MHz reference clock on ivybridge.
Allows to use more frequencies than sandybridge.
Tested on Lenovo T430 (Intel IvyBridge) on DDR3-1800.
Change-Id: I780d34ded2c1e3737ae1af685c8c2da832842e7c
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17607
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Use Ivy Bridge specific magic values on Ivy Bridge instead
of Sandy Bridge values.
The values are extracted from MRC.bin.
Should increase raminit stability.
Tested on Lenovo T430 (Intel IvyBridge).
Change-Id: I49fdfe5ae3e65704d22e083e8446e3f1069869bc
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17606
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Update ABUILD_VERSION for the timeless & checksum parameters.
Change-Id: I96b4c027ccf3e5563dbf4598a0d1fb5e83a5985a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/19034
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Add --checksum command line parameter to specify a base path and
filename for the checksums to be saved into.
- Save checksums of each platform into the specified file appended
with "_platform"
- Save a sha256 checksum of the sorted config.h into the base file
appended with "_config"
Change-Id: Id24dc4b10afbd35cdb8750f75b934419e6e80290
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/19033
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Remove document history. Since the document is now stored in git,
this is no longer needed.
- Fix spacing for the kconfig_lint help output
- Add license information to the bottom of the document.
Change-Id: I9854602a6ad9b4a99bf3988e1d7662b3b426e608
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/19075
Tested-by: build bot (Jenkins)
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This mainboard uses a LVDS connection for LCD panels. Apollo Lake SoC
provides a display controller with three independent pipes (1x eDP and
2x DP/HDMI). PTN3460 is an embedded DisplayPort to LVDS bridge device
that enables connectivity between an eDP source and LVDS display panel
(http://www.nxp.com/documents/data_sheet/PTN3460.pdf).
The bridge contains an On-chip Extended Display Identification Data
(EDIT) emulation for EDIT data structures.
This patch sets up PTN3460 to be used with the appropriate LCD panel.
Change-Id: Ib8fa79bb608f1842f26c1af3d7bf4bb0513fa94d
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/19043
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This was guarded because AGESA.h only defined it starting from fam15
header files. We can simply test if it has been defined.
The way coreboot currently handles this request, is to make the
allocation outside the heap, since heap may not be in CBMEM and thus
not available runtime. The acquired buffer from Allocate() would not
be found with Locate() or Deallocate(), so move the alloc_cbmem()
call for better code symmetry.
Change-Id: Ibf0066913a0b73e768488c3afbeb70139a3961eb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19039
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Once we do CAR teardown between AmdInitResume() and
AmdS3LateRestore() we attempt to find our heap from the
temporary memory buffer instead of cache.
S3 resume is essentially broken anyways and this is not yet a
proper fix at all, but barely keeps system from halting on S3
resume.
Offset that seems arbitrary was taken from hudson/agesawrapper.c.
Change-Id: Idddf2ecde5a9d32d532071d6ba05032be730460c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19038
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Producer and consumer of these buffers now appear in same file.
Also add test for uninitialized NonVolatileStorage in SPI.
Change-Id: Ibbf6581a0bf1d4bffda870fc055721627b538b92
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19037
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
- Add some variables to allow server customizations.
- Verify that coreboot images and containers exist before trying to
remove them.
- Add a couple of convenience targets: clean & cleanall to remove
coreboot containers and images or ALL containers and images.
- Add docker-what-jenkins-does target to run a test build locally inside
a docker image.
- Add docker-jenkins-server target to test the server configuration and
run the jenkins docker image.
- Add docker-jenkins-shell and docker-shell targets to run the
coreboot-sdk and coreboot-jenkins-server images.
- Update the help.
Change-Id: I1896f33e7eddfe3248f44ae780de65ce50d5dd99
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/18004
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
pci_me_interface_scan was returning (via argument 'name') a pointer
to the interface name which was stored in a stack variable. This
caused part of the name to be printed as garbage stack data in some
situations if stack data was overwritten.
This moves the name buffer to the calling function so it can be accessed
before it gets overwritten.
Change-Id: I947a4c794ee37fe87e035593eaabcaf963b9875e
Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Reviewed-on: https://review.coreboot.org/19066
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
This save/restore facility operates on the same datablock.
Change-Id: I6e1f176adc2addbf2659c724f94c1b8d46d4838f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19026
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Only guard the parts that are problematic for romstage.
Also intention is to move AMD_S3LATE_RESTORE to ramstage in followup
work, it will need OemS3LateRestore.
Change-Id: Ie9c1fb3f3f0ab1951771ed829d4acdd8a59d8fbf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19025
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Specification says to do CAR teardown as part of AmdInitPost().
Move initializing the final AGESA heap storage to AmdInitEnv()
so the buffer is not invalidated without writeback.
Change-Id: I3a5d497d0e25ec291f722e9f089bc8928238c3f9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19024
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Logging makes it easier to track order of events as these
call-sites are scattered on various files.
Change-Id: I428547051fd8bf487e91415dc72ee03dba13029e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/18718
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The tis.c module is needlessly copying data to/from a 1260 byte
buffer on the stack. Each device's transport implementation (cr50.c
or tpm.c) maintains its own buffer, if needed, for framing purposes.
Therefore, remove the duplicated buffer.
BUG=b:36598499
Change-Id: I478fb57cb65509b5d74bdd871f1a231f8080bc2f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19061
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
The spi tis_sendrecv() implementation was always returning success
for all transactions. Correct this by returning -1 on error when
tpm2_process_command() returns 0 since that's its current failure
return code.
BUG=b:36598499
Change-Id: I8bfb5a09198ae4c293330e770271773a185d5061
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19058
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
The tpm_info object is a global, but its symbol does not need to
be exposed to the world as its only used within tpm.c.
BUG=b:36598499
Change-Id: Idded3dad8d0d1c3535bddfb359009210d3439703
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19057
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
In the case of start_transaction() failing the chip select is never
deasserted. Correct that by deasserting the chip select when
start_transaction() fails.
BUG=b:36598499
Change-Id: I2c5200085eb357259edab39c1a0fa7b1d81ba7b2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19056
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently only 256 bytes can be written at a time using the
acpigen_write_return_byte_buffer or acpigen_write_byte_buffer API's
and there can be cases where the buffer size can exceed this, hence
increase the number of bytes that can be written.
Change-Id: Ifaf508ae1d5c0eb2629ca112224bfeae1c644e58
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Sowmya V <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/18966
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With COREBOOT_BUILD_DIR set, nvramcui & coreinfo were getting built
in the wrong location, causing those builds to fail.
Also, because they were built in the wrong location, the build failures
were not detected by jenkins which was looking for the junit.xml files
under the payloads directory.
Change-Id: I9d81ebabebe5d8b5f79ae63f8a5f388430e06754
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/19069
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
There's a missing closing brace in fillbits function of jpeg.c which
caused an avalanche of compilation errors.
This was introduced in commit
491c5b60 (src/lib: Move assignment out of if condition)
which was reviewed in gerrit at https://review.coreboot.org/18761 and it
prevents coreboot from building when CONFIG_BOOTSPLASH is set.
Change-Id: Ie10b774875fc25ce2ff613c542c15870e780a761
Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Reviewed-on: https://review.coreboot.org/19032
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Adjust gpio settings according to the hardware layout.
Change-Id: I2f440e863c2e6f59298c500ac5aefa3b7386bcdf
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/18995
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Wake On Voice stream capture configuration is mono. It is sufficient
to keep DMIC_CLK_A1 on in S0ix; so, turning off DMIC_CLK_B1.
Power saving should be visible in the boards which has more
than one DMIC connected.
BUG=None
BRANCH=None
TEST=WoV and quad channel DMIC capture works
Change-Id: Ic46d4c7b30b945eba47a05d78386f48e4a675a03
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/19018
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Venkateswarlu V Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Tested-by: build bot (Jenkins)
- Fix clean target to pass if output doesn't exist
- Make sure $(RM) is actually defined
Change-Id: Ibcdb0e329084f58b27c3f53213a237d02c922a51
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/18998
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the binaryPI file for the FT4 package and add SMU firmware to
be consumed by fanless OPNs.
Change-Id: I1c9b5ded6b494fac1553cc2ec7756a7a47386ecf
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/18988
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Use the new parameters in amdfwtool to include the additional SMU
firmware into amdfw.rom.
Change-Id: Ib44860780c8d5fb00c47f775a2a83b82ff3e1821
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/19002
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change the current implementation so that multiple PSP directory
structures are not included, saving 448 KB.
AMD created a mechanism so that multiple generations of APUs, in
identical packages, may be supportable in one BIOS image. The PSP
identifies the correct directory table by checking one of two
pointers in the Embedded Firmware structure. Coreboot doesn't
implement this capability, however it has been constructing
amdfw.rom with two identical directory tables and two copies of
each PSP blob.
Tested on Bettong (Merlin Falcon / Carrizo) and Jadeite (Stoney).
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit 11dfc3f621344db66d92b61d72927128ea48685f)
Change-Id: I139f3bfdb319af803fef64e7bd848e95945f41aa
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/18990
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
For systems using Chrome OS, place the amdfw outside of cbfs control.
The firmware must go to a fixed position at an offset of 0x20000 into
the flash device.
Potentially improve by adding a warning or error message for the
condition when sizeof(amdfw) + sizeof(cbfs and metadata) > sizeof(flash).
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit 2d9d631b39d7850576438a5b0979936bd33893e1)
Change-Id: I38029bc03e5db260424cca293b1a7bceea4d0d75
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/18435
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The Stoney Ridge program has OPNs that are considered fanless. These
APUs are strapped to search for unique SMU firmware, indicated by
Type[8]=1 in the directory table entry.
Add new options to amdfwtool and include the blobs in the build with
the appropriate bit set in the Type encoding.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit 8df0d6847c39bb021271983018ac6f448f9ff9da)
Change-Id: I4b80ccf8fd9644f9a9d300e6c67aed9834a2c7a7
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/18991
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with
CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why
this wouldn't work (e.g. x86 CAR migration logic currently always
assumes verstage code to run pre-migration). It would also not really
make sense: the reason we use separate verstages is to decrease
bootblock size (mitigating the boot speed cost of slow boot ROM SPI
drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick,
neither of which would apply to the after-romstage case. It is better to
just forbid that case explicitly and give programmers more guarantees
about what the verstage is (e.g. now the assumption that it runs pre-RAM
is always valid).
Since Kconfig dependencies aren't always guaranteed in the face of
'select' statements, also add some explicit compile-time assertions to
the vboot code. We can simplify some of the loader logic which now no
longer needs to provide for the forbidden case. In addition, also try to
make some of the loader logic more readable by writing it in a more
functional style that allows us to put more assertions about which cases
should be unreachable in there, which will hopefully make it more robust
and fail-fast with future changes (e.g. addition of new stages).
Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18983
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Currently, src/vboot/bootmode.c gets compiled even if vboot is disabled.
It seems that this was only done to support calling certain
developer/recovery mode functions in this case. There is no reason to
compile the whole file for that -- we can just differentiate with a
stub in the header instead, which is what other parts of coreboot
usually do for cases like this.
Change-Id: If83e1b3e0f34f75c2395b4c464651e373724b2e6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18982
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This callback was only required for a single mainboard, and it can
easily be moved to mainboard-specific code. This patch removes it from
the global namespace and isolates it to the Jecht board. (This makes
it easier to separate vboot and chromeos code in a later patch.)
Change-Id: I9cf67a75a052d1c86eda0393b6a9fbbe255fedf8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18981
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The virtualized developer switch was invented five years ago and has
been used on every vboot system ever since. We shouldn't need to specify
it again and again for every new board. This patch flips the Kconfig
logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with
CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to
set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the
latter for Lumpy which seems to have been omitted incorrectly, and hide
it from menuconfig since it's a hardware parameter that shouldn't be
configurable.)
Since almost all our developer switches are virtual, it doesn't make
sense for every board to pass a non-existent or non-functional developer
mode switch in the coreboot tables, so let's get rid of that. It's also
dangerously confusing for many boards to define a get_developer_mode()
function that reads an actual pin (often from a debug header) which will
not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set.
Therefore, this patch removes all those non-functional instances of that
function. In the future, either the board has a physical dev switch and
must define it, or it doesn't and must not.
In a similar sense (and since I'm touching so many board configs
anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC.
Instead, it should just be assumed by default whenever a Chrome EC is
present in the system. This way, it can also still be overridden by
menuconfig.
CQ-DEPEND=CL:459701
Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18980
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
VBOOT_DYNAMIC_WORK_BUFFER and VBOOT_STARTS_IN_ROMSTAGE are equivalent in
practice. We can't have a dynamic work buffer unless we start in/after
romstage, and there'd be no reason to go with a static buffer if we do.
Let's get rid of one extra option and merge the two.
Change-Id: I3f953c8d2a8dcb3f65b07f548184d6dd0eb688fe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18979
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CHIPSET_PROVIDES_VERSTAGE_MAIN_SYMBOL allows the SoC directory to
provide its own main() symbol that can execute code before the generic
verstage code runs. We have now established in other places (e.g. T210
ramstage) a sort of convention that SoCs which need to run code in any
stage before main() should just override stage_entry() instead. This
patch aligns the verstage with that model and gets rid of the extra
Kconfig option. This also removes the need for aliasing between main()
and verstage(). Like other stages the main verstage code is now just in
main() and can be called from stage_entry().
Change-Id: If42c9c4fbab51fbd474e1530023a30b69495d1d6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18978
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Some Chrome OS boards previously didn't have a hardcoded vboot
configuration (e.g. STARTS_IN_BOOTBLOCK/_ROMSTAGE, SEPARATE_VERSTAGE,
etc.) selected from their SoC and mainboard Kconfig files, and instead
relied on the Chrome OS build system to pass in those options
separately. Since there is usually only one "best" vboot configuration
for a certain board and there is often board or SoC code specifically
written with that configuration in mind (e.g. memlayout), these options
should not be adjustable in menuconfig and instead always get selected
by board and SoC Makefiles (as opposed to some external build system).
(Removing MAINBOARD_HAS_CHROMEOS from Urara because vboot support for
Pistachio/MIPS was never finished. Trying to enable even post-romstage
vboot leads to weird compiler errors that I don't want to track down
now. Let's stop pretending this board has working Chrome OS support
because it never did.)
Change-Id: Ibddf413568630f2e5d6e286b9eca6378d7170104
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19022
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The correct way to mock out vboot TPM accesses these days is the
CONFIG_VBOOT_MOCK_SECDATA Kconfig option. There are some remnants of
older TPM-mocking infrastructure in our codebase that are as far as I
can tell inert. Remove them.
Change-Id: I3e00c94b71d53676e6c796e0bec0f3db67c78e34
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18977
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Patrick Rudolph