To gradually consolidate and improve AGESA board romstages,
fork the original CAR setup code as a separate file. It becomes
too messy with preprocessor to attempt make changes within the
same file, and at end of patchset original becomes obsolete.
BUG=none
BRANCH=none
TEST=none
Change-Id: If6b072173e1cefc4f676f0295040ff6debeaeaa3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 77d3c4b690
Original-Change-Id: I256b675b1ab9e13c2bcc956e0d67c6c03e91f2ed
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18620
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/462939
We define AGESA_LEGACY as an implementation of mainboard
that has its romstage main completely under mainboard/
directory. We have learnt from other platforms this approach
has several downsides when it comes to making platform-wide
improvements.
We start by creating per-family romstage.c file, which
boards will gradually take into use by removing the
AGESA_LEGACY Kconfig option we here apply to all of them.
BUG=none
BRANCH=none
TEST=none
Change-Id: I3ff98b2ee71ee55883efe83372494d2181785388
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 967d94d626
Original-Change-Id: Id01931e185a023039a60af16a678de9966db8d65
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/18619
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/462938
This board has a socketed SOIC-8 4 MB flash chip. All the flash
regions are unlocked by default but unfortunately flashrom
doesn't work with the original firmware and the stock UEFI flash
tool refuses to flash the coreboot image (different image ID).
For now, the external programmer seems to be the only option for
the first coreboot flashing.
Tested and working:
* Debian GNU/Linux Stretch (with Linux kernel 4.9, SeaBIOS)
* Microsoft Windows 7 installer with VGA blob (SeaBIOS)
* Internal GPU, both with VGA blob and libgfxinit (VGA and DVI)
* External GPU
* RAM (tested 8 + 8 GB)
* S3
* USB, both the 2.0 and 3.0 ports
* Sata
* Thermal management
* Sound
* LAN
* Bluetooth
* VT-x and VT-d
* me_cleaner
Not working:
* Microsoft Windows 7 installer with libgfxinit
Untested:
* Backside Mini PCI-E port
* DisplayPort and HDMI ports
Issues:
* The USB is always powered, even is S3 and S5 (like in the
original firmware).
* Internal flashing with flashrom doesn't work after resuming
from S3.
* The raminit is unreliable, as the RAM training sometimes fails
and sometimes succeeds, with the same couple of RAMs. Once
a MRC cache has been created, the raminit works fine.
* If an external card is inserted and the option
ONBOARD_VGA_IS_PRIMARY is not enabled, the internal GPU
disappears completely from the PCI bus.
BUG=none
BRANCH=none
TEST=none
Change-Id: I5dfe408289bca6647c228b5e1ca17688723c535a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1bea5b7df2
Original-Change-Id: I76aca2cfc4708c1728ae03ee4f6bc59d976c28a0
Original-Signed-off-by: Nicola Corna <nicola@corna.info>
Original-Reviewed-on: https://review.coreboot.org/18564
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/462937
This chip is similar to the Fintek F71869AD.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ic48309e90c4356e1689797de7d5e5edefe999134
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2fca86f370
Original-Change-Id: Iba3f3dadf2b15071981f52d0b08da7847354bd23
Original-Signed-off-by: Nicola Corna <nicola@corna.info>
Original-Reviewed-on: https://review.coreboot.org/18563
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://chromium-review.googlesource.com/462936
This is a cosmetic change.
BUG=none
BRANCH=none
TEST=none
Change-Id: I4536ce41bad5c02a10d008b52df66819b0910bd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 50db9c99be
Original-Change-Id: Iea4dd97e9d83594447427abd9f844e507b805192
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/18960
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://chromium-review.googlesource.com/462935
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: I48be3be92c154c5c93e7696e39d1d65773fc6c5f
Original-Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Original-Reviewed-on: https://review.coreboot.org/18302
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: e91d170d21
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462015
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: I45230f7a73521d66fdc46a54ee9bde32b3e7eae7
Original-Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Original-Reviewed-on: https://review.coreboot.org/18984
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: 58c3938705
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462014
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: Ibf115ba8ac3238bb9f87cafbfde236cd4f555d11
Original-Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa
Original-Reviewed-on: https://review.coreboot.org/18983
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 73d042bd90
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462013
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: I2a80a26e93c8ca4a2ac66395b9a22ea940e9a79d
Original-Change-Id: If83e1b3e0f34f75c2395b4c464651e373724b2e6
Original-Reviewed-on: https://review.coreboot.org/18982
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 5fc7c2896a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462012
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: Ida287e5b48f4543b9caee1a81c302044bd041edc
Original-Change-Id: I9cf67a75a052d1c86eda0393b6a9fbbe255fedf8
Original-Reviewed-on: https://review.coreboot.org/18981
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: b04cc6b902
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462011
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: I33d6fe4570b6c7e6d120ed43736413ace0016454
Original-Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f
Original-Reviewed-on: https://review.coreboot.org/18980
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: 320edbe2ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462010
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: I1946f68355ea9549f0458615f4c0f7b8929baa39
Original-Change-Id: I3f953c8d2a8dcb3f65b07f548184d6dd0eb688fe
Original-Reviewed-on: https://review.coreboot.org/18979
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: fa8fa7dd54
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462009
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: I505fa91910fc6fda6bd11da709493ada605090ae
Original-Change-Id: If42c9c4fbab51fbd474e1530023a30b69495d1d6
Original-Reviewed-on: https://review.coreboot.org/18978
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 94d9411415
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462008
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: Ie50b79b1bb1acd10ed64332eaa763f0a6cb9ea17
Original-Change-Id: Ibddf413568630f2e5d6e286b9eca6378d7170104
Original-Reviewed-on: https://review.coreboot.org/19022
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: 1210b41283
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462007
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: I62e2c58a2d8796f43690ca3525074caa4977bde1
Original-Change-Id: I3e00c94b71d53676e6c796e0bec0f3db67c78e34
Original-Reviewed-on: https://review.coreboot.org/18977
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Commit-Id: 84b2978ed6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462006
Due to an unfortunate race between adding verstage support and reverting
an earlier hack that disabled the optimized assembly versions of
memcpy(), memmove() and memset() on ARM64, it seems that we never
enabled the optimized code for the verstage. This should be fixed so
that all stages use the same architecture support code.
Change-Id: I97547ed22f6522ba1eaaaf8bb857d57e247fbe34
Original-Change-Id: I0bf3245e346105492030f4b133729c4d11bdb3ff
Original-Reviewed-on: https://review.coreboot.org/18976
Original-Tested-by: build bot (Jenkins)
Original-Commit-Id: 2f891a08e7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/462005
Instead of defining a separate LID device for mainboards using
chromeec, define EC_ENABLE_LID_SWITCH for these boards.
BUG=none
BRANCH=none
TEST=none
Change-Id: I3f68109701dc74fe44f5d35fdbfe44e2bfd1b4e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5029a1668e
Original-Change-Id: Iac58847c2055fa27c19d02b2dbda6813d6dec3ec
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18964
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/459510
Instead of defining SIO_EC_ENABLE_PS2K by default for all boards and
doing an undef in variant/onboard.h, move the definition of
SIO_EC_ENABLE_PS2K to variant/onboard.h. This avoids dependency
between different *.asl files.
BUG=none
BRANCH=none
TEST=none
Change-Id: Id20f7df9985490f42ace4b5dbf03d7c5e8ff84ef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3795b03b69
Original-Change-Id: I83e4ce42a594e952a443c618d7ef9840113027b9
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18965
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/459508
Replace the use of the old device_t definition inside
soc/intel/fsp_baytrail.
BUG=none
BRANCH=none
TEST=none
Change-Id: I208de00fab4cefe1e35b26f2ece16117750de2e4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fb94dcf5d5
Original-Change-Id: I2791346289c04049e6f032c8e120e4be9ba6657f
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/17319
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459507
- Change preprocessor #if to standard C if. This will get optimized
out if the config option is disabled, but lets the compiler check the
contents.
- CONFIG_USBDEBUG is always going to be defined even if it's disabled,
so this check is not going to work as expected.
See the coreboot Kconfig documentation in /Documentation/core/Kconfig.md
BUG=none
BRANCH=none
TEST=none
Change-Id: I57ae98d60f240b92d1e2fd9146c95c2928631db5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5ef5c00704
Original-Change-Id: Ia63438d9525e79307d9229ad3ffa2962978611d8
Original-Signed-off-by: Martin Roth <martinroth@google.com>
Original-Reviewed-on: https://review.coreboot.org/18974
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Philippe Mathieu-Daud <philippe.mathieu.daude@gmail.com>
Original-Tested-by: build bot (Jenkins)
Reviewed-on: https://chromium-review.googlesource.com/459506
Currently the `break` further down is called unconditionally as the
brackets for the body of the if statement are missing. Add those.
BUG=none
BRANCH=none
TEST=none
Change-Id: I738178ea9f4f92fad237cfec23acad6af17995dd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b45bbb253f
Original-Change-Id: I34917a9877dcc882d880dedea689e1d72fe52888
Original-Found-by: Coverity (CID 1372941: Control flow issues (UNREACHABLE))
Original-Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-on: https://review.coreboot.org/18971
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459504
Also move all local variable declaration at starting of function
block.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ie2e4ef0cac7545cb8acc6d3513cbe364065b19bd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c790850ebe
Original-Change-Id: I774485a23b4b7d96a8dbd837da45553251dff3b0
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18949
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/459503
1. Remove CPU throttling effect of the charger sensor
Refers Change-Id I267b6e07fa9def2c91ff9f6035f2d9437faf1965
(mb/google/reef: Remove CPU throttling effect of the charger sensor)
to remove CPU throttling effect of the charger sensor
since it's not relevant to throttle CPU based on the charger sensor.
2. Change TSR1 influence from 200 to 100
3. Change TSR2 sample period from 120s to 30s
BUG=b:35585781
BRANCH=reef
TEST=built, and verified on snappy by thermal team.
Change-Id: Ic0e9b9c76a6cf56b6fc07e483a78f44665f4d949
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ccc21ca685
Original-Change-Id: Ic3fc51c4288b24f4e64950e5b148aed4495a1c3b
Original-Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Original-Reviewed-on: https://review.coreboot.org/18950
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/459501
The upcoming Cr50 firmware changes will require the AP to enable the
previously downloaded Cr50 firmware update(s).
A new vendor command (TPM2_CR50_SUB_CMD_TURN_UPDATE_ON) is used for
that. The command accepts one parameter - a timeout value in range of
0 to 1000 ms.
When processing the command the Cr50 checks if the alternative RO or
RW image(s) need to be enabled, and if so - enables them and returns
to the host the number of enabled headers.
If the vendor command requested a non-zero timeout, the Cr50 starts
a timer to trigger system reboot after the requested timeout expires.
The host acts on the number of enabled headers - if the number is
nonzero, the host prepares the device to be reset and waits for the
Cr50 to reboot the device after timeout expires.
This patch also adds more formal vendor command
marshaling/unmarshaling to make future additions easier.
BRANCH=gru,reef
BUG=b:35580805
TEST=with the actual user of this code in the next patch verified that
the cr50 update is enabled as expected.
Change-Id: I06feba1e778d20fdc70038672d663d6236a3e180
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 021ec2819b
Original-Change-Id: Ic76d384d637c0eeaad206e0a8242cbb8e2b19b37
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18945
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/459670
Creating google/fizz directory based on poppy (using kabylake and FSP
2.0). Only making name changes and Copyright year changes. Many
poppy-specific configs left in and will be updated in follup CLs.
BUG=b:35775024
BRANCH=None
TEST=Compile fizz board
Change-Id: Ic40bb336dabc4bf48213ccd454d29032c5846bc9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 243dc3913d
Original-Change-Id: Icab3639a53fef65e904e797028916fda879fff7c
Original-Signed-off-by: Shelley Chen <shchen@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/18796
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459665
This patch implements SGX initialization steps in coreboot per Intel SGX
BWG rev 2.0.8 for Kaby Lake SoC. If enabled on a Kabylake device, SoC
capability and PRM (processor reserved memory) of desired size (needs to
be configured through PrmrrSize) are provisioned for later software
stack to use SGX (i.e., run SGX enclaves).
One issue is still puzzling and needs to be addressed: by calling
configure_sgx() in cpu_core_init() which is the per-thread function, SGX
is always failing for thread 0 but is successful for other 3 threads.
I had to call configure_sgx() again from soc_init_cpus() which is the
BSP-only function to make it enable on the BSP.
Another pending work is the implementation for the Owner Epoch update
which shall be added later.
BUG=chrome-os-partner:62438
BRANCH=NONE
TEST=Tested on Eve, verified SGX activation is successful on all threads.
Change-Id: I3bca7131d5f51a7bdb913cc6ae135b910d3aa52e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7de031759b
Original-Change-Id: I8b64284875eae061fa8e7a01204d48d320a285a9
Original-Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18445
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/459664
Replace the use of the old device_t definition inside
mainboard/samsung/stumpy.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ibf85e77a6901fab095c06798ea16b6424f4bb776
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9709af3521
Original-Change-Id: Ie6209b3b40d9aad0723690e7aeb3edfd0bfcc4a8
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/17304
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459661
Replace the use of the old device_t definition inside
mainboard/samsung/lumpy.
BUG=none
BRANCH=none
TEST=none
Change-Id: I45bd8786ba4341f123264b2fbed8747447c8d4bf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6b542faf20
Original-Change-Id: I39fe6bad42b3b0772d09d0fa7af357b797b8e04f
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/17303
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459660
Replace the use of the old device_t definition inside
northbridge/via/vx900.
BUG=none
BRANCH=none
TEST=none
Change-Id: Iaf6a189371992a2f6d391802c1bb714d29baf8ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 823f7bb962
Original-Change-Id: I04292a6b698a42a5c582eddcef7cf5a235e1a464
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/17317
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459659
Replace the use of the old device_t definition inside
mainboard/technexion/tim5690.
BUG=none
BRANCH=none
TEST=none
Change-Id: I71904345f76418c71cd37d29f5078e142c1b8678
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a34e70e002
Original-Change-Id: I661daa5ab34c70db8ed783e5bf1114877f13b548
Original-Signed-off-by: Antonello Dettori <dev@dettori.io>
Original-Reviewed-on: https://review.coreboot.org/17307
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/459658
FSP disables host access to shadowed PMC XRAM registers by default,
it also provides a UPD to enable/disable host reads to these regiters.
Expose the same in devicetree as a config option.
BUG=none
BRANCH=none
TEST=none
Change-Id: I1ffd08c2aa4abb52787ae7b8c91cbc734290f6ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffe58107df
Original-Change-Id: Iaa33aa3233bda4f050da37d1d8af0556311c9496
Original-Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Original-Reviewed-on: https://review.coreboot.org/18319
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/458355
It makes no sense to read SPDs if the system will reset anyway.
BUG=none
BRANCH=none
TEST=none
Change-Id: Icc0587de64d04063c9203535a773ec1967604b23
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bb5e77c478
Original-Change-Id: Id2ad9b04860b3e4939a149eef6b619a496179ff8
Original-Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-on: https://review.coreboot.org/17661
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://chromium-review.googlesource.com/458348
Currently, its impossible for the user to select `NO_POST`, for boards
selecting `CONSOLE_POST` in their config.
```
warning: (BOARD_SPECIFIC_OPTIONS) selects CONSOLE_POST which has unmet
direct dependencies (VENDOR_SIEMENS && BOARD_SIEMENS_MC_BDX1 || !NO_POST)
```
This is currently done for Intel Camelback Mountain and Siemens MC-BDX1.
Selecting the option `CONSOLE_POST` in board specific configuration is
not a good idea, as this should be user configurable over Kconfig, and
also the tree-wide defaults should be the same for these options.
Kconfig is different, as commit 97535558f1 (mainboard/{google,intel}:
Change config option selection) only touch the Intel board.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ie93d38b3c82261458534993b856737f9ea5d019c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 98adaf5989
Original-Change-Id: I91c1e0cb92ed218b6bbc7c33759b91f748cf6f51
Original-Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Original-Reviewed-on: https://review.coreboot.org/18878
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://chromium-review.googlesource.com/458346
