A recent change to disable cache setup when booting from coreboot assumed that this has been done by SPL. The result is that for the coreboot board, the cache is disabled (in start.S) and never re-enabled.
If the cache was turned off, as it is on boards without SPL, we should turn it back on. Add this new condition.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add a comment about the cases
arch/x86/lib/init_helpers.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c index 67401b9ba79..f33194045f9 100644 --- a/arch/x86/lib/init_helpers.c +++ b/arch/x86/lib/init_helpers.c @@ -18,10 +18,20 @@ int init_cache_f_r(void) IS_ENABLED(CONFIG_FSP_VERSION2); int ret;
- if (!ll_boot_init()) - return 0; - - do_mtrr &= !IS_ENABLED(CONFIG_FSP_VERSION1) && + /* + * Supported configurations: + * + * booting from slimbootloader - in that case the MTRRs are already set + * up + * booting with FSPv1 - MTRRs are already set up + * booting with FSPv2 - MTRRs must be set here + * booting from coreboot - in this case there is no SPL, so we set up + * the MTRRs here + * Note: if there is an SPL, then it has already set up MTRRs so we + * don't need to do that here + */ + do_mtrr &= !IS_ENABLED(CONFIG_SPL) && + !IS_ENABLED(CONFIG_FSP_VERSION1) && !IS_ENABLED(CONFIG_SYS_SLIMBOOTLOADER);
if (do_mtrr) {