Commit graph

7 commits

Author SHA1 Message Date
Xi Chen
5c7a923757 soc/mediatek/mt8186: Support DRAM fast calibration using blob
For most MediaTek SoCs (MT8183, MT8192, MT8195) we rely on an external
program (e.g., the "DRAM blob") to do the full DRAM calibration first,
then store and and apply the generated parameters to the reference
"fast DRAM calibration" in the vendor/mediatek folder for normal system
boot.

Starting with MT8186 the implementation of fast calibration may need
to be changed, and a "DRAM blob" only path is introduced for devices
that have to do both full and fast calibration using the external blob.

TEST=fast calibration pass on kingler/krabby
BUG=b:204226005

Signed-off-by: Xi Chen <xixi.chen@mediatek.corp-partner.google.com>
Change-Id: If25a7dd6aa6261ecff79a1b4df8b1f2e53d896dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-02-09 06:02:52 +00:00
Xi Chen
f4bb77bd9e soc/mediatek: Save dramc_param header to mrc_cache
Fast-k flow may need to re-init header because mrc_cache doesn't
store header. Storing header together with dparam data is better
for data consistancy.

TEST=fast calibration pass on Corsola
BUG=b:204226005

Signed-off-by: Xi Chen <xixi.chen@mediatek.corp-partner.google.com>
Change-Id: I22982923dce06c9e770aa4f20f3dcd2f33685d84
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
2022-01-25 09:42:29 +00:00
Yu-Ping Wu
ba49444c33 soc/mediatek: Remove misleading memory logs
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>
2021-04-16 06:42:25 +00:00
Yu-Ping Wu
c074f61d8f soc/mediatek: Include sdram_info in ddr_base_info
Sync dramc_param.h with private repo mtk-dramk (CL:*3751861).

BUG=none
TEST=emerge-asurada coreboot
TEST=Hayato boots with fast calibration
BRANCH=asurada

Change-Id: I79541f66ce68a75147c22b83a456e6268ca1485e
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
2021-04-14 00:55:57 +00:00
Yu-Ping Wu
71c5ca764f soc/mediatek: Use MRC cache API for asurada
Use the MRC cache API for asurada, and sync dramc_param.h with dram
blob (CL:*3674585). With this change, the checksum, originally stored in
flash, is replaced with a hash in TPM. In addition, in recovery boot,
full calibration will always ne performed, and the cached calibration
data will be cleared from flash.

This change increases ROMSTAGE size from 236K to 264K. Most of the
increase is caused by TPM-related functions.

Add new API mtk_dram_init() to emi.h, so that 'dramc_parameter' can be
moved to soc folder.

With this CL, there is no significant change in boot time. Normal AP
reboot time (fast calibration) is consistently 0.98s as before, so
this change should not affect the result of platform_BootPerf.

BUG=b:170687062
TEST=emerge-asurada coreboot
TEST=Hayato boots with both full and fast calibration
BRANCH=none

Cq-Depend: chrome-internal:3674585, chrome-internal:3704751
Change-Id: Ief942048ce530433a57e8205d3a68ad56235b427
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51620
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
2021-03-24 05:43:50 +00:00
Julius Werner
1de8708fe5 cbfs: Remove prog_locate() for stages and rmodules
This patch removes the prog_locate() step for stages and rmodules.
Instead, the stage and rmodule loading functions will now perform the
locate step directly together with the actual loading. The long-term
goal of this is to eliminate prog_locate() (and the rdev member in
struct prog that it fills) completely in order to make CBFS verification
code safer and its security guarantees easier to follow. prog_locate()
is the main remaining use case where a raw rdev of CBFS file data
"leaks" out of cbfs.c into other code, and that other code needs to
manually make sure that the contents of the rdev get verified during
loading. By eliminating this step and moving all code that directly
deals with file data into cbfs.c, we can concentrate the code that needs
to worry about file data hashing (and needs access to cbfs_private.h
APIs) into one file, making it easier to keep track of and reason about.

This patch is the first step of this move, later patches will do the
same for SELFs and other program types.

Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia600e55f77c2549a00e2606f09befc1f92594a3a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-16 21:45:34 +00:00
Xi Chen
e8c681cc62 soc/mediatek/common: Move DRAM implementation from mt8192 to common
To reduce duplicated dram sources on seperate SOCs,
add dpm, dram_init, dramc_params, memory(fast-k or full-k)
implementations, also add dramc log level macro header files.

Signed-off-by: Xi Chen <xixi.chen@mediatek.com>
Change-Id: I557c96b3d09828472b8b6f932b0192a90894043e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
2021-03-08 01:50:11 +00:00
Renamed from src/soc/mediatek/mt8192/memory.c (Browse further)