So, this is odd in multiple ways. First of all, we fix something:
We work around a weirdness in `make oldconfig` that adds spurious
entries into the `auto.conf` for choices that were given a symbol
name.
When introducing the Ada config package, it seemed reasonable to
use `auto.conf` as source, but it turned out that we didn't use it
as input, only `config.h` and the original `.config` were used. As
the syntax for `.config` is the same as for `auto.conf` we use the
former now as input for Ada, too. One question remains: If `.config`
already contains all required information, what is this `auto.conf`
and what does it want?
Alternatively, we could try to fix `oldconfig` or add a linter to
forbid named choices. I thought, our build test would reject the
latter already. But the `oldconfig` behaviour is too subtle.
We keep a dependency on the `oldconfig` step, to make sure it runs
first.
Change-Id: If3fe6bc782251cdbd696395d3069a1c0bb0ae802
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36320
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
New changes in the latest binutils 2.32 lead to assembler errors causes
ipxe build failure. IPXE uses the divide test which requires /dev/null as
input as well as the output file name.
This patch facilitates the /dev/null as an exception to the current
changes in binutils package while building crossgcc for coreboot leads to
successful build of ipxe and further tests to pass based on /dev/null and
applies automatically during the crossgcc rebuild.
Also, this can be reverted once binutils/ipxe provides an updated release
in this respect.
Fixes: https://ticket.coreboot.org/issues/204
Change-Id: I9f664829b8c42420c0b2ab1f2316150f86ac0b1a
Signed-off-by: Himanshu Sahdev <himanshusah@hcl.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35098
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since there are no calls where we wouldn't die(), move die() calls into
the fsp_find_* functions.
Change-Id: I750a225999688137421bbc560d9d1f5fdf68fd01
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Remove the calculation of the Reserved Intel MMIO Memory size from
systemagent and memmap, since it is not needed.
The size is used in SA to calculate the space between cbmem_top and TSEG
without DPR and Chipset Reserved Memory. Since this will always be equal
to 0, the reservation will be skipped and TSEG, DPR and Chipset Reserved
Memory will get reserved alltogether.
By reading the code and pratical testing we figured out that:
- TSEG - DPR - reserved - top_of_memory == 0
- TSEG - DPR - reserved == top_of_memory
This means the whole block will never reserve anything because it is
always 0. Hence the code can be removed for simplification.
Tested successfully on X11SSM-F
Change-Id: I0cc730551eb3a79c78a971b40056de8d029f4b82
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Follow-up commit where only files are moved and paths adapted to make
review of the previous commit easier.
Change-Id: Iff1acbd286c2ba8e6613e866d4e2f893562e8973
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35868
Reviewed-by: Michael Niewöhner
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove orphaned functionality from the FSP1.1 driver that only has been
used by skylake, which is now FSP2.0-only.
Change-Id: I732f2d6846788d5c03647c6fb620e45b3b66de5f
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36266
Reviewed-by: Michael Niewöhner
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This drops support for FSP 1.1 in soc/intel/skylake, after all boards
have been migrated to FSP 2.0, which is backwards compatible.
Any moving of files happens in a follow-up commit to make review easier.
Change-Id: I0dd2eab0edfda0545ff94c3908b8574d5ad830bd
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35813
Reviewed-by: Michael Niewöhner
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch is part of the patch series to drop support for FSP 1.1 in
soc/intel/skylake.
The following modifications have been done to migrate the board(s) from
FSP 1.1 to FSP 2.0:
- remove deprecated devicetree VR_RING domain (only 4 domains in FSP 2.0)
TODO:
- testing
Change-Id: I7481f3413de6780df01d9b769bd4f16d439f087c
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35923
Reviewed-by: Michael Niewöhner
Reviewed-by: Wim Vervoorn
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: Ic2f0944b92dcad7048a0c38720d2ef3c855ef007
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
- This port should be Reclaim Your Freedom compliant
(not certified yet).
- Untested on boards with external Radeon graphics adapter.
- Some columns on the left-most side of display are completely
black on 1400x1050 IPS display[1]. Display works fine on Linux.
I don't know why it appears like that. So far it has been observed
only with native graphics initialization.
- Only GRUB2 and SeaBIOS payloads tested for now.
- 2504 docking station USB doesn't work under Linux.
Can detect pendrive in GRUB2 payload.
- Sometimes it takes 20s of "pretending it's powered off" to run
coreboot code. Issue is payload agnostic.
Probably caused by missing one capacitor on my unit.
[1] https://imgur.com/a/0wpMGsm
Change-Id: Ibd9208a5eafd228f8eedbc8fb4f4eb9ed1932a14
Signed-off-by: Maciej Matuszczyk <maccraft123mc@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Change-Id: I09fce1298794f30c1db699438204ac32ee9cb27d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36296
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Change-Id: I50cafce0aaf465ee95562ccff6c8f63fb22096c0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Change-Id: If3ee38f3eaa8e6d1c1b0393d0ba289f708e0ae5e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36293
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
An io_trap_handler on this board is unused in SMM.
Change-Id: Ie922f8f1a10495ae887221735c96807261508041
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
These mainboard_io_trap_handler functions do nothing compared to a weak
mainboard_io_trap_handler in src/cpu/x86/smm/.
Change-Id: I73ebcc6c3f604a075a946503d51881ccc6820dac
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Remove SMM reinitialization since it's already done in src/ec/lenovo/h8.
Untested on a real hardware.
See also commit 8953d4a1 with Change-Id
I33fd829a7e34aefa8f76ca6020cc8e802f7aab17 ("mb/lenovo/*/smihandler: Get
rid of mainboard_io_trap_handler").
Change-Id: Icc582527db15f3a31cdee8948bc5a190240fdc84
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
I does nothing on these boards. It's just a call a local noop function
which only prints a debug-level message.
Change-Id: Id3fb2e9074db72d9025b95f7d4918417dd488b9e
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Convert names to all capital in enum acpi_apic_types. Use of these names in
corresponding type assign for I/O APIC Structure.
Change-Id: Iab2f6d8f645677734df753f8bf59fde4205ce714
Signed-off-by: Himanshu Sahdev <himanshusah@hcl.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36197
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
mainboard_silicon_init_params() is supposed to be used for only
overriding any FSP params as per mainboard configuration. GPIOs should
be configured by mainboard as part of its chip init(). This ensures
proper ordering w.r.t. any common operations that the SoC code might
want to perform e.g. snapshot ITSS polarities.
This change moves the configuration of GPIOs from
mainboard_silicon_init_params() to mainboard chip->init().
Change-Id: I5d10c01c5b9d5f8ed02274d51dcf9c2a17269685
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36270
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
mainboard_silicon_init_params() is supposed to be used for only
overriding any FSP params as per mainboard configuration. GPIOs should
be configured by mainboard as part of its chip init(). This ensures
proper ordering w.r.t. any common operations that the SoC code might
want to perform e.g. snapshot ITSS polarities.
This change moves the configuration of GPIOs from
mainboard_silicon_init_params() to mainboard chip->init().
Change-Id: I5cd89c6e24b6a4b0c20fd476915f3781a0d46e0d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36269
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mathew King <mathewk@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
mainboard_silicon_init_params() is supposed to be used for only
overriding any FSP params as per mainboard configuration. GPIOs should
be configured by mainboard as part of its chip init(). This ensures
proper ordering w.r.t. any common operations that the SoC code might
want to perform e.g. snapshot ITSS polarities.
This change moves the configuration of GPIOs from
mainboard_silicon_init_params() to mainboard chip->init().
Change-Id: Ied0201b954894acd3503801e7739b91a2cc9b4a8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36268
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
mainboard_silicon_init_params() is supposed to be used for only
overriding any FSP params as per mainboard configuration. GPIOs should
be configured by mainboard as part of its chip init(). This ensures
proper ordering w.r.t. any common operations that the SoC code might
want to perform e.g. snapshot ITSS polarities.
This change moves the configuration of GPIOs from
mainboard_silicon_init_params() to mainboard
chip->init(). Additionally, this change moves mainboard_ec_init() to
mainboard dev->init().
TEST=Verified that GPIOs are configured properly and hatch boots to
OS.
Change-Id: Ia509471a3678c60454cd4f14625f151860d9b9d2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36267
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set VPD keys for DSM parameters in overridetree.cb for Helios.
RT1011 driver will load values from VPD and set them to device property.
BUG=b:140397934
BRANCH=none
TEST=On Helios, with patch series, check realtek,r0_calib and
realtek,temperature_calib are available to rt1011 codec driver.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Change-Id: Ic72fd57becf93e70a1a716dbb76633509f2fd5c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The correct mapping for speakers to their names should be:
uid 0: Woofer Left
uid 1: Woofer Right
uid 2: Tweeter Left
uid 3: Tweeter Right
Also, fix the name to be 4-character.
BUG=b:140397934, b:143192767
BRANCH=none
TEST=On Helios, with patch series, check realtek,r0_calib and
realtek,temperature_calib are available to rt1011 codec driver.
And the speaker mapping is correct.
Change-Id: I353fb9ad0ca8ec85431eb2b59be748b4887278cf
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36256
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Found-by: ACPICA 20191018
Change-Id: I8bcdfa7a4dc33c3e3866d3135249a602379b9615
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36265
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Found-by: ACPICA 20191018
Change-Id: Iaa35790a38c36091a228007d739b970cb66a3e1c
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36264
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Found-by: ACPICA 20191018
Change-Id: Ic0bcaa37ac017ab61e1fb4e78d3c7dfbbcc0899d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Change-Id: Ieb54664a6528ce67634991f64a5f3c411822cdf4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36260
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ACPI Version 6.3 Section 6.1: "A device object must contain either an _HID
object or an _ADR object, but should not contain both."
Found-by: ACPICA 20191018
Change-Id: I9f55cc033b5672917520b139444bc614462c4a05
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The SOC DRAM team suggested to delay at least 1us after setting new
voltage in PMIC wrapper so the new value can be effective.
BRANCH=kukui
BUG=b:142358843
TEST=emerge-kukui coreboot
Change-Id: I19d236769c3c0c87513ea4a0a3f64b83e3a844c2
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36254
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add VPD variables for enabling/disabling FRB2 watchdog timer and
setting the timer countdown value. By default it would start the
timer and trigger hard reset when it's expired. The timer is
expected to be stopped later by payload or OS.
Right now the timer is started after FSP-M. Ideally it should be
before FSP-M (to detect memory training error).
Tested on OCP Mono Lake.
Change-Id: I82b244d08380a0461c92662e025d8b95b3133e23
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add a function for initializing and starting FRB2 timer with the
provided countdown and action values, and a stop function for
stopping the timer.
Tested on OCP Monolake.
Change-Id: Ic91905e5f01b962473b6b3a9616266d2d95b1d6b
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
As fmaptool can now handle the offset computation for every mentioned
region in the fmap file on its own there is no need to provide the
offset in the fmd file anymore. This patch clears this out so that the
files are way more readable now.
Change-Id: I1dc841604fdb662e08cb6690ff4bf6dd311e01d8
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
RT1011 is a smart amplifier. It needs to know speaker related parameters
including speaker resistor value and temperature when the calibration is
done in order to run Dynamic Speaker Management (DSM) algorithm on chip.
The purpose of DSM is to protect speaker when the volume is large.
The calibration data of speaker is stored in VPD in factory.
This driver is needed to read data from VPD and write to ACPI _DSD when
config CHROMEOS_DSM_CALIB is turned on.
Kernel rt1011 codec driver will read these device properties to set up
codec accordingly on boot.
The reason to prepare these parameters in coreboot is because kernel
codec driver expects to read per-device parameters directly from device
properties. Another benefit is that other OS can also take these
parameters through ACPI _DSD table and take benefit of DSM on RT1011.
The kernel driver device properties of RT1011 are documented at
linux/Documentation/devicetree/bindings/sound/rt1011.txt
It is currently in ASoC maintainer's tree at
https://kernel.googlesource.com/pub/scm/linux/kernel/git/broonie/sound/+/for-next/
and hopefully should be merged to mainline kernel in the next merge window.
BUG=b:140397934
BRANCH=none
TEST=On Helios, with patch series, check realtek,r0_calib and
realtek,temperature_calib are available to rt1011 codec driver.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Change-Id: I9550b9890ce2cae787f4f17779a5ade77f619171
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
On ChromeOS, there will be VPD values for dynamic speaker management (DSM)
calibration data. They are resistor calibration values and temperature
during calibration.
These VPD fields use "dsm_calib_" prefix.
Known keys are:
"dsm_calib_r0_0"
"dsm_calib_r0_1"
"dsm_calib_r0_2"
"dsm_calib_r0_3"
"dsm_calib_temp_0"
For now these values are unsigned decimal numbers greater than 0.
This library will be used for RT1011 device driver in the patch series.
Note that in the future we may encode more values into this VPD field if
needed. We retain the flexibility for coreboot device driver or codec
driver to decode/parse the VPD values based on the needed use case
per-board.
BUG=b:140397934
BRANCH=none
TEST=On Helios, with patch series, check realtek,r0_calib and
realtek,temperature_calib are available to rt1011 codec driver.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Change-Id: Ib9579a5cc055f8f438cb30a8acaf250a343db19e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Refactor I2C driver for fsp_baytrail to match the coreboot supported I2C
bus device structure. The internal I2C controllers are now handled by
the generic PCI driver approach and generic I2C access is enabled.
As orientation for the I2C code the actual solution from
soc/intel/apollolake I2C was taken. All the I2C specific parts were
removed from lpss.c and have been implemented in the I2C driver.
Future merge to soc/intel/common/block/i2c/i2c.c would be possible.
With this patch I2C chip devices can now be used in devicetree.
TEST=Booted siemens/tcu3 and verified that access to PTN3460 worked.
Change-Id: I3b87bd7c27e4c1afcce7cd4225cca02599f43c60
Signed-off-by: Uwe Poeche <uwe.poeche@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36062
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
To allow retraining memory without hotkey (for example in manufacturing
process), we want to enforce re-training when the recovery reason is set
to VB2_RECOVERY_TRAIN_AND_REBOOT (which can be done by running
"crossystem recovery_request=0xc4").
The special reason was created for X86 MRC cache, for ensuring RO
calibration data is filled (the underlying implementation was in vboot,
not coreboot); and on MT8183 we have only RW calibration, but it seems
totally fine to extend that for RW.
BRANCH=kukui
BUG=None
TEST=boots; crossystem recovery_reason=0xc4; reboot
Change-Id: Iaa5275f0e0eb90f6ab3a7d4579977a6655d59bd9
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Nico Huber