7f8afe0631
Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
67 lines
2.1 KiB
Text
67 lines
2.1 KiB
Text
/*
|
|
* This file is part of the coreboot project.
|
|
*
|
|
* Copyright 2015 Google Inc
|
|
*
|
|
* 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.
|
|
*
|
|
* This program is distributed in the hope that it will be useful,
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
* GNU General Public License for more details.
|
|
*/
|
|
|
|
#include <memlayout.h>
|
|
#include <arch/header.ld>
|
|
|
|
SECTIONS
|
|
{
|
|
/*
|
|
* It would be good to lay down RAMSTAGE, ROMSTAGE, etc consecutively
|
|
* like other architectures/chipsets it's not possible because of
|
|
* the linking games played during romstage creation by trying
|
|
* to find the final landing place in CBFS for XIP. Therefore,
|
|
* conditionalize with macros.
|
|
*/
|
|
#if ENV_RAMSTAGE
|
|
RAMSTAGE(CONFIG_RAMBASE, CONFIG_RAMTOP - CONFIG_RAMBASE)
|
|
|
|
#elif ENV_ROMSTAGE
|
|
/* The 1M size is not allocated. It's just for basic size checking.
|
|
* Link at 32MiB address and rely on cbfstool to relocate to XIP. */
|
|
ROMSTAGE(CONFIG_ROMSTAGE_ADDR, 1M)
|
|
|
|
/* Pull in the cache-as-ram rules. */
|
|
#include "car.ld"
|
|
#elif ENV_VERSTAGE
|
|
/* The 1M size is not allocated. It's just for basic size checking.
|
|
* Link at 32MiB address and rely on cbfstool to relocate to XIP. */
|
|
VERSTAGE(CONFIG_VERSTAGE_ADDR, 1M)
|
|
|
|
/* Pull in the cache-as-ram rules. */
|
|
#include "car.ld"
|
|
#elif ENV_BOOTBLOCK
|
|
/* This is for C_ENVIRONMENT_BOOTBLOCK. arch/x86/bootblock.ld contains
|
|
* the logic for the romcc linking. */
|
|
BOOTBLOCK(0xffffffff - CONFIG_C_ENV_BOOTBLOCK_SIZE + 1,
|
|
CONFIG_C_ENV_BOOTBLOCK_SIZE)
|
|
|
|
/* Pull in the cache-as-ram rules. */
|
|
#include "car.ld"
|
|
|
|
#elif ENV_POSTCAR
|
|
POSTCAR(32M, 1M)
|
|
#endif
|
|
}
|
|
|
|
#if ENV_BOOTBLOCK
|
|
/* Bootblock specific scripts which provide more SECTION directives. */
|
|
#include <cpu/x86/16bit/entry16.ld>
|
|
#include <cpu/x86/16bit/reset16.ld>
|
|
#include <arch/x86/id.ld>
|
|
#if IS_ENABLED(CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE)
|
|
#include <cpu/intel/fit/fit.ld>
|
|
#endif
|
|
#endif /* ENV_BOOTBLOCK */
|