The mt8183 dsi driver can be shared with mt819x SoC.
Move dsi.c to common/ folder and rename it to dis_v2.c to
differentiate it from mt8173's dsi driver.
TEST=emerge-kukuki coreboot
Change-Id: I722d3e67f230ab8eb729900cdf15b922eb91a072
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48530
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add I2C controller for MT8192, and revise the common I2C driver
to support I2C controller running in APDMA async mode. In that
case we have to initiate a different handshake protocol and reset
I2C differently.
BUG=b:155715435
TEST=Asurada boots up to shell
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Change-Id: I13835e00eb674a93aa5496a9870d1e601e263368
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47800
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
SSPM is "Secure System Power Manager" that provides power control in
secure domain. The initialization flow is to load SSPM firmware to
its SRAM space and then enable.
Signed-off-by: TingHan.Shen <tinghan.shen@mediatek.com>
Change-Id: Ia834852af50e9e7e1b1222ed1e2be20e43139c62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47786
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DPM is a hardware module for DRAM power management and for better
power saving in low power mode.
BUG=none
TEST=Boots correctly on Asurada
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Change-Id: I16b341ad63940b45b886c4a7fd733c1970624e40
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46393
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MCUPM is the MediaTek proprietary firmware for MCU power management.
TEST=1. emerge-asurada coreboot chromeos-bootimage;
2. See following log during booting.
load_blob_file: Load mcupm.bin in 35 msecs, size 115668 bytes
3. Test suspend/resume by:
a. suspend (on DUT): powerd_dbus_suspend
b. resume (on host): dut-control power_state:on
Change-Id: I50bea1942507b4a40df9730b4e1bf98980d74277
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46392
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for loading spm firmware from cbfs to spm sram.
Spm needs its own firmware to enable spm suspend/resume function which
turns off several resources such as DRAM/mainpll/26M clk when linux
system suspend.
BUG=b:159079649
TEST=suspend with command `powerd_dbus_suspend` and
wake up the DUT by powerkey
Signed-off-by: Roger Lu <roger.lu@mediatek.com>
Change-Id: I6478b98f426d2f3e0ee919d37d21d909ae8a6371
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Use mtk_init_mcu API to load and run sspm firmware.
TEST=emerge-kukui coreboot
Change-Id: I63c4b99342bdebb2a94cbf0c6380b0a6817853e7
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
mtk_init_mcu uses DRAM_DMA section as CBFS buffer.
The change "mediatek/mt8183: Remove DRAM_DMA section" is reverted
for using mtk_init_mcu.
On mt8173 and mt8192, this region is used by DMA hardware and is
marked as non-cacheable resource. On mt8183, this region is reserved
as CBFS buffer, so it is not necessary to be marked as non-cacheable
resource.
Change-Id: I7ce9f68883e2787ee7f3c5066f4c47c5ca315633
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add mtk_init_mcu to load the firmware to the specified memory address
and run the firmware. This function also measures the load time and the
blob size. For example:
mtk_init_mcu: Loaded (and reset) dpm.pm in 15 msecs (14004 bytes)
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: Ie94001bbda25fe015f43172e92a1006e059de223
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch flips the default of CONFIG_NO_CBFS_MCACHE so the feature is
enabled by default. Some older chipsets with insufficient SRAM/CAR space
still have it explicitly disabled. All others get the new section added
to their memlayout... 8K seems like a sane default to start with.
Change-Id: I0abd1c813aece6e78fb883f292ce6c9319545c44
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The auxadc (auxiliary analogue-to-digital conversion) is a unit
to identify the plugged peripherals or measure the temperature
or voltages.
The MT8183 auxadc driver can be shared by multiple MediaTek SoCs
so we should move it to the common folder.
Signed-off-by: Po Xu <jg_poxu@mediatek.com>
Change-Id: Id4553e99c3578fa40e28b19a6e010b52650ba41e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
SD Card driver needs to access two regulators - MT6360_LDO5 and
MT6360_LDO3. These two regulators are disabled by default.
Two APIs are implemented:
- mainboard_enable_regulator: Configure the regulator as enabled/disabled.
- mainboard_regulator_is_enabled: Query if the regulator is enabled.
BUG=b:168863056,b:147789962
BRANCH=none
TEST=emerge-asurada coreboot
Change-Id: I391f908fcb33ffdcccc53063644482eabc863ac4
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46687
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, five regulator controls are implemented for DRAM
calibration and DVFS feature.
The regulators for VCORE and VM18 are controlled by MT6359.
The reguatlors for VDD1, VDD2 and VMDDR are controlled by MT6360
via EC.
BUG=b:147789962
BRANCH=none
TEST=verified with DRAM driver
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: Id06a8196ca4badc51b06759afb07b5664278d13b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
MT8192 uses power management interface (PMIF) to access pmics by spmi
and spi, so we add pmif driver to control pmics.
BUG=b:155253454
BRANCH=none
TEST=boot asurada correctly
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Change-Id: I32fc28f72d9522133baa06f9d67c383f814d862c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45398
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reduce PRERAM_CBMEM_CONSOLE buffer from 63K to 19K and reserve
0x00115000 ~ 0x0011ffff for MCUPM.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: Ic82a194736eecd7bdc8df80b493290090a2ccba5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
If no correct params were found in flash, do dram full calibration.
Full calibration will load blob, dram.elf.
Blob version: v3, size: 320KB.
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Change-Id: I2d4437a4e4c770de084927018d4dd3f2e8b87fb1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Mediatek SoC uses part of the L2 cache as SRAM before DRAM is ready.
After DRAM is ready, we should invoke disable_l2c_sram to reconfigure
the L2C SRAM as L2 cache.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: Icaf80bd9da3e082405ba66ef05dd5ea9185784a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46387
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To enable DVFS, DRAM driver needs to access four different
regulators that SoC can't access directly and need board-specific
implementations.
To support that we need to define the getter and setter APIs for
those regulators.
BUG=b:147789962
BRANCH=none
TEST=verified with DRAM driver
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: I0c2d471a7f8628735af90c5b5a5ab3012831e442
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46405
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Load params from flash and use those params to do dram fast calibration.
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Change-Id: I45a4fedc623aecfd000c5860e0e85175f45b8ded
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Adjust ssusb register layout and offset accroding mt8192 Soc
then refactor USB code which will be reused among similar SoCs
Signed-off-by: Tianping Fang <tianping.fang@mediatek.com>
Signed-off-by: Zhanyong Wang <zhanyong.wang@mediatek.com>
Change-Id: Icb4cc304654b5fb7cf20b96ab83a22663bfeab63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Implement mt_fmeter_get_freq_khz() in MT8192 to measure frequency of
some pre-defined clocks by frequency meter.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Change-Id: I75df0b040ed7ea73d25724a3c80040f4e731118f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45402
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
LPDDR4x has 6 CA PINs, but for some 8GB LPDDR4X DDR, the left margin
of some CA PIN window is too small than others. Need to enable the CA
perbit mechanism to avoid those risks.
BUG=none
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: I58e29d0c91a469112b0b1292da80bcb802322d47
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41965
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using common mtcmos code to power on audio and display modules in SOC.
TEST=Boots correctly on MT8192EVB. Passes the status check at the end of
mtcmos_power_on()
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Change-Id: Ie7bff831eecfc2b4d315a577f6ff86befc483eab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45394
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The power status bits of display and audio of MT8192 are different
from the bits of MT8173 & MT8183, so move those under each chip.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Change-Id: Iaa211b8db733d8aa52d93af9e507042bf0984d55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The UART index is never negative, so make it unsigned and drop the
checks for the index to be non-negative.
Change-Id: I64bd60bd2a3b82552cb3ac6524792b9ac6c09a94
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Support SPI flash dual read funciton which change spi mode (1-1-1)
to dual mode (1-1-2).
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: Iabd3668fc4bc42137b7743144fc1cced4fe72737
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44852
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a SPI-NOR flash controller which supports pio mode.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: I1e38672a532dd8234b3ef24c84113888c8795810
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The gpio_common.h needs EINT_BASE from addressmap.h.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: I20834e38343410526da0a489fed907acbf479d02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Initialize watch dog so the system won't reboot on timeout.
In addition, print the reason of reboot triggered by watch dog.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: I7e849659700218f1c50365c2d68a32be2f703d94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Initialize CPU mmu and config range.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: I5ba405dab87d51d373704657ccb44c07c7249041
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add DRAM resource in ramstage to load payload.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: Iac02f81fc7d47851b3bba442eb7043169fbdbcfb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The first Makefile to support building minimal stage files for MT8192 SOC.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: I2cf68805532f70f072b4e9a21ee61e2ebe4ebd9d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43962
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add MT8192 address map, memlayout and first Kconfig. MT8192 is similar to
MT8183.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Change-Id: I4e34c03a11a77ed98674ffd8eeddb20ef5fea89d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43957
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the DRAM initialization code can only work on 4GB size and
want to support larger memory sizes in future, so add geometry
information to the DRAM calibration parameters.
BUG=none
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: I1fdf50b75c6a552c0a889f21e1a81ab4b9a305fa
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Different density should correspond to different tRFCab and tRFCpb
timing.
BUG=none
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: I2599fcd620cdefe2e12480932ffd75e0416b9545
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Some DRAM control settings need to apply to all channels,
so add those missing settings.
Also fix a typo (0x1 < 0) to (0x1 << 0).
BUG=none
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: I35e25c922ed45216d5f04835abcd10809a8d559a
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
I would like to make assertions evaluate at compile time where possible,
but sometimes people used a literal assert(0) to force an assertion in a
certain code path. We already have BUG() for that so let's just replace
those instances with that.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I674e5f8ec7f5fe8b92b1c7c95d9f9202d422ce32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows
SoC/mainboard to provide a linker file for the platform. x86 already
provides a default memlayout.ld under src/arch/x86. With this new
Kconfig variable, it is possible for the SoC/mainboard code for x86 to
provide a custom linker file as well.
Makefile.inc is updated for all architectures to use this new Kconfig
variable instead of assuming memlayout.ld files under a certain
path. All non-x86 boards used memlayout.ld under mainboard
directory. However, a lot of these boards were simply including the
memlayout from SoC. So, this change also updates these mainboards and
SoCs to define the Kconfig as required.
BUG=b:155322763
TEST=Verified that abuild with --timeless option results in the same
coreboot.rom image for all boards.
Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>,
<stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes
each time when <types.h> is included.
Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The CA vref should alway select range[1]. But in fast calibration flow,
we missed the range selection and caused the CA vref to use the range[0] value.
The DQ vref should select correct range that corresponds to current frequency,
that is for 1600Mbps, 2400Mbps to select range[1], for 3200Mbps and 3600Mbps
to select range[0].
Refer to the 'JESD209-4 - Low Power Double Data Rate 4X(LPDDR4X).pdf',
used MR12 to set Vref(CA) levels, used MR14 to set VREF(DQ) levels.
MR12 range[0] values from 15.0% to 44.9%, range[1] values from 32.9% to 62.9%,
MR14 range[0] and range[1] values same as MR12.
BUG=b:153614919
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: Ie7680b1bf0c29c946d18e3b27626ce6f31c4216b
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40525
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If panel has too small hfp or hbp, hfp_byte or hbp_byte may become
very small value or negative value. When very small value or
negative value is used, the panel will be scrolling or distorted.
This patch adjusts their values so that they are greater than
the minimum value and keep total of them unchanged.
DSI transfer HBP or HFP, There are some extra packet. ex. packet
header(4byte) and eof(2byte) and (next)hs packet header(4 byte).
the hfp_byte = HFP * BPP - packet header(4byte) and eof(2byte)
and (next)hs packet header(4 byte). So the min hfp_byte is 2 when
HFP = 4.
This is equivalent to the Linux kernel DSI change in:
https://chromium-review.googlesource.com/c/chromiumos/third_party/
kernel/+/2186872
BUG=b:144824303
BRANCH=kukui
TEST=boot damu board with panel CMN N120ACA-EA1 (12" panel and its
hbp only 6), the panel can display without scrolling or
distortions.
Signed-off-by: Paul Ma <magf@bitland.corp-partner.google.com>
Change-Id: I608c01d41ae93c8d5094647bbf3e0ae4a23d814c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41163
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To change frequency, the SOC PLL team suggests procedure below:
First, we need to enable the intermediate clock and
switch the ca53 clock source to the intermediate clock.
Second, disable the armpll_ll clock output.
Third, raise armpll_ll frequency and enable the clock output.
The last, switch the ca53 clock source back to armpll_ll and
disable the intermediate clock.
BUG=b:154451241
BRANCH=jacuzzi
TEST=Boots correctly on Jacuzzi.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Change-Id: Ib9556ba340da272fb62588f45851c93373cfa919
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41077
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This replaces GPLv2-or-later and GPLv2-only long form text with the
short SPDX identifiers.
Commands used:
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.*of.*the.*License.*or.*(at.*your.*option).*any.*later.*version.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-or-later */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation[.;,].+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This software is licensed under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation,.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
Change-Id: I7a746088a35633c11fc7ebe86006e96458a1abf8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This reverts commit 285975dbba.
Reason for revert: VB2_RECOVERY_TRAIN_AND_REBOOT was never meant to have
any special effect on memory training behavior. It was just supposed to
be a "reboot automatically after reaching kernel verification" recovery
reason. On x86 devices this was used to prime the separate recovery
MRC cache in the factory (make sure it is initialized before shipping).
This isn't used on Kukui anyway, but in order to make sure nobody copies
this code and keep the behavior consistent between platforms, let's
remove it.
Change-Id: I5df5e00526e90cb573131de3c8bac9f85f4e3a5f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40623
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When CONFIG_SEPARATE_VERSTAGE=n, all verstage code gets linked into the
appropriate calling stage (bootblock or romstage). This means that
ENV_VERSTAGE is actually 0, and instead ENV_BOOTBLOCK or ENV_ROMSTAGE
are 1. This keeps tripping up people who are just trying to write a
simple "are we in verstage (i.e. wherever the vboot init logic runs)"
check, e.g. for TPM init functions which may run in "verstage" or
ramstage depending on whether vboot is enabled. Those checks will not
work as intended for CONFIG_SEPARATE_VERSTAGE=n.
This patch renames ENV_VERSTAGE to ENV_SEPARATE_VERSTAGE to try to
clarify that this macro can really only be used to check whether code is
running in a *separate* verstage, and clue people in that they may need
to cover the linked-in verstage case as well.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2ff3a3c3513b3db44b3cff3d93398330cd3632ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: I7c3c75eaf2d7a64e7d833541bcf168b93921a142
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40132
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently, those who want to use measured boot implemented within
vboot should enable verified boot first, along with sections such
as GBB and RW slots defined with manually written fmd files, even
if they do not actually want to verify anything.
As discussed in CB:34977, measured boot should be decoupled from
verified boot and make them two fully independent options. Crypto
routines necessary for measurement could be reused, and TPM and CRTM
init should be done somewhere other than vboot_logic_executed() if
verified boot is not enabled.
In this revision, only TCPA log is initialized during bootblock.
Before TPM gets set up, digests are not measured into tpm immediately,
but cached in TCPA log, and measured into determined PCRs right after
TPM is up.
This change allows those who do not want to use the verified boot
scheme implemented by vboot as well as its requirement of a more
complex partition scheme designed for chromeos to make use of the
measured boot functionality implemented within vboot library to
measure the boot process.
TODO: Measure MRC Cache somewhere, as MRC Cache has never resided in
CBFS any more, so it cannot be covered by tspi_measure_cbfs_hook().
Change-Id: I1fb376b4a8b98baffaee4d574937797bba1f8aee
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Set more AC timing items to make the system more stable.
BUG=none
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: Ibd003582a3ffab1ae91f6378651c2c9e585c4676
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
They're listed in AUTHORS and often incorrect anyway, for example:
- What's a "Copyright $year-present"?
- Which incarnation of Google (Inc, LLC, ...) is the current
copyright holder?
- People sometimes have their editor auto-add themselves to files even
though they only deleted stuff
- Or they let the editor automatically update the copyright year,
because why not?
- Who is the copyright holder "The coreboot project Authors"?
- Or "Generated Code"?
Sidestep all these issues by simply not putting these notices in
individual files, let's list all copyright holders in AUTHORS instead
and use the git history to deal with the rest.
Change-Id: I4c110f60b764c97fab2a29f6f04680196f156da5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Move channel loop at the top level to deduplicate the logic.
BUG=none
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: Iea623d1bd1f7d736e81f66f191a1bf8476d30404
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The TX window will offset to edge during DVFS switch, which may cause
TX data transmission error and random kernel crash. Therefore, use the
standard dqsosc (DQS Oscillator) for TX window tracking.
BUG=b:142358843
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: Idcf9213a488e795df3faf64b03588cfe55cb2f81
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Because eMCP and discrete DDR devices have different DVFS tables, their
EMI bandwidth thresholds should also be different. When the EMI total
bandwidth reaches the threshold, the system will notify DVFS module to
perform DVFS switch for system performance in low power states.
This patch increases the threshold from 0xa to 0xd for eMCP DDR devices
so that DVFS switch will be less likely to happen.
The register table of EMI_BWCT0 is incorrect in the datasheet. According
to the hardware design, BW_2ND_INT_BW_THR should be in bits [30:24]
instead of [22:16]. However, the logic in DRAM driver is correct,
aligned with the hardware design, so we don't need to correct it.
BRANCH=kukui
BUG=b:142358843
TEST=bootup pass
Change-Id: I82c3c70bcd90df3fdd613c0353aba0f176bc82bc
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39034
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. The ac timing of 2400Mbps should use diff params with 1600Mbps.
2. Fix the typo error of save shuffle function for DVFS.
BRANCH=kukui
BUG=none
TEST=emerge-kukui coreboot
Change-Id: I5edac32938def50836f386426e7deb652b80d42d
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The number of bits per pixel for MIPI_DSI_FMT_RGB666 should be 24
instead of 18.
BRANCH=none
BUG=none
TEST=none
Change-Id: I9574502b2dec4b5a042df3886922ddd8c755da1a
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jitao Shi <jitao.shi@mediatek.corp-partner.google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The extra data transfer in DSI, namely, lpx, hs_prepare, hs_zero,
hs_exit and the sof/eof of DSI packets, will enlarge the line time,
which causes the real frame on dsi bus to be lower than the one
calculated by video timing. Therefore, hfp_byte is reduced by d_phy to
compensate the increase in time by the extra data transfer. However, if
hfp_byte is not large enough, the hsync period will be increased on DSI
data, leading to display scrolling in firmware screen.
To avoid this situation, this patch changes the DSI Tx driver to reduce
both hfp_byte and hbp_byte, with the amount proportional to hfp and hbp,
respectively. Refer to kernel's change in CL:1915442.
Also rename 'phy_timing' to 'timing' to sync with kernel upstream.
Since the phy timing initialization sequence has been corrected, the m
value adjustment in the analogix driver can be removed.
BUG=b:144824303
BRANCH=kukui
TEST=emerge-jacuzzi coreboot
TEST=Boots and sees firmware screen on krane and juniper
TEST=No scrolling issue on juniper AUO and InnoLux panels
Change-Id: I10a4d8a4fb41c309fa1917cf1cdf19dabed98227
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38400
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
When configuring MIPI DSI Tx, the value of pcw was calculated from data
rate in MHz, leading to loss of precision. This patch changes to use
data rate in Hz for the calculation so that the resulting value should
be consistent with the one in kernel (CL:1786327).
In addition, change the type of data rate to u32, and calculation of
data rate from pixel clock is changed to use DIV_ROUND_UP for
consistency with kernel (CL:1761843).
Also remove unused variable txdiv.
BRANCH=kukui
BUG=b:149051882
TEST=emerge-jacuzzi coreboot
TEST=No scrolling issue on Juniper AUO and InnoLux panels
Change-Id: I23220d446833b956431006027bbc8cb20fc696a5
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38827
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The names of each spi flash cause quite a bit of bloat in the text
size of each stage/program. Remove the name entirely from spi flash
in order to reduce overhead. In order to pack space as closely as
possible the previous 32-bit id and mask were split into 2 16-bit
ids and masks.
On Chrome OS build of Aleena there's a savings of >2.21KiB in each
of verstage, romstage, and ramstage.
Change-Id: Ie98f7e1c7d116c5d7b4bf78605f62fee89dee0a5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
DRAM calibration sets vcore to different voltages at different
frequencies. After DRAM calibration, vcore should be restored to the
default voltage, which is 800mV for both eMCP and discrete DDR devices.
BRANCH=kukui
BUG=b:146618163
TEST=bootup pass
Change-Id: Ia87b4ac78a32dbd4c4ab52e84d307cb46525afa1
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
The delay cell result should use DDR clock PLL rate for computation,
and should not be divided by 2.
This helps to improve DRAM stability.
BUG=b:80501386,b:142358843
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: Idf5cce206e248bb327f9a7d27c4f364ef1c68aa1
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For low frequency (e.g., 1600 or 2400 Mbps) we can do fast
calibration for TX and RX window. However, for high frequency
(e.g., 3200 or 3600 Mbps) a full calibration is needed.
BUG=b:80501386,b:142358843
BRANCH=kukui
TEST=Boots correctly on Kukui
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Change-Id: I00d563ece4cf91ef5e8e12b6cf7f777849375a24
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36921
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes all existing instances of clrsetbits_leXX() to the
new endian-independent clrsetbitsXX(), after double-checking that
they're all in SoC-specific code operating on CPU registers and not
actually trying to make an endian conversion.
This patch was created by running
sed -i -e 's/\([cs][le][rt]bits\)_le\([136][624]\)/\1\2/g'
across the codebase and cleaning up formatting a bit.
Change-Id: I7fc3e736e5fe927da8960fdcd2aae607b62b5ff4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
When we only enable XO_SOC and mask most BBLPM requests, the BBLPM HW
arbiter will have DCXO core to enter Baseband Low-Power Mode(BBLPM).
Under BBLPM mode, inaccurate(about 1.5KHz offset) 26MHz clocks from
crystal is provided and crystal voltage will drop from 1.8V to 0.7V
or lower.
In order to ensure the stability by always outputting an accuarate
system clock when system is running. We should disable BBLPM when only
XO_SOC enabled.
BRANCH=kukui
TEST=accurate 26MHz provided and correct crystal voltage swing
Change-Id: Iea72a964507a19735cf92e3774cd8a94c06545b2
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37136
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch moves the traditional POSIX stdbool.h definitions out from
stdint.h into their own file. This helps for using these definitions in
commonlib code which may be compiled in different environments. For
coreboot everything should chain-include this stuff via types.h anyway
so nothing should change.
Change-Id: Ic8d52be80b64d8e9564f3aee8975cb25e4c187f5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36837
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Leave more space for PreRAM memconsole especially for seeing complete
logs when doing DRAM full calibration (that outputs in 200+k to UART):
- Shrink Full-K mem space (the ELF blob today needs ~132K)
- Move PRERAM_CBFS_CACHE to L2C since it's no used after DRAM is up
- Shrink TIMESTAMP to 1k (all other non-MTK ARM SOCs use only 1k)
- Incease PRERAM_CBMEM_CONSOLE to 63k-4
- Reordered few sections to align at better locations
BUG=b:144542023
TEST=emerge-kukui coreboot chromeos-bootimage; boot and see logs
Change-Id: I8696fb01653c0a581cf62e687dc523cb6fed9a32
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds an optional pre-RAM cache for the FMAP which most
platforms should be able to use, complementing the recently added
post-RAM FMAP cache in CBMEM. vboot systems currently read the FMAP
about half a dozen times from flash in verstage, which will all be
coalesced into a single read with this patch. It will also help
future vboot improvements since when FMAP reads become "free" vboot
doesn't need to keep track of so much information separately.
In order to make sure we have a single, well-defined point where the new
cache is first initialized, eliminate the build-time hardcoding of the
CBFS section offsets, so that all CBFS accesses explicitly read the
FMAP.
Add FMAP_CACHEs to all platforms that can afford it (other than the
RISC-V things where I have no idea how they work), trying to take the
space from things that look like they were oversized anyway (pre-RAM
consoles and CBFS caches).
Change-Id: I2820436776ef620bdc4481b5cd4b6957764248ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36657
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Joel Kitching <kitching@google.com>
This solution is very generic and can in principle be implemented on
all arch/soc. Currently the old infrastructure to pass on information
from romstage to ramstage is left in place and will be removed in a
follow-up commit.
Nvidia Tegra will be handled in a separate patch because it has a
custom ramstage entry.
Instead trying to figure out which files can be removed from stages
and which cbmem_top implementations need with preprocessor, rename all
cbmem_top implementation to cbmem_top_romstage.
Mechanisms set in place to pass on information from rom- to ram-stage
will be replaced in a followup commit.
Change-Id: I86cdc5c2fac76797732a3a3398f50c4d1ff6647a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This adds a common cbmem_top implementation to all coreboot target.
In romstage a static variable will be used to cache the result of
cbmem_top_romstage.
In ramstage if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is set a global variable
needs to be populated by the stage entry with the value passed via the
calling arguments. if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is not set the
same implementation as will be used as in romstage.
Change-Id: Ie767542ee25483acc9a56785ce20a885e9a63098
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Currently full calibration with DVFS (which implies tripling memory
training time for multiple frequencies) will be run in recovery mode,
which takes up to 30 seconds with serial console enabled.
However, in recovery mode the system should be running only the recovery
programs with minimal services. DVFS should be not needed.
In order to improve stability and system boot time, we want to disable
DVFS training in recovery mode.
BRANCH=kukui
BUG=b:142358843
TEST=emerge-kukui coreboot
Change-Id: I4f1b1b020eba9bfce21655169bcb31b98d54b010
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36456
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To make data flow more explicit, global variables 'MR01Value' and
'MR13Value' are replaced with local variables, which are passed as
function arguments.
BRANCH=kukui
BUG=none
TEST=1. emerge-kukui coreboot
2. Fast calibration succeeded
Change-Id: Id21483092c86c3ae7dbb1173a2b943defe41a379
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36286
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
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>
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>
To fix MIPI D-PHY test failure, the hs-prepare should be less than
LimitMin from spec, and we have to enlarge TEOT margin.
BUG=b:138344447
BRANCH=kukui
TEST=Boots correctly on kukui
Change-Id: If91e7a546866299f02432be27fe778be5d7bdc5f
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Similar to MRC cache on x86 platforms, when a hotkey is pressed during
boot, the calibration data cache saved in the flash will be cleared,
consequently triggering DRAM retraining (full calibration) in the next
boot.
BRANCH=kukui
BUG=b:139099592
TEST=emerge-kukui coreboot
Change-Id: I2f9225f359e1fe5733e8e1c48b396aaeeb9a58ab
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
SoC DRAM team suggested always running full calibration mode in recovery
mode because it is possible to get unstable memory even if the complex
memory test has been passed.
Since the recovery mode runs from RO and we only have training data
cache for RW, the trained calibration data can't be saved since RO and
RW may be running different firmware.
Also revised few message to make it more clear for what calibration mode
(fast, full, or partial) has been executed.
BRANCH=kukui
BUG=b:139099592
TEST=emerge-kukui coreboot
Change-Id: I29e0df71dc3357462e15ce8fc2ba02f21b54ed33
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The DRAM calibration blob can be compressed using pre-RAM algorithm
(currently LZ4), which will save ~12ms in boot time.
On Kodama, boot time difference:
Before: 1,082,711
After: 1,070,309
BUG=b:139099592,b:117953502
TEST=build and boot, cbfstool coreboot.rom print -v (see dram compressed)
BRANCH=kukui
Change-Id: Ic3bd49d67ee6f80a0e4d8f6945744642611edf64
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
To make data flow more explicit, global variable 'impedance' is replaced
with a local variable, which is passed as a function argument.
BUG=none
BRANCH=kukui
TEST=Krane boots correctly
Change-Id: I0f6dacc33fda013a3476a10d9899821b7297e770
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The patch adds config MT8183_DRAM_DVFS to enable DRAM calibration with
multiple frequencies to support DVFS switch.
BUG=b:80501386,b:142358843
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: I97c8e513dc3815a2d62b2904a246a1d8567704a4
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch supports voltage adjustment for each DRAM frequency, which is
neccesary to support DVFS switch.
BUG=b:80501386,b:142358843
BRANCH=none
TEST=Boots correctly and stress test pass on Kukui.
Change-Id: I9539473ff708f9d0d39eb17bd3fdcb916265d33e
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
DRAM DVFS needs to be calibrated with different vddq voltages to get
correct parameters.
A new API is added to allow changing vddq voltage.
BUG=b:80501386
BRANCH=none
TEST=measure vddq voltage with multimeter
Change-Id: I5f0d82596a1709bf0d37885f257646133f18f210
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35147
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DRAM DVFS needs to be calibrated with different vdram1 voltages to get
correct parameters.
A new API is added to allow changing vdram1 voltage.
BUG=b:80501386
BRANCH=none
TEST=measure vdram1 voltage with multimeter
Change-Id: Ia15ab3a2e1668e5b4873d317b57a38ebee037709
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33186
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most coreboot debug messages are sent to UART and cbmem console, and we
also want to collect DRAM calibration module output, especially for
cbmem console (so we can see the logs after kernel is up).
Instead of sharing whole cbmem/cbtable/cbmemconsole implementations, we
want to simplify that by a simple function pointer so output can be
preserved by do_putchar, which internally sends data to all registered
consoles (usually cbmem console and UART).
BUG=b:139099592
TEST=make; boots properly for full-k, with and without serial console.
BRANCH=kukui
Change-Id: I1cf16711caf3831e99e17b522b86694524425116
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36056
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The checksum is stored in the header of calibration data and saved to
SPI flash. After reading the data from flash, checksum is used to verify
the integrity of the calibration parameters.
BUG=b:139099592
BRANCH=kukui
TEST=Calibration data successfully loaded from flash
Change-Id: Ie4a0688ed6e560d4c0c6b316f44e52fd10d71a9d
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36014
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
In broadcast mode we only need to set registers for channel 0
instead of all channels.
BUG=none
BRANCH=kukui
TEST=emerge-kukui coreboot
Change-Id: I22a4b69fd40d1978fa7b12e8edaba00ce5d7787d
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Replace the magic clrsetbits_le32, read32, write32 by SET_BITFIELDS and
other bit field helpers.
Change-Id: I327297dd10718fbef7275fe95c95d00d3ab6ac84
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35471
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If DRAM calibration fails or mem test fails using the cached calibration
results stored in flash, rerun DRAM full calibration. If partial
calibration fails or the mem test following it fails, hang forever.
Partial calibration acts as a fallback approach in case of full
calibration failure. Therefore, if it fails, there would be no other
ways to initialize DRAM. Instead of falling into reboot loop and
draining out of battery, it is better to just hang so that the end user
may notice that and send to RMA.
BUG=b:80501386,b:139099592
BRANCH=kukui
TEST=Boots correctly on Kukui
Change-Id: I8e1d4f5bc7b45f45a8bfef74e86ec0ff6a556af4
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35481
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since struct dramc_param has been defined, we can pass the struct
directly from mt_mem_init().
BUG=b:139099592
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: If7333fb579eff76dd9d1c2bf6fdfe7eccb22050f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35846
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Load the calibration params from flash first and check the correctness
of the params. If the params have correct format, perform DRAM fast
calibration with these params to reduce bootup time. Otherwise, load the
DRAM blob and perform DRAM full calibration.
Bootup time of DRAM partial calibration:
- 1,349,385 usecs with low frequency
- 924,698 usecs with middle frequency
- 1,270,089 usecs with high frequency
3,544,172 usecs in total.
Bootup time of DRAM fast calibration:
- 216,663 usecs with low frequency
- 328,220 usecs with middle frequency
- 322,612 usecs with high frequency
867,495 usecs in total.
BUG=b:139099592
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: I8de29b14b1fb24b3b4f351c855c5c4d8f350cc34
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35110
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Load calibration params from flash. If the format of the params is
correct, use these calibration params for fast calibration to reduce the
bootup time.
Bootup time of DRAM partial calibration:
- 1,349,385 usecs with low frequency
- 924,698 usecs with middle frequency
- 1,270,089 usecs with high frequency
3,544,172 usecs in total.
Bootup time of DRAM fast calibration:
- 216,663 usecs with low frequency
- 328,220 usecs with middle frequency
- 322,612 usecs with high frequency
867,495 usecs in total.
BUG=b:139099592
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: I9ef4265dd369a1c276bb02294696556df927e7bc
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35164
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The dramc_param module simplifies the communication between coreboot and
MTK DRAM full calibration blob, and is shared by both implementations to
ensure the same format of parameters.
BUG=b:139099592
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: I4cfd634da1855a76706aab0b050197251e2ed4dd
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Since we always write to &ch[chn].ao.dummy_rd after calling
dramc_engine2_end(), this write could be merged into dramc_engine2_end()
to simplify code.
BUG=none
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: Ibb4bd5ed016118811ad2097098417c19f00f4263
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35749
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Two fields of struct sdram_params are renamed for future CL of DRAM full
calibration. Field 'impedance' is also removed.
BUG=none
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: I2f9673fd5ea2e62ee971f0d81bdd12aaf565e31c
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35738
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Because vcore is the power of ddrphy in the soc, DRAM DVFS needs to be
calibrated with different vcore voltages to get correct parameters.
A new API is added to allow changing vcore voltage.
BUG=b:80501386
BRANCH=none
TEST=measure vcore voltage with multimeter
Change-Id: Ic43d5efe7e597121775dc853a3e2a08ebc59657d
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33391
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support mt8183 power saving during suspend to RAM, this patch loads
SPM firmware to support SPM suspend. SPM needs its own firmware to do
these power saving in the right timing under correct conditions. After
linux PM suspends, SPM is able to turn off power for the last CPU and do
more power saving for the SoC such as DRAM self-refresh mode and turning
off 26M crystal.
BUG=none
BRANCH=none
TEST=suspend/resume passes for LPDDR4 3200
Change-Id: I3393a772f025b0912a5a25a63a87512454fbc86e
Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Devices using eMCP may run at a high DRAM frequency (e.g., 3600Mbps)
while those with discrete DRAM can only run at 3200Mbps. This patch
enables 3600Mbps for eMCP DDR for better system performance.
BUG=b:80501386
BRANCH=none
TEST=Boots correctly and stress test passes on Kukui
Change-Id: Iab6a9c2c390feeb9497b051a255b29566909e656
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34990
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Add more DRAM frequency bootup to support DRAM frequencies 1600Mbps,
2400Mbps, 3200Mbps and 3600Mbps.
BUG=b:80501386
BRANCH=none
TEST=Memory test passes on eMCP platform
Change-Id: Ic1378ca43fb333c445ca77e7dc0844cdf65f2207
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch implements the dram init setting by replacing the hard-coded
init sequence with a series of functions to support calibration for more
frequencies. These functions are modified from MediaTek's internal DRAM
full calibration source code.
BUG=b:80501386
BRANCH=none
TEST=1. Kukui boots correctly
2. Stress test (/usr/sbin/memtester 500M) passes on Kukui
Change-Id: I756ad37e78cd1384ee0eb97e5e18c5461d73bc7b
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34988
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Initialize the input_hertz and uart_pci_addr fields of the lb_serial
struct to prevent later undefined reads in lb_add_serial(). This was
done for exynos5420 in commit ff94e00362 (soc/samsung/exynos5420/uart.c:
Init new serial struct variables), and this patch finishes the rest.
Note that not all of the drivers can have the UART PCI address
configured at build time, so a follow-up patch will be needed to correct
those ones.
Change-Id: I733bc8185e2f2d28a9823495b53d6b09dce4deb1
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1354778
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34548
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set BL31 platform to mt8183 to link with ARM Trusted Firmware.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui with more patches in ATF.
Change-Id: Ia988d2b4ed646027c04c7c6ff0e50ed7a0b14da3
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch uprevs the Arm Trusted Firmware submodule to the new upstream
master (commit 42cdeb930).
Arm Trusted Firmware unified a bunch of stuff related to BL31 handoff
parameters across platforms which involved changing a few names around.
This patch syncs coreboot back up with that. They also made header
changes that now allow us to directly include all the headers we need
(in a safer and cleaner way than before), so we can get rid of some
structure definitions that were duplicated. Since the version of entry
point info parameters we have been using has been deprecated in Trusted
Firmware, this patch switches to the new version 2 parameter format.
NOTE: This may or may not stop Cavium from booting with the current
pinned Trusted Firmware blob. Cavium maintainers are still evaluating
whether to fix that later or drop the platform entirely.
Tested on GOOGLE_KEVIN (rk3399).
Change-Id: I0ed32bce5585ce191736f0ff2e5a94a9d2b2cc28
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Devices using eMCP may run at a high DRAM frequency (e.g., 3600Mbs)
while those with discrete DRAM can only run at 3200Mbps. A new option
MT8183_DRAM_EMCP is added to Kconfig for a mainboard to select,
depending on whether it supports eMCP or not.
BUG=b:80501386
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: I9b73c8b512db5104896ea0d330d56e63eb50a44b
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Some USB 3.0 devices fail to be enumerated after USB reset, and xhci
port status register shows the device is disconnected. After measuring
the USB signal, we found that the USB disconnect threshold was lower and
that the disconnect event was triggered unexpectedly.
USB designers suggest changing discth to 15.
BUG=b:122047652
TEST=emerge-kukui coreboot chromeos-bootimage
Change-Id: I0e8556035b49d693a42cbe1099a6882a1c0ed0d1
Signed-off-by: Changqi Hu <changqi.hu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Consider the association between modem[1] and DCXO, this patch is a fix for
eb5e47d("mediatek/mt8183: update dcxo output buffer setting") [2]
We should not disable XO_CEL and block the bblpm request when modem is still ON.
For power-saving, we still could disable unused XO_CEL and
mask request to disable unused power mode when modem is no longer be used.
[1] https://review.coreboot.org/c/coreboot/+/32666
[2] https://review.coreboot.org/c/coreboot/+/32323
BRANCH=none
TEST=Boots correctly on Krane.
Change-Id: I047ebed615e874977ca211aafd52b5551c71b764
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch renames arm_tf.c and arm_tf.h to bl31.c and bl31.h,
respectively. That name is closer to the terminology used in most
functions related to Trusted Firmware, and it removes the annoying
auto-completion clash between arm64/arm_tf.c and arm64/armv8.
Change-Id: I2741e2bce9d079b1025f82ecb3bb78a02fe39ed5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34677
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Enlarge PRERAM_CBFS_CACHE region from (16K - 4) to (48K - 4) bytes to
decompress and load more data from CBFS in romstage.
BUG=b:134351649
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: Idc23a67c886718e910ca3c50468e5793f19c8d66
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34896
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since SRAM space is too small to fit all needed features, enable
VBOOT_RETURN_FROM_VERSTAGE and overlap decompressor, verstage and
romstage to gain more space.
BUG=b:134351649
BRANCH=none
TEST=emerge-kukui coreboot
Change-Id: Ibe336cf93b01fa2ea57b4c2e0a89685424878c91
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34871
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some boards (e.g., Kukui) need GPIO based CS for SPI0. This patch
changes the pinmux and binds the pins to the correponding SPIs.
When using GPIO based SPI CS, we need to manually make CS log/high
before/after SPI transactions.
BUG=b:132311067
BRANCH=none
TEST=Verified that b/132311067 is irreproducible
Change-Id: I61653fb19242b6ee6be9a45545a8b66e5c9c7cad
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33165
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The fixed size of init command in lcm_init_table is wasting lots of
space and we should change to packed array since the command buffer
already provides length information.
With this change, BOE panel init commands have been reduced from 4848
bytes to 1309 bytes.
BUG=b:80501386,b:117254947
TEST=emerge-kukui coreboot chromeos-bootimage; Boots properly
Change-Id: I359dde8e6f2e1c0983f4677193bb47a7ae497ca6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34778
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MT8183 display serial interface (DSI) is based on MIPI
Alliance Specification, supporting high-speed serial data
transfer between host processor and peripheral devices such
as display modules.
DSI supports both video mode and command mode data transfer
defined in MIPI spec, and it also provides bidirectional
transmission with low-power mode to receive messages from
the peripheral.
Reference: MT8183 Application Processor Functional Spec,
6.7 Display Serial Interface (DSI)
BUG=b:80501386,b:117254947
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: Ic413f524ca0b36f0b01f723a71fe9745e2710cd2
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31591
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For systems with real MIPI panels (8173/oak was using PS8640 eDP
bridge), we have to send DCS commands to initialize panel.
BUG=b:80501386,b:117254947
TEST=make -j # board = oak and boots
Change-Id: Ie7c824873465ac82a95bcb0ed67b8b9866987008
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34773
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The video timing should be based on PHY timing. Some values can be
ignored on 8173 because of fixed values in PHY but should be calculated
for newer platforms like 8183.
BUG=b:80501386,b:117254947
TEST=make -j # board = oak and boots
Change-Id: Id3ad2edc08787414a74188f5050460e98222caf4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The PHY timing should be calculated by data rate (Mbps). However for
8173 some values were hard-coded so we want to introduce a new
mtk_phy_timing structure and a weak function mtk_dsi_override_phy_timing
that allows per-SOC customization to apply PHY timings.
BUG=b:80501386,b:117254947
TEST=make -j # board = oak and boots
Change-Id: I1176ca06dda026029ff431aca7f9e21479eed670
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The only platform-specific difference in mtk_dsi_phy_clk_setting is how
to configure MIPI TX because those registers (and logic) are quite
different across different SOCs.
The calculation of data rate is actually the same so we should isolate
it and move to common, and rename mtk_dsi_phy_clk_setting to a better
name as mtk_dsi_configure_mipi_tx.
BUG=b:80501386,b:117254947
TEST=make -j # board = oak and boots
Change-Id: I894dc2c4c053267debf5a58313b2bb489bcf5f3a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The 'bpp' was referred to both 'bits per pixel' and 'bytes per pixel' in
MTK DSI driver and should be corrected. By this change we now always
consider 'bpp' as 'bits per pixel', and rename the variables for other
cases.
BUG=b:80501386,b:117254947
TEST=make -j # board = oak and boots
Change-Id: Ibd405220b73859e5592c68f498af07eef8d7edbc
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34770
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DSI initialization is almost the same for 8173 and 8183, so we want
to move most of common functions into common/dsi.c.
The major board-specific functions left are:
- reset (controller register has different format)
- pin_drv_ctrl (8183 does not need this)
BUG=b:80501386,b:117254947
TEST=make -j # board=oak (mt8173)
Change-Id: I8d4369a3c84db551287a9c9d1b22f552c5f7518d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34769
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MT8183 SOC has a DISP (display controller) that supports
overlay, read/write DMA, ... etc. The output of DISP goes to
display interface DSI, DPI or DBI directly.
Reference: MT8183 Application Processor Functional Spec,
6.1 Display Controller
BUG=b:80501386,b:117254947
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: Ic4aecc58d081f14f5d136b9ff8e813e6f40f78eb
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Move those will be shared by other MTK SOCs (for example, MT8183) to
common/ddp.c.
BUG=b:80501386,b:117254947
BRANCH=none
TEST=Boots correctly on Oak
Change-Id: Ie5709ab6e263caa21fdf7e799dc2ee884ffaf800
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The 'dual DSI mode' was never used by any real boards running coreboot
and is introducing lots of complexity when it comes to refactoring.
In order to create a common display stack for MTK SOCs, we want to first
drop dual DSI mode so 8173 and 8183 DSI/DDP implementation will be more
similar to each other.
BUG=b:80501386,b:117254947
TEST=emerge-oak coreboot
Change-Id: I357c30cc687803ca8045d0b055dec2e22eef4291
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34693
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch implements i2c driver for MT8183.
BUG=b:80501386
BRANCH=none
TEST=Boot correctly on kukui.
Change-Id: I0a4d78b494819f45951f78e5a618021000cf3463
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30976
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Refactor I2C code which will be reused among similar SOCs.
BUG=b:80501386
BRANCH=none
TEST=emerge-elm coreboot
Change-Id: I407d5e2a9eb29562b40bb300e39f206a94afe76c
Signed-off-by: qii wang <qii.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30975
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Load SSPM firmware and boot up SSPM.
BUG=b:80501386
BRANCH=none
Test=We can see "SSPM is alive" in ATF stage if SSPM enabled and ipi success
Change-Id: I9285034fc8ce38b40134f5eb7b986a663175e620
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31835
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Also including <types.h>, is supposed to provide stdint and stddef.
Change-Id: Id6d881055826044d04843ba165641131b9111342
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
SRCCLKENA holds 26M clock, which will fail suspend/resume,
and the SRCCLKENA is not used by mt8183,
so we can simply release it for suspend/resume to work.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui, suspend test pass.
Change-Id: Ib6e11faeb6936a1dd6bbe8b1a8b612446bf51082
Signed-off-by: Yanjie.jiang <yanjie.jiang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32666
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SSPM is "Secure System Power Manager" that provides power control in
secure domain. The initialization flow is to load SSPM firmware to
its SRAM space and then enable.
BUG=b:80501386
BRANCH=none
Test=Build pass
Change-Id: I4ae6034454326f5115cd3948819adc448b67fb1c
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31516
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Calibrate RTC eosc clock which will be used when RTC goes into
low power state.
BUG=b:133872611
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: Ie8fd6f4cffdcf7cf410ce48343378a017923789c
Signed-off-by: Ran Bi <ran.bi@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33907
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
DCXO consists of core that generates clock and output buffers that
provide clock to other peripheral components.
This patch mainly eliminates the extra power consumption of output buffers.
We only enable the buffer for SOC and disable unused buffers for power-saving.
Also disable useless buffer power mode to guarantee the lowest power state.
BRANCH=none
TEST=Boots correctly on Kukui.
Change-Id: I2e5ce181ad327ccf852979da53baca4f249912fe
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32323
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When system shuts down, RTC enable eosc calibration feature to save
power. Then coreboot RTC driver needs to call rtc_enable_dcxo function
at every boot to switch RTC clock source to dcxo.
BUG=b:128467245
BRANCH=none
TEST=Boots correctly on Kukui
Change-Id: Iee21e7611df8959cbbc63b6e6655cfb462147748
Signed-off-by: Ran Bi <ran.bi@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Support SAMSUNG KMDP6001DA-B425 and MICRON MT29VZZZAD8DQKSL EMCP LPDDR4X DDR
From the calibration log of MICRON MT29VZZZAD8DQKSL, we found
the begin pass range of RX window earlier than with other DDR type.
So need change the DQS starting offset to increase the scan range of RX window.
BUG=b:80501386
BRANCH=none
TEST=Boots correctly on EMCP DRAM
Change-Id: I5fcc8673a2fbd7ec3a8776ab61c57f8903ddda20
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32243
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Huayang Duan <huayang.duan@mediatek.corp-partner.google.com>
The mode register setting of DRAM may fail without some
delay after each MR write.
BUG=b:80501386
BRANCH=none
TEST=Boots correctly and stress test pass on Kukui.
Change-Id: I51785e90b2014994be5018bfe543245d44626242
Signed-off-by: Huayang Duan <huayang.duan@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32284
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Huayang Duan <huayang.duan@mediatek.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The correct address for vproc12 register of sw mode is 0x1426 instead
of 0x140a.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui and see that regulator is not stuck to
1.05V anymore:
grep vproc12 /sys/kernel/debug/regulator/regulator_summary
Change-Id: I13867b11c44019875e0ed607343197950a3b38b2
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33168
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add infra group DCM (Dynamic Clock Management) settings,
which slows down OR gate clocks while hardware is in idle state.
BUG=b:80501386
BRANCH=none
TEST=Boots correctly on Kukui.
Change-Id: I4741dfb7b984deb92171f370e5fb2593829d74c2
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31977
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
We need to support RTC in ramstage so that we can see correct timestamp
in ChromiumOS eventlog.
BUG=b:134461866
TEST='mosys eventlog list' shows correct timestamp on Kukui
Change-Id: Idb0fe5c05e4ecdf0e6398e3c781c71d14f85f19b
Signed-off-by: You-Cheng Syu <youcheng@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The values from auxadc may be incorrect if not calibrated by efuse.
Without calibration, the value error range is about +/-50mv,
and after being calibrated the error range is about +/-10mv.
BUG=b:131391176
TEST=make clean && make test-abuild; boots on Kukui rev 2 units.
BRANCH=none
Change-Id: Iccd6ea0ad810c993f9b62c0974279c960f890e52
Signed-off-by: Po Xu <jg_poxu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32800
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: JG Poxu <jg_poxu@mediatek.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The default voltage of vsim2 is set to 2.76V for sim card usage.
In general, 2.76V of vsim2 is composed of 2.7V main voltage and 0.06V calibration voltage.
However, vsim2 is used for the tx_ovdd power of display port IT6505 on the kukui board design which needs 2.7V.
So we set it to 2.7V with modifying calibration value.
BUG=b:126139364
BRANCH=none
TEST=measure vsim2 voltage with multimeter
Change-Id: I4dffdde89cbde91286d92e6c2b445f0b3d0ad2fe
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32057
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
<types.h> is supposed to provide <stdint.h> and <stddef.h>.
When <types.h> is included, <stdint.h> and/or <stddef.h> is removed.
Change-Id: I2db0a647bc657a3626cb5e78f23e9198e290261a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
When we increase voltages, it takes 200us for voltages to stablize.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui
Change-Id: I5f32035693b6084dbe763411c612ae5d1f7c9e48
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The name OPROM is somewhat inaccurate, since other steps to bring
up display and graphics are needed depending on mainboard/SoC.
This patch cleans up OPROM code nomenclature, and works towards
the goal of deprecating vboot1:
* Rename CONFIG_VBOOT_OPROM_MATTERS to
CONFIG_VBOOT_MUST_REQUEST_DISPLAY and clarify Kconfig
description
* Remove function vboot_handoff_skip_display_init
* Remove use of the VbInit oflag VB_INIT_OUT_ENABLE_DISPLAY
* Add |flags| field to vboot_working_data struct
* Create VBOOT_FLAG_DISPLAY_REQUESTED and set in vboot_handoff
BUG=b:124141368, b:124192753, chromium:948529
TEST=make clean && make test-abuild
TEST=build and flash eve device; attempt loading dev/rec modes
BRANCH=none
Change-Id: Idf111a533c3953448b4b9084885a9a65a2432a8b
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Implement mt_pll_raise_ca53_freq() in MT8183 to raise the CPU frequency.
Move the function declaration to common header.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui
Change-Id: Ide8d767486d68177fa2bfbcc5b559879eca1bcda
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With the default CPU voltage (0.8v), CPU frequency should be 1417Mhz at
most. We have to raise CPU frequency to 1989MHz after increasing CPU
voltage to 1.05v in romstage.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui
Change-Id: I4c3e0fa27ccda8e0efe422b6ab503a1efb1697e9
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32464
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Set CPU frequency from 1100MHz to 1989MHz to improve booting time.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui
Change-Id: Id41c7ea8905c4db2537a5c32f96eb7c6b2c008ea
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32397
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The maximum CPU frequency is 1417MHz with current processor voltage
(0.8v). Set processor voltage to 1.05v for higher CPU frequency.
BUG=b:80501386
BRANCH=none
Test=Boots correctly on Kukui
Change-Id: I24ecdac2c85d3f012d9235449c0d727d727dc185
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Yidi Lin