Add support to allocate a region just below CBMEM root. This region is
reserved for FSP 1.1 to use for its stack and variables.
BRANCH=none
BUG=None
TEST=Build and run on Braswell
Change-Id: I1d4b36ab366e6f8e036335c56c1756f2dfaab3f5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10148
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The vboot library currently relies on link-time known
address and sizes of the work buffer. Not all platforms
can provide such semantics. Therefore, add an option
to use cbmem for the work buffer. This implies such platforms
can only do verification of the firmware after main memory
has been initialized.
Change-Id: If0b0f6b2a187b5c1fb56af08b6cb384a935be096
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10157
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add identifers and descriptions for the FSP areas within CBMEM.
BRANCH=none
BUG=None
TEST=Build for Braswell and Skylake boards using FSP 1.1.
Change-Id: I4d58f7f08cfbc17f3aef261c835b92d8d65f6622
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10026
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
By design, the imd library still provdes dynamic growth so that
feature is consistent. The imd-based cbmem packs small allocations
into a larger entry using a tiered imd. The following examples show
the reduced fragmentation and reduced memory usage.
Before with dynamic cbmem:
CBMEM ROOT 0. 023ff000 00001000
aaaabbbb 1. 023fe000 00001000
aaaabbbc 2. 023fd000 00001000
aaaabbbe 3. 023fc000 00001000
aaaacccc 4. 023fa000 00002000
aaaacccd 5. 023f9000 00001000
ROMSTAGE 6. 023f8000 00001000
CONSOLE 7. 023d8000 00020000
COREBOOT 8. 023d6000 00002000
After with tiered imd:
IMD ROOT 0. 023ff000 00001000
IMD SMALL 1. 023fe000 00001000
aaaacccc 2. 023fc000 00001060
aaaacccd 3. 023fb000 000007cf
CONSOLE 4. 023db000 00020000
COREBOOT 5. 023d9000 00002000
IMD small region:
IMD ROOT 0. 023fec00 00000400
aaaabbbb 1. 023febe0 00000020
aaaabbbc 2. 023feba0 00000040
aaaabbbe 3. 023feb20 00000080
ROMSTAGE 4. 023feb00 00000004
Side note: this CL provides a basis for what hoops one needs to
jump through when there are not writeable global variables on
a particular platform in the early stages.
Change-Id: If770246caa64b274819e45a26e100b62b9f8d2db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9169
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Many chipsets were using a stage cache for reference code
or when using a relocatable ramstage. Provide a common
API for the chipsets to use while reducing code duplication.
Change-Id: Ia36efa169fe6bd8a3dbe07bf57a9729c7edbdd46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8625
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
A tiered imd allows for both small and large allocations. The
small allocations are packed into a large region. Utilizing a
tiered imd reduces internal fragmentation within the imd.
Change-Id: I0bcd6473aacbc714844815b24d77cb5c542abdd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The imd (internal memory database) library provides a way to
track memory regions by assigning ids to each region. The implementation
is a direct descendant of dynamic cbmem. The intent is to replace
the existing mechanisms which do similar things: dynamic cbmem, stage
cache, etc.
Differences between dynamic cbmem and imd:
- All structures/objects are relative to one another. There
are no absolute pointers serialized to memory.
- Allow limiting the size of the idm. i.e. provide a maximum
memory usage.
- Allow setting the size of the root structure which allows
control of the number of allocations to track.
Change-Id: Id7438cff80d396a594d6a7330d09b45bb4fedf2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8621
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This is a no-op change just sorting the CBMEM entries' definitions for
easy look up and comparison.
BRANCH=storm
BUG=none
TEST=Booted a storm device, observed the expected CBMEM entries
present in the console output.
Change-Id: I26365285f20ecb256918277b60e178cd61dc8213
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f140fd8d85ded30d1b89f5d4c64f8b9f31d6b27b
Original-Change-Id: Ibcd4f184ef1bade10ad677384f61243da7e3c713
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225259
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9810
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This patch adds plumbing necessary to ensure that the CBMEM WiFi
calibration blobs entry, if present, is referenced if the coreboot
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none - the entry is not yet in the CBMEM
Change-Id: I072f2368b628440b6fe84f310eebc1ab945f809e
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d0330280369753a6520196425e6dfc7d7bd226a3
Original-Change-Id: I04d52934ad1c5466d0d124b32df5ab17c0f59686
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
1.) Allow MCT information structures to be copied to cbmem.
2.) Retrieve DIMM vendor, model, and serial information.
3.) Allow maximum installable memory to be set via devicetree.
Change-Id: I0aecd2fb69ebad0a784c01d40ce211f6975a3ece
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/9137
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There was a hacky and one-off spin table support in tegra132.
Make this support generic for all arm64 chips.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Ran with and without secure monitor booting smp into the kernel.
Change-Id: I3425ab0c30983d4c74d0aa465dda38bb2c91c83b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 024dc3f3e5262433a56ed14934db837b5feb1748
Original-Change-Id: If12083a9afc3b2be663d36cfeed10f9b74bae3c8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218654
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9084
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add smbios type 17 which can optionally be implemented
at the platform or mainboard level
In order to create SMBIOS type17, you will need to fill
memory_info data
BUG=None
BRANCH=None
TEST=Compile successfully on rambi and samus
Boot to chromeOS on samus and rambi
Original-Change-Id: Ie4da89135c879d7a687305d423103fcfcbb96e3f
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/210005
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 634b899ba41242caa800d7b570f3a339c738db77)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I61d1e8b1d32d43f0011b0f93966d57646ea0eb63
Reviewed-on: http://review.coreboot.org/8955
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
1) Save the pointer to the FSP HOB list to low memory at address 0x614.
This is the same location as CBMEM_RESUME_BACKUP - the two aren't used
in the same platform, so overlapping should be OK. I didn't see any
documentation that actually said that this location was free to use, and
didn't need to be restored after use in S3 resume, but it looks like
the DOS boot vector gets loaded juat above this location, so it SHOULD
be ok. The alternative is to copy the memory out and store it in cbmem
until we're ready to restore it.
2) When a request for the pointer to a CAR variable comes in, pass back
the location inside the FSP hob structure.
3) Skip the memcopy of the CAR Data. The CAR variables do not
get transitioned back into cbmem, but used out of the HOB structure.
4) Remove the BROKEN_CAR_MIGRATE Kconfig option from the FSP platform.
Change-Id: Iaf566dce1b41a3bcb17e4134877f68262b5e113f
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8196
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We can now create CBMEM with dynamic allocation even if CBMEM
location is resolved late in ramstage.
Change-Id: I8529ccbcd4a0e567ebe0a46232ac5d16476e81a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7861
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The name was always obscure and confusing. Instead define cbmem_top()
directly in the chipset code for x86 like on ARMs.
TODO: Check TSEG alignment, it used for MTRR programming.
Change-Id: Ibbe5f05ab9c7d87d09caa673766cd17d192cd045
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7888
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Until we completely can unify early_variables, use these to
handle CBMEM update hooks for both romstage and ramstage.
For x86, CAR_MIGRATE serves the purpose of romstage hooks.
Change-Id: I100ebc0e35e1b7091b4f287ca37f539fd7c9fa7a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7876
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Original-Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199791
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5217446a536bb1ba874e162c6e2e16643caa592a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d839316e9697bd3afa0b60490a840d39902dfb3
Reviewed-on: http://review.coreboot.org/7938
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
After commit
2ca2afe ACPI S3 support: Add acpi_s3_resume_allowed()
ACPISCRATCH region in CBMEM was no longer allocated, causing
AGESA platforms to fail S3 resume.
IS_ENABLED() did not evaluate true here with non-zero parameter.
Also avoid multiple defined defaults for HIGH_SCRATCH_MEMORY_SIZE.
Change-Id: Id99e4bee91581b8ac3d1ec44763b2d792b721832
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6093
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Add this to reduce the amount of preprocessor conditionals used in the source,
compiler currently resolves this to a constant.
Once we have gone through all #if CONFIG_HAVE_ACPI_RESUME cases, we may change
the implementation to enable/disable S3 support runtime.
Change-Id: I0e2d9f81e2ab87c2376a04fab38a7c951cac7a07
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6060
Tested-by: build bot (Jenkins)
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5032
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5257
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The write_coreboot_table() in coreboot_table.c was already using
struct memrange for managing and building up the entries that
eventually go into the lb_memory table. Abstract that concept
out to a bootmem memory map. The bootmem concept can then be
used as a basis for loading payloads, for example.
Change-Id: I7edbbca6bbd0568f658fde39ca93b126cab88367
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5302
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4896
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This function does not really initialize anything, but only
checks for the TOC.
Change-Id: I9d100d1823a0b630f5d1175e42a6a15f45266de4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4669
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The replacement function confirms CBMEM TOC is wiped clean on power
cycles and resets. It also introduces compatibility interface to ease
up transition to DYNAMIC_CBMEM.
Change-Id: Ic5445c5bff4aff22a43821f3064f2df458b9f250
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4668
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
CBMEM console buffer size is adjustable in menuconfig, but this would
not correctly adjust the overall allocation made for CBMEM.
HIGH_MEMORY_SIZE is aligned to 64kB and definitions are moved down in
the header file as HIGH_MEMORY_SIZE is not used with DYNAMIC_CBMEM.
Try to continue boot even if CBMEM cannot be created. This error would
only occur during development of new ports anyways and more log output
is better.
Change-Id: I4ee2df601b12ab6532ffcae8897775ecaa2fc05f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4621
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This function was for logging only, but we have both base and size
already logged elsewhere.
Change-Id: Ie6ac71fc859b8fd42fcf851c316a5f888f828dc2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Handler is ACPI/x86 specific so move details out of cbmem code.
With static CBMEM initialisation, ramstage will need to test for
S3 wakeup condition so publish also acpi_is_wakeup().
Change-Id: If591535448cdd24a54262b534c1a828fc13da759
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4619
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add support for Sandybridge and Ivybridge using the Intel FSP.
The FSP is different enough to warrant its own source files.
This source handle the majority of FSP interaction.
"Intel® Firmware Support Package (Intel® FSP) provides key
programming information for initializing Intel® silicon and can be
easily integrated into a boot loader of the developer’s choice.
It is easy to adopt, scalable to design, reduces time-to-market, and
is economical to build."
http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4015
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Old name was too much x86.
All external references have been removed.
Change-Id: I982b9abfcee57a7ea421c245dadb84342949efae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3906
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The parameters can be dropped as initialisation always happens for
the region resolved with cbmem_locate_table().
This is no longer referenced externally, make it static.
Change-Id: Ia40350a5232dcbf30aca7b5998e7995114c44551
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3565
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Function is always called with get_top_of_ram() - HIGH_MEMORY_SIZE
which equals cbmem_base, thus no need to pass it as a parameter.
Change-Id: If026cb567ff534716cd9200cdffa08b21ac0c162
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3564
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
AMD northbridges have a complex way to resolve top_of_ram.
Once it is resolved, it is stored in NVRAM to be used on resume.
TODO: Redesign these get_top_of_ram() functions from scratch.
Change-Id: I3cceb7e9b8b07620dacf138e99f98dc818c65341
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3557
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
For both romstage and ramstage, this calls an arch-specific function
get_cbmem_table() to resolve the base and size of CBMEM region. In ramstage,
the result is cached as the query may be relatively slow involving multiple PCI
configuration reads.
For x86 CBMEM tables are located right below top of low ram and
have fixed size of HIGH_MEMORY_SIZE in EARLY_CBMEM_INIT implementation.
Change-Id: Ie8d16eb30cd5c3860fff243f36bd4e7d8827a782
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This helper function is for compatibility only for chipsets that do
not implement get_top_of_ram() to support early CBMEM.
Also remove references to globals high_tables_base and _size under
arch/ and from two ARMv7 boards.
Change-Id: I17eee30635a0368b2ada06e0698425c5ef0ecc53
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3902
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We can postpone the call to set_top_of_ram_once() outside the
loops and make just one call instead.
As set_top_of_ram() is now only called once, it is no longer
necessary to check if high_tables_base was already set.
Change-Id: I302d9af52ac40c7fa8c7c7e65f82e00b031cd397
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Prepare for removal of globals high_tables_base and _size
by replacing the references with a helper function.
Added set_top_of_ram_once() may be called several times,
but only the first call (with non-zero argument) takes effect.
Change-Id: I5b5f71630f03b6a01e9c8ff96cb78e9da03e5cc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3894
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
If we already initialized EHCI controller and USB device in romstage,
locate active configuration from salvaged CAR_GLOBAL and avoid doing
the hardware initialisation again.
Change-Id: I7cb3a359488b25abc9de49c96c0197f6563a4a2c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3476
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The IOMMU AGESA needs a reserved scratch space and it wants
to allocate the stuff for runtime. So provide a simple
allocator for 4 KB CBMEM page.
Change-Id: I53bdfcd2cd69f84fbfbc6edea53a051f516c05cc
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3315
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cbmem_post_handling() function was implemented by 2
chipsets in order to save memory configuration in flash. Convert
both of these chipsets to use the boot state machine callbacks
to perform the saving of the memory configuration.
Change-Id: I697e5c946281b85a71d8533437802d7913135af3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3137
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There were previously 2 functions, init_cbmem_pre_device() and
init_cbmem_post_device(), where the 2 cbmem implementations
implemented one or the other. These 2 functions are no longer
needed to be called in the boot flow once the boot state callbacks
are utilized.
Change-Id: Ida71f1187bdcc640ae600705ddb3517e1410a80d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3136
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Lee Leahy