summaryrefslogtreecommitdiff
path: root/src/include/cbmem.h
AgeCommit message (Collapse)Author
2020-03-17src (minus soc and mainboard): Remove copyright noticesPatrick Georgi
They're listed in AUTHORS and often incorrect anyway, for example: - What's a "Copyright $year-present"? - Which incarnation of Google (Inc, LLC, ...) is the current copyright holder? - People sometimes have their editor auto-add themselves to files even though they only deleted stuff - Or they let the editor automatically update the copyright year, because why not? - Who is the copyright holder "The coreboot project Authors"? - Or "Generated Code"? Sidestep all these issues by simply not putting these notices in individual files, let's list all copyright holders in AUTHORS instead and use the git history to deal with the rest. Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-10lib/cbmem: Remove the cbmem_top_init() hookArthur Heymans
This hook is unused and with the need for initializing storage to share cbmem_top over other stages gone, there is likely no future need for this. Change-Id: I4ba9daea61b6d7b8949bbd2c4fb71d0a0fa20d93 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36369 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Michael Niewöhner Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-01lib/cbmem_top: Add a common cbmem_top implementationArthur Heymans
This adds a common cbmem_top implementation to all coreboot target. In romstage a static variable will be used to cache the result of cbmem_top_romstage. In ramstage if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is set a global variable needs to be populated by the stage entry with the value passed via the calling arguments. if CONFIG_RAMSTAGE_CBMEM_TOP_ARG is not set the same implementation as will be used as in romstage. Change-Id: Ie767542ee25483acc9a56785ce20a885e9a63098 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36273 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-10-27cbmem.h: Align comment with the reality of implementationsArthur Heymans
cbmem_top() should simply not be called before memory is initialed, in order for the implementation to return something meaningful. Change-Id: I8fe32844af290626a0f91279143fda4d3442680f Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36334 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Michael Niewöhner
2019-09-14arch/x86: Remove acpi_fail_wakeup() and cbmem_fail_resume()Kyösti Mälkki
Unused since commit d46b8d5. Change-Id: If0f1e0381dd7698f842dc1288ff222a4d5d4783c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35389 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-01-24cbmem_top: Fix comment and remove upper limitPatrick Rudolph
There's no such limit on 64 Bit coreboot builds. * Fix comment in cbmem.h * Remove 4 GiB limit on Cavium SoCs Tested on opencellular/elgon. Still boots Linux as payload. Change-Id: I8c9c6a5ff81bee48311e8bf8e383d1a032ea3a6d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/30609 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2019-01-16buildsystem: Promote rules.h to default includeKyösti Mälkki
Does not fix 3rdparty/, *.S or *.ld or yet. Change-Id: I66b48013dd89540b35ab219d2b64bc13f5f19cda Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/17656 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2018-12-22arch/x86 cbmem: Drop tests for LATE_CBMEM_INITKyösti Mälkki
Remove all cases in code where we tested for EARLY_CBMEM_INIT or LATE_CBMEM_INIT being set. This also removes all references to LATE_CBMEM_INIT in comments. Change-Id: I4e47fb5c8a947d268f4840cfb9c0d3596fb9ab39 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/26827 Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-08-22lib/fit_payload: Add coreboot tables support for FDT.Philipp Deppenwiese
Copy code of depthcharge boot/coreboot.c and adapt it. Tested on Cavium CN8100 EVB SFF, /sys/firmware/log is readable and prints the log. Change-Id: Ib714a021a24f51407558f484cd97aa58ecd43977 Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/28104 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-08-04lib/cbmem: provide optional cbmem top initialization hookAaron Durbin
Provide a hook to allow an optional one-time cbmem_top() initialization. The new function, cbmem_top_init(), is called on the first expected initialization of cbmem based on the Kconfig options LATE_CBMEM_INIT and EARLY_CBMEM_INIT. Change-Id: I89edd2d11f226217c8e2aaca829b4f375a2cff28 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: John Zhao <john.zhao@intel.com> Reviewed-on: https://review.coreboot.org/20847 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-08-03lib/cbmem: remove cbmem_region_used()Aaron Durbin
The cbmem_region_used() function wasn't being utilized outside this module. Threfore, reduce the surface area. Change-Id: I28a9d02221048ab0aa4cd3d986d17ee7692ce636 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/20858 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-05-27CBMEM: Clarify CBMEM_TOP_BACKUP function usageKyösti Mälkki
The deprecated LATE_CBMEM_INIT function is renamed: set_top_of_ram -> set_late_cbmem_top Obscure term top_of_ram is replaced: backup_top_of_ram -> backup_top_of_low_cacheable get_top_of_ram -> restore_top_of_low_cacheable New function that always resolves to CBMEM top boundary, with or without SMM, is named restore_cbmem_top(). Change-Id: I61d20f94840ad61e9fd55976e5aa8c27040b8fb7 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/19377 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-05-18CBMEM: Add config CBMEM_TOP_BACKUPKyösti Mälkki
AGESA and binaryPI boards have no easy way to determine correct cbmem_top() location early enough when GFXUMA is enabled, so they will use these functions with EARLY_CBMEM_INIT as well. At the end of AmdInitPost() the decisions of UMA base and size have not been written to hardware yet. The decisions are stored inside AGESA heap object we cannot locate from coreboot proper until after AmdInitEnv(). Modify code such that weak backup functions are only defined for LATE_CBMEM_INIT; they are somewhat troublesome to handle. Change-Id: Ifef4f75b36bc6dee6cd56d1d9164281d9b2a4f2a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/19306 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-03-13src/include: Move storage class to beginning of declarationLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: storage class should be at the beginning of the declaration The following storage class attribute is not detected by checkpatch.py: static cbmem_init_hook_t init_fn_ ## _ptr_ __attribute__((used, \ section(".rodata.cbmem_init_hooks"))) = init_fn_; The following lines generates a false positive: (pound)define STATIC static src/include/cpu/amd/common/cbtypes.h:60: WARNING: storage class should be at the beginning of the declaration typedef asmlinkage void (*smm_handler_t)(void *); src/include/cpu/x86/smm.h:514: WARNING: storage class should be at the beginning of the declaration (pound)define MAYBE_STATIC static src/include/stddef.h:34: WARNING: storage class should be at the beginning of the declaration TEST=Build and run on Galileo Gen2 Change-Id: Ie087d38e6171b549b90e0b831050ac44746a1e14 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18657 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-09src/include: Indent code using tabsLee Leahy
Fix the following error and warning detected by checkpatch.pl: ERROR: code indent should use tabs where possible WARNING: please, no spaces at the start of a line TEST=Build and run on Galileo Gen2 Change-Id: I487771b8f4d7e104457116b772cd32df5cd721a6 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18646 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-15lib/cbmem: allow anyone to use cbmem_possibly_online()Aaron Durbin
The cbmem_possibly_online() is a helpful construct. Therefore, push it into cbmem.h so other users can take advantage of it. BUG=chrome-os-partner:60592 BRANCH=reef Change-Id: If5a1c7815ed03874dcf141014b8ffefb82b7cc92 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17868 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-09-19arch/x86,lib: make cbmem console work in postcar stageAaron Durbin
Implement postcar stage cbmem console support. The postcar stage is more like ramstage in that RAM is already up. Therefore, in order to make the cbmem console reinit flow work one needs the cbmem init hook infrastructure in place and the cbmem recovery called. This call is added to x86/postcar.c to achieve that. Additionally, one needs to provide postcar stage cbmem init hook callbacks for the cbmem console library to use. A few other places need to become postcar stage aware so that the code paths are taken. Lastly, since postcar is backed by ram indicate that to the cbmem backing store. BUG=chrome-os-partner:57513 Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16619 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-08-27cbmem: Always maintain backing store struct in a global on non-x86Julius Werner
The current CBMEM code contains an optimization that maintains the structure with information about the CBMEM backing store in a global variable, so that we don't have to recover it from cbmem_top() again every single time we access CBMEM. However, due to the problems with using globals in x86 romstage, this optimization has only been enabled in ramstage. However, all non-x86 platforms are SRAM-based (at least for now) and can use globals perfectly fine in earlier stages. Therefore, this patch extends the optimization on those platforms to all stages. This also allows us to remove the requirement that cbmem_top() needs to return NULL before its backing store has been initialized from those boards, since the CBMEM code can now keep track of whether it has been initialized by itself. Change-Id: Ia6c1db00ae01dee485d5e96e4315cb399dc63696 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16273 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-17intel/model_206ax: Move platform specific definesKyösti Mälkki
Change-Id: I3c517fc55dd333b1a457324f1d69aeb6f70acec2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15197 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2016-06-17Move definitions of HIGH_MEMORY_SAVEKyösti Mälkki
This is more of ACPI S3 resume and x86 definition than CBMEM. Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15190 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-03-29cbmem: Add comment for cbmem_top returning NULL if backing store is not readyFurquan Shaikh
Board or chipset needs to ensure that cbmem backing store is ready when returning the cbmem top address. cbmem infrastructure has no support for checking the validity of the backing store/address. E.g.: If romstage handles cbmem coming online, chipset or board need to ensure that call to cbmem_top in romstage returns NULL if the backing store is not yet initialized. Add a comment to ensure that developers know this requirement while implementing cbmem_top for future chipsets/boards. Change-Id: I0086b8e528f65190b764a84365cf9bf970b69c3f Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14181 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-03-10cbmem: Add utility to get memory region occupied by cbmemAlexandru Gagniuc
Change-Id: I8e57c23565f173afc0f4d450579b8bfb35aeb964 Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/13363 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-03cbmem: add coreboot table records for each cbmem entryAaron Durbin
In order to not expose the cbmem data structures to userland that are used by coreboot internally add each of the cbmem entries to a coreboot table record. The payload ABI uses coreboot tables so this just provides a shortcut for cbmem entries which were manually added previously by doing the work on behalf of all entries. A cursor structure and associated functions are added to the imd code for walking the entries in order to be placed in the coreboot tables. Additionally a struct lb_cbmem_entry is added that lists the base address, size, and id of the cbmem entry. BUG=chrome-os-partner:43731 BRANCH=None TEST=Booted glados. View coreboot table entries with cbmem. Change-Id: I125940aa1898c3e99077ead0660eff8aa905b13b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11757 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-09-22coreboot: introduce commonlibAaron Durbin
Instead of reaching into src/include and re-writing code allow for cleaner code sharing within coreboot and its utilities. The additional thing needed at this point is for the utilities to provide a printk() declaration within a <console/console.h> file. That way code which uses printk() can than be mapped properly to verbosity of utility parameters. Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11592 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-06-09cbmem: add indicator to hooks if cbmem is being recoveredAaron Durbin
It can be helpful to certain users of the cbmem init hooks to know if recovery was done or not. Therefore, add this as a parameter to the hooks. Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10480 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-09cbmem: Unify CBMEM init tasks with CBMEM_INIT_HOOK() APIKyösti Mälkki
Squashed and adjusted two changes from chromium.git. Covers CBMEM init for ROMTAGE and RAMSTAGE. cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API There are several use cases for performing a certain task when CBMEM is first set up (usually to migrate some data into it that was previously kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them differently: timestamp migration is called explicitly from cbmem_initialize(), certain x86-chipset-specific tasks use the CAR_MIGRATION() macro to register a hook, and the CBMEM console is migrated through a direct call from romstage (on non-x86 and SandyBridge boards). This patch decouples the CAR_MIGRATION() hook mechanism from cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer description of what it really does. All of the above use cases are ported to this new, consistent model, allowing us to have one less line of boilerplate in non-CAR romstages. BRANCH=None BUG=None TEST=Built and booted on Nyan_Blaze and Falco with and without CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after boot (and the resume log after S3 resume on Falco). Compiled for Parrot, Stout and Lumpy. Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/232612 Reviewed-by: Aaron Durbin <adurbin@chromium.org> cbmem: Extend hooks to ramstage, fix timestamp synching Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since timestamp_sync() was no longer called there. Oops. This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism to the cbmem_initialize() call in ramstage. The macro is split into explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as possible and prevent surprises (although just using a single macro and relying on the Makefiles to link an object into all appropriate stages would also work). This allows us to get rid of the explicit cbmemc_reinit() in ramstage (which I somehow accounted for in the last patch without realizing that timestamps work exactly the same way...), and replace the older and less flexible cbmem_arch_init() mechanism. Also added a size assertion for the pre-RAM CBMEM console to memlayout that could prevent a very unlikely buffer overflow I just noticed. BRANCH=None BUG=None TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once again show up. Compile-tested for Rambi and Samus. Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/233533 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/7878 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-06-09cbmem: Break out CBMEM_ID to a separate header fileMarc Jones
The cbmem util needs the CBMEM_IDs and the strings for reporting and shares the cbmem.h file with coreboot. Split out the IDs so for a simpler sharing and no worries about overlap of standard libraries and other things in the header that coreboot requires, but the tool does not. Change-Id: Iba760c5f99c5e9838ba9426e284b59f02bcc507a Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/10430 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-05-28Add TCPA table.Vladimir Serbinenko
This allows SeaBIOS to fill it as necessary. This is needed to make BitLocker work. Change-Id: I35858cd31a90c799ee1a240547c4b4a80fa13dd8 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/10274 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-27AGESA: Split S3 backup in CBMEMKyösti Mälkki
Use separate CBMEM allocations for stack and heap on S3 resume path. The allocation of HIGH_SCRATCH_MEMORY is specific to AGESA and is moved out of globals and ACPI. This region is a replacement for BIOS_HEAP_SIZE used on non-resume paths. Change-Id: I6658ce1c06964de5cf13b4e3c84d571f46ce76f3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/10316 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-26cbmem: remove cbmem_set_top()Aaron Durbin
Now that the users of cbmem_set_top() always provide a consistent cbmem_top() value there's no need to have cbmem_set_top() around. Therefore, delete it. Change-Id: I0c96e2b8b829eddbeb1fdf755ed59c51ea689d1b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10314 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-05-26x86: provide consistent cbmem_top() for CONFIG_LATE_CBMEM_INITAaron Durbin
For x86 systems employing CONFIG_LATE_CBMEM_INIT, set_top_of_ram() is called in ramstage to note the upper address of the 32-bit address space. This in turn is consumed by cbmem. However, in this scenario cbmem_top() cannot always be relied upon because get_top_of_ram() doesn't return the same value provided to set_top_of_ram(). To fix the inconsistency in ramstage save the value passed in to set_top_of_ram() and defer to it as the return value for cbmem_top(). Change-Id: Ida796fb836c59b9776019e7f8b3f2cd71156f0e5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10313 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins)
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-13cbmem: Add initial allocation supportLee Leahy
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>
2015-05-11vboot: allow for dynamic work buffersAaron Durbin
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>
2015-04-30cbmem: Identify the FSP areas in CBMEMLee Leahy
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>
2015-04-22cbmem: switch over to imd-based cbmemAaron Durbin
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>
2015-04-22coreboot: common stage cacheAaron Durbin
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>
2015-04-22coreboot: tiered imdAaron Durbin
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>
2015-04-22coreboot: add imd libraryAaron Durbin
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>
2015-04-21Arrange CBMEM table entries' IDs alphanumericallyVadim Bendebury
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>
2015-04-02chromeos: Add WiFi calibration CBMEM entry pointer to coreboot tableVadim Bendebury
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>
2015-04-01northbridge/amd/amdfam10: Collect DIMM information for ramstage useTimothy Pearson
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>
2015-03-28arm64: add spin table supportAaron Durbin
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>
2015-03-27smbios: add funtion for smbios type17Kane Chen
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>
2015-02-06FSP & CBMEM: Fix broken cbmem CAR transition.Martin Roth
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>
2015-01-27CBMEM: Always use DYNAMIC_CBMEMKyösti Mälkki
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>
2015-01-27CBMEM: Support DYNAMIC_CBMEM with LATE_CBMEM_INITKyösti Mälkki
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)
2015-01-27CBMEM: Do not use get_top_of_ram() with DYNAMIC_CBMEMKyösti Mälkki
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>
2015-01-27CBMEM: Implement cbmem_run_init_hooks() stubKyösti Mälkki
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)
2014-12-30cbmem: use a single id to name mapping tableVadim Bendebury
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>
2014-09-11Move nehalem/sandy/ivy to per-device acpiVladimir Serbinenko
Change-Id: I3d664ab575bf9c49a7bff9a395fbab96748430d0 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6802 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2014-06-25AGESA S3: Fix ACPISCRATCH in CBMEMKyösti Mälkki
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>
2014-06-20ACPI S3 support: Add acpi_s3_resume_allowed()Kyösti Mälkki
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)
2014-05-13baytrail: snapshot power state in romstageAaron Durbin
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>
2014-03-11chromeos: provide option to dynamically allocate ram oops bufferAaron Durbin
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>
2014-03-03coreboot: introduce notion of bootmem for memory map at bootAaron Durbin
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>
2014-02-16x86: provide infrastructure to backup default SMM regionAaron Durbin
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>
2014-02-15coreboot: infrastructure for different ramstage loadersAaron Durbin
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>
2014-01-28cbmem: add reference code idsAaron Durbin
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>
2014-01-22CBMEM: Rename cbmem_reinit()Kyösti Mälkki
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>
2014-01-22CBMEM: Replace cbmem_initialize() with cbmem_recovery()Kyösti Mälkki
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)
2014-01-06CBMEM: Fix allocation for static CBMEMKyösti Mälkki
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)
2014-01-06CBMEM: Drop cbmem_base_check()Kyösti Mälkki
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>
2014-01-06CBMEM ACPI: Move resume handlerKyösti Mälkki
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>
2013-12-04Add Intel FSP northbridge support Sandybridge and IvybridgeMarc Jones
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>
2013-09-11CBMEM: Rename high_tables variables and make them staticKyösti Mälkki
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>
2013-09-11CBMEM: Drop parameters from cbmem_init()Kyösti Mälkki
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>
2013-09-11CBMEM: Drop parameter from cbmem_reinit()Kyösti Mälkki
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>
2013-09-11CBMEM x86: Unify get_cbmem_toc()Kyösti Mälkki
Remove any chipset-specific implementations and use arch-specific implementation of get_cbmem_table() instead. Change-Id: I338ee2c1bd51f5e517462115170dc926e040159e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3907 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM: Backup top_of_ram instead of cbmem_tocKyösti Mälkki
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>
2013-09-11CBMEM: Add cbmem_locate_table()Kyösti Mälkki
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>
2013-09-11CBMEM: Unify get_top_of_ram()Kyösti Mälkki
Change-Id: Ic40a51638873642f33c74d80ac41cf082b2fb177 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3904 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM tables: Remove references to global high_tables_baseKyösti Mälkki
Unify checks and writing of CBMEM tables for x86 and ARMv7. Change-Id: I89c012bce1b86d0710748719a8840ec532ce6939 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3559 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-11CBMEM: Add cbmem_late_set_table() and drop references to high_tables_baseKyösti Mälkki
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>
2013-09-11CBMEM AMD: Fix calls to set_top_of_ram_once()Kyösti Mälkki
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>
2013-09-11CBMEM AMD: Remove references to global high_tables_baseKyösti Mälkki
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>
2013-09-06usbdebug: Use CAR migrationKyösti Mälkki
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>
2013-07-11include: Fix spellingMartin Roth
Change-Id: Iadc813bc8208278996b2b1aa20cfb156ec06fac9 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3755 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-24AMD Fam15tn: Add support for AGESA runtime allocation in CBMEMRudolf Marek
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>
2013-05-16x86: add cache-as-ram migration optionAaron Durbin
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>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
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>
2013-05-01cbmem: use boot state machineAaron Durbin
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>
2013-04-01lynxpoint: Move ACPI NVS into separate CBMEM tableDuncan Laurie
The ACPI NVS region was setup in place and there was a CBMEM table that pointed to it. In order to be able to use NVS earlier the CBMEM region is allocated for NVS itself during the LPC device init and the ACPI tables point to it in CBMEM. The current cbmem region is renamed to ACPI_GNVS_PTR to indicate that it is really a pointer to the GNVS and does not actually contain the GNVS. Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2970 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22cbmem: add vboot cmbem idAaron Durbin
The vboot firmware selection from romstage will need to pass the resulting vboot data to other consumers. This will be done using a cbmem entry. Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2851 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-21cbmem: dynamic cbmem supportAaron Durbin
This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: Add cbmem_get_table_location()Aaron Durbin
When CONFIG_EARLY_CBMEM_INIT is selected romstage is supposed to have initialized cbmem. Therefore provide a weak function for the chipset to implement named cbmem_get_table_location(). When CONFIG_EARLY_CBMEM_INIT is selected cbmem_get_table_location() will be called to get the cbmem location and size. After that cbmem_initialize() is called. Change-Id: Idc45a95f9d4b1d83eb3c6d4977f7a8c80c1ffe76 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2797 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-21cbmem: add CBMEM_ID_ROMSTAGE_INFO idAaron Durbin
Introduce a new cbmem id to indicate romstage information. Proper coordination with ramstage and romstage can use this cbmem entity to communicate between one another. Change-Id: Id785f429eeff5b015188c36eb932e6a6ce122da8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2790 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-01-12Implement GCC code coverage analysisStefan Reinauer
In order to provide some insight on what code is executed during coreboot's run time and how well our test scenarios work, this adds code coverage support to coreboot's ram stage. This should be easily adaptable for payloads, and maybe even romstage. See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for more information. To instrument coreboot, select CONFIG_COVERAGE ("Code coverage support") in Kconfig, and recompile coreboot. coreboot will then store its code coverage information into CBMEM, if possible. Then, run "cbmem -CV" as root on the target system running the instrumented coreboot binary. This will create a whole bunch of .gcda files that contain coverage information. Tar them up, copy them to your build system machine, and untar them. Then you can use your favorite coverage utility (gcov, lcov, ...) to visualize code coverage. For a sneak peak of what will expect you, please take a look at http://www.coreboot.org/~stepan/coreboot-coverage/ Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2052 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-14SMM: Restore GNVS pointer in the resume pathDuncan Laurie
The SMM GNVS pointer is normally updated only when the ACPI tables are created, which does not happen in the resume path. In order to restore this pointer it needs to be available at resume time. The method used to locate it at creation time cannot be used again as that magic signature is overwritten with the address itself. So a new CBMEM ID is added to store the 32bit address so it can be found again easily. A new function is defined to save this pointer in CBMEM which needs to be called when the ACPI tables are created in each mainboard when write_acpi_tables() is called. The cpu_index variable had to be renamed due to a conflict when cpu/cpu.h is added for the smm_setup_structures() prototype. Change-Id: Ic764ff54525e12b617c1dd8d6a3e5c4f547c3e6b Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1765 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-12ELOG: Support for non-memory mapped flashDuncan Laurie
If the event log is stored in flash that is not memory mapped then it must use the SPI controller to read from the flash device instead of relying on memory accesses. In addition a new CBMEM ID is added to keep an resident copy of the ELOG around if needed. The use of CBMEM for this is guarded by a new CONFIG_ELOG_CBMEM config option. This CBMEM buffer is created and filled late in the process when the SMBIOS table is being created because CBMEM is not functional when ELOG is first initialized. The downside to using CBMEM is that events added via the SMI handler at runtime are not reflected in the CBMEM copy because I don't want to let the SMM handler write to memory outside the TSEG region. In reality the only time we add runtime events is at kernel shutdown so the impact is limited. Test: 1) Test with CONFIG_ELOG_CBMEM enabled to ensure the event log is operational and SMBIOS points to address in CBMEM. The test should involve at least on reboot to ensure that the kernel is able to write events as well. > mosys -l smbios info log | grep ^address address | 0xacedd000 > mosys eventlog list 0 | 2012-10-10 14:02:46 | Log area cleared | 4096 1 | 2012-10-10 14:02:46 | System boot | 478 2 | 2012-10-10 14:02:46 | System Reset 3 | 2012-10-10 14:03:33 | Kernel Event | Clean Shutdown 4 | 2012-10-10 14:03:34 | System boot | 479 5 | 2012-10-10 14:03:34 | System Reset 2) Test with CONFIG_ELOG_CBMEM disabled to ensure the event log is operational and SMBIOS points to memory mapped flash. The test should involve at least on reboot to ensure that the kernel is able to write events as well. > mosys -l smbios info log | grep ^address address | 0xffbf0000 > mosys eventlog list 0 | 2012-10-10 14:33:17 | Log area cleared | 4096 1 | 2012-10-10 14:33:18 | System boot | 480 2 | 2012-10-10 14:33:18 | System Reset 3 | 2012-10-10 14:33:35 | Kernel Event | Clean Shutdown 4 | 2012-10-10 14:33:36 | System boot | 481 5 | 2012-10-10 14:33:36 | System Reset Change-Id: I87755d5291ce209c1e647792227c433dc966615d Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1776 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-05-11Hook up MRC cache updateStefan Reinauer
Requirements: - must be in ramstage (locking flash while executing code from there might not work) - must be after cbmem is reinitialized (so the mrc cache copy of the current run can be found) Change-Id: I8028fb073349ce2b027ef5f8397dc1a1b8b31c02 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/1002 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-04-16S3 code in coreboot public folder.zbao
1. Move the Stack to high memory. 2. Restore the MTRR before Coreboot jump to the wakeup vector. Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: zbao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/623 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marcj303@gmail.com>
2012-04-06Add constants for fast path resume copyingStefan Reinauer
cache as ram does not usually cache the ram before it is up. Hence, if romstage.c backs up resume memory, the involved memcpy is always uncached. This makes resume very slow. On Sandybridge we copy the memory later, after enabling caching, and that allows us to resume in as little as 250ms. Change-Id: I31a71ad4468679d39880cf9a8c4e497bb7addf8f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/872 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-03-29CBMEM CONSOLE: Add CBMEM type for console buffer.Vadim Bendebury
Add CBMEM type for the console buffer section. Change-Id: I02757c06d71e46af77b02b90b0e6018a37b62406 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/720 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-29Increase CBMEM to accommodate larger console.Vadim Bendebury
This change adds 128K to the memory amount set aside for CBMEM in case the CBMEM console is enabled (to keep the CBMEM 128K byte aligned). The console buffer size is being set to 64K, which is enough to accommodate the most verbose coreboot console and u-boot console. Change-Id: If583013dfb210de5028d69577675095c6fe2f3ab Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/725 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-28Add timestamp collecting to coreboot.Vadim Bendebury
This patch adds code to initialize the time stamp collection facility in coreboot. It adds a table in the CBMEM section, which provides the base timer reading value (all other readings are offsets of this one) and an array of timestamp id/timestamp value pairs. Just two values are being added now, this will have to be used more extensively and also integrated into payloads to provide more comprehensive boot process time measurements. Also, since the CBMEM area could already contain a section (from the previous run, before reset), when processing a section addition request we should check if a section already exists and return its address, if so. Change-Id: I7ed9f5c400bc5432f228348b41fd19a67c36d533 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/713 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-29 05:26:11 +0000