| Age | Commit message (Collapse) | Author |
|---|
|
Update all of the license headers to make sure they are compliant
with coreboot's license header policy.
Change-Id: I151d058615290e528d9d1738c17804f6b9cc8dce
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14321
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The ACPI base address was being programmed sepearately from
the other BARs in the PMC device. Group all the programming
together so there isn't separate paths for programming the
relevant BARs.
Change-Id: Ib17684397fc19c42b39d066f981c01a886d65235
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14320
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Change-Id: Iee30a6efb8dcdd04affd5d1105a254781287e9e4
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14253
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The current Apollolake flow has its code executing out of
cache-as-ram for the pre-DRAM stages. This is different from
past platforms where they were just executing-in-place against
the memory-mapped SPI flash boot media. The implication is
that when cache-as-ram needs to be torn down one needs to be
executing out of DRAM since the act of cache-as-ram going
away means the code disappears out from under the processor.
Therefore load and use the postcar infrastructure to bootstrap
this process for tearing down cache-as-ram and subsequently
loading ramstage.
Change-Id: I856f4b992dd2609b95375767bfa4fe64a267d89e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14141
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Instead of having to supply CAR memory region during compilation
time it is possible to determine it in runtime. FSP2.0 blobs carry
a copy of UPD structure pre-populated with 'default' values. The
default value for StackSize is actually the real value blob needs.
Change-Id: I298e07bb12470ce659f63846ab096189138e594f
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14001
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There's no need to use a struct resource type for
fsp_find_reserved_memory(). struct resource is mainly associated
with a device and that memory is added to cbmem after memory init.
Other uses ins FSP 2.0 just use struct range_entry. Use that
instead for consistency.
Change-Id: Id7d39da1c2e23f97cdaafd7f5d281cefa6fee543
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13960
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
The memory provided to MemoryInit() for its own usage is at the
top of the CAR region.
Change-Id: I8685b5ab138182e24123b14cac6f7b32e5e784d2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13957
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
This romstage is minimalistic. Its goal is to set up some BARs
that FSP expects to be set and then invoke FSP driver to train
memory.
Change-Id: I3fa56aafe99cf6cf062a46dece3a0febeafdbfad
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13805
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
