Three stages of the new tint build system:
1) generate_core.sh extracts the core part from buildgcc script,
most importantly the checksum calculation/verification functions.
2) tintify_core.sh adds the tint-specific footer/header to the core,
such as the properties of current version including its checksum.
3) tint.sh - generated and "tintified" core script - builds a tint.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: Ib71f5b861ecf91949a5af12812258e60873f0498
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We need to change OC pin for type C USB3 ports and it depends
on the board design. Allowing it to be filled by devicetree will
make it easier to change the mapping based on the board design
BUG=b:184653645
BRANCH=None
TEST=compilation works fine and value of UPD is getting reflected.
Change-Id: I61faa661c12dced27c6cdd7005a61ae8de8621e1
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
When MRC cache region type is not found (for example, in recovery mode
with !HAS_RECOVERY_MRC_CACHE), mrc_cache_stash_data() will return 0.
Therefore, the platform code is not able to tell from the return value
if the MRC cache data is actually written to flash or not. Since the MRC
driver is already pretty verbose, ignore the return value and remove the
misleading memory logs.
BUG=none
TEST=emerge-asurada coreboot
BRANCH=asurada
Change-Id: I6b411664ca91b9be2d4518a09e9734d26db02d6e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52361
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is no need to stash the SCI trigger register configuration and
apply it at the end. Remove this to make SCI and SMI programming more
symmetrical and to use available configure_scimap function instead of
implementing it again, but without the additional checks. Using this
function also allows removing soc_route_sci.
Change-Id: Ie23da79546858282910db65182a6315ade506279
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This adds a driver for the TI TAS5825M smart amplifier [1].
The driver expects the mainboard using it to define tas5825m_setup(),
which uses the tas5825m_* functions to set configuration data. Each
mainboard may have very different configuration data, depending on
its audio hardware.
Tested on System76 addw1, bonw14, oryp5, and oryp6.
[1]: https://www.ti.com/product/TAS5825M
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I896e8f272f18e64bfc90f406e7d4163010800aaf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The new discovery from Google & AMD, the value currently used
STAPM Time Constant of 1640 is reducing real PPT TSP from the
target 4.8W to 4.68W.
Furthermore, when using the "default" STAPM Time Constant of 1400,
the actual real PPT TSP becomes 4.89W.
Operating at this default settings therefore uses a higher real PPT TSP,
which results in a significant performance improvement.
BUG=b:175364713,b:184902568
BRANCH=zork
TEST=1. emerge-zork coreboot
2. run balance performance and skin temperature test => pass
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Change-Id: I9cf4d51f42fe250340bcb642db07796c9a480c34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52312
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The new discovery from Google & AMD, the value currently used
STAPM Time Constant of 1640 is reducing real PPT TSP from the
target 4.8W to 4.68W.
Furthermore, when using the "default" STAPM Time Constant of 1400,
the actual real PPT TSP becomes 4.89W.
Operating at this default settings therefore uses a higher real PPT TSP,
which results in a significant performance improvement.
BUG=b:184902568
BRANCH=zork
TEST=1. emerge-zork coreboot
2. run balance performance and skin temperature test => pass
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Change-Id: I102c1c5f8215a6c5f7a4451f5731167c32e27c90
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52313
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add wifi sar for botenflex.
Due to fw-config cannot distinguish between boten and botenflex.
Using sku_id to decide to load botenflex custom wifi sar.
Detail reason for using sku_id in b:182433707.
BUG=b:182433707
TEST=build and test on boten/botenflex
Cq-Depend: chrome-internal:3686313
Change-Id: Id3f2529a7ad56ff306df98f77cda556656da52a5
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested with TianoCore payload (UefiPayloadPkg).
Working:
- PS/2 keyboard, touchpad
- Both DIMM slots
- NVMe port
- SATA port
- SD card slot
- Left USB 3 Type-A port
- Right USB 3 Type-A port
- Right USB 3 Type-C port
- Webcam
- Ethernet
- Integrated graphics using Intel GOP driver
- mDP output
- HDMI output
- Internal microphone
- Internal speakers
- 3.5mm audio input
- 3.5mm audio output
- S3 suspend/resume
- Flashing with flashrom
- Booting to Ubuntu Linux 20.10 and Windows 10
Not tested:
- Thunderbolt functionality
Change-Id: I5c992e603dbd57ae1b4ddc3a0f9bfc92d6acc813
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51832
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The functionality to restore the previous power state after power was
lost that could previously be enabled by selecting
MAINBOARD_POWER_RESTORE in the mainboard's Kconfig can now be achieved
by selecting POWER_STATE_PREVIOUS_AFTER_FAILURE in the mainboard's
Kconfig instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I49c4a44ca2c4fa937a823c4eddf1618739c15114
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The functionality to restore the previous power state after power was
lost that could previously be enabled by selecting
MAINBOARD_POWER_RESTORE in the mainboard's Kconfig can now be achieved
by selecting POWER_STATE_PREVIOUS_AFTER_FAILURE in the mainboard's
Kconfig instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iab9578ebea89651dc2389bf6ca93ca3f3507eb47
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52302
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Picasso and Stoneyridge didn't do a read-modify-write operation on the
lower nibble of PM_RTC_SHADOW_REG, but just wrote the upper nibble as
all zeros. Since the upper nibble might be uninitialized before the
lower nibble gets written, do what Picasso and Stoneyridge did here
instead of what the reference code does. Also add a comment why and how
this register behaves a bit weird.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0bda2349e3ae84cba50b187cc773fd8a5b17f4e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52301
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Not selecting POWER_STATE_DEFAULT_ON_AFTER_FAILURE brings Cezanne that
is currently the only SoC using this functionality in line with Picasso
where the default is that the board remains in power off mode after
power was lost and later restored. Boards can change this behavior by
selecting POWER_STATE_OFF_AFTER_FAILURE, POWER_STATE_ON_AFTER_FAILURE or
POWER_STATE_PREVIOUS_AFTER_FAILURE.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic96f40e3c9867cd821e58d752f58b763930f6d0f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>