2020-04-02 23:48:27 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2009-10-26 18:04:28 +01:00
|
|
|
|
|
|
|
#ifndef _CBMEM_H_
|
|
|
|
#define _CBMEM_H_
|
|
|
|
|
2022-10-27 12:25:12 +02:00
|
|
|
#include <commonlib/bsd/cbmem_id.h> /* IWYU pragma: export */
|
2014-01-31 00:19:46 +01:00
|
|
|
#include <stddef.h>
|
2013-03-13 18:41:44 +01:00
|
|
|
#include <stdint.h>
|
2015-09-30 19:26:54 +02:00
|
|
|
#include <boot/coreboot_tables.h>
|
2013-03-13 18:41:44 +01:00
|
|
|
|
2016-06-15 05:15:46 +02:00
|
|
|
#define CBMEM_FSP_HOB_PTR 0x614
|
|
|
|
|
2013-03-13 18:41:44 +01:00
|
|
|
struct cbmem_entry;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The dynamic cbmem infrastructure allows for growing cbmem dynamically as
|
|
|
|
* things are added. It requires an external function, cbmem_top(), to be
|
|
|
|
* implemented by the board or chipset to define the upper address where
|
|
|
|
* cbmem lives. This address is required to be a 32-bit address. Additionally,
|
|
|
|
* the address needs to be consistent in both romstage and ramstage. The
|
2013-07-10 05:46:01 +02:00
|
|
|
* dynamic cbmem infrastructure allocates new regions below the last allocated
|
2013-03-13 18:41:44 +01:00
|
|
|
* region. Regions are defined by a cbmem_entry struct that is opaque. Regions
|
|
|
|
* may be removed, but the last one added is the only that can be removed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define DYN_CBMEM_ALIGN_SIZE (4096)
|
2015-05-08 20:33:55 +02:00
|
|
|
#define CBMEM_ROOT_SIZE DYN_CBMEM_ALIGN_SIZE
|
|
|
|
|
|
|
|
/* The root region is at least DYN_CBMEM_ALIGN_SIZE . */
|
|
|
|
#define CBMEM_ROOT_MIN_SIZE DYN_CBMEM_ALIGN_SIZE
|
|
|
|
#define CBMEM_LG_ALIGN CBMEM_ROOT_MIN_SIZE
|
|
|
|
|
|
|
|
/* Small allocation parameters. */
|
|
|
|
#define CBMEM_SM_ROOT_SIZE 1024
|
|
|
|
#define CBMEM_SM_ALIGN 32
|
|
|
|
|
|
|
|
/* Determine the size for CBMEM root and the small allocations */
|
|
|
|
static inline size_t cbmem_overhead_size(void)
|
|
|
|
{
|
2017-03-07 21:18:53 +01:00
|
|
|
return 2 * CBMEM_ROOT_MIN_SIZE;
|
2015-05-08 20:33:55 +02:00
|
|
|
}
|
2013-03-13 18:41:44 +01:00
|
|
|
|
2014-01-06 16:20:31 +01:00
|
|
|
/* By default cbmem is attempted to be recovered. Returns 0 if cbmem was
|
|
|
|
* recovered or 1 if cbmem had to be reinitialized. */
|
|
|
|
int cbmem_initialize(void);
|
2015-05-08 20:33:55 +02:00
|
|
|
int cbmem_initialize_id_size(u32 id, u64 size);
|
|
|
|
|
2013-07-10 05:46:01 +02:00
|
|
|
/* Initialize cbmem to be empty. */
|
2013-03-13 18:41:44 +01:00
|
|
|
void cbmem_initialize_empty(void);
|
2015-05-08 20:33:55 +02:00
|
|
|
void cbmem_initialize_empty_id_size(u32 id, u64 size);
|
2013-03-13 18:41:44 +01:00
|
|
|
|
|
|
|
/* Return the top address for dynamic cbmem. The address returned needs to
|
|
|
|
* be consistent across romstage and ramstage, and it is required to be
|
2019-01-02 14:04:02 +01:00
|
|
|
* below 4GiB for 32bit coreboot builds. On 64bit coreboot builds there's no
|
2019-10-25 18:06:58 +02:00
|
|
|
* upper limit. This should not be called before memory is initialized.
|
|
|
|
*/
|
2019-10-23 17:25:58 +02:00
|
|
|
/* The assumption is made that the result of cbmem_top_romstage fits in the size
|
|
|
|
of uintptr_t in the ramstage. */
|
|
|
|
extern uintptr_t _cbmem_top_ptr;
|
2013-03-13 18:41:44 +01:00
|
|
|
void *cbmem_top(void);
|
2019-10-23 17:25:58 +02:00
|
|
|
/* With CONFIG_RAMSTAGE_CBMEM_TOP_ARG set, the result of cbmem_top is passed via
|
|
|
|
* calling arguments to the next stage and saved in the global _cbmem_top_ptr
|
|
|
|
* global variable. Only a romstage callback needs to be implemented by the
|
|
|
|
* platform. It is up to the stages after romstage to save the calling argument
|
|
|
|
* in the _cbmem_top_ptr symbol. Without CONFIG_RAMSTAGE_CBMEM_TOP_ARG the same
|
|
|
|
* implementation as used in romstage will be used.
|
|
|
|
*/
|
2022-11-09 14:00:44 +01:00
|
|
|
uintptr_t cbmem_top_chipset(void);
|
2013-03-13 18:41:44 +01:00
|
|
|
|
|
|
|
/* Add a cbmem entry of a given size and id. These return NULL on failure. The
|
|
|
|
* add function performs a find first and do not check against the original
|
|
|
|
* size. */
|
|
|
|
const struct cbmem_entry *cbmem_entry_add(u32 id, u64 size);
|
|
|
|
|
|
|
|
/* Find a cbmem entry of a given id. These return NULL on failure. */
|
|
|
|
const struct cbmem_entry *cbmem_entry_find(u32 id);
|
|
|
|
|
|
|
|
/* Remove a region defined by a cbmem_entry. Returns 0 on success, < 0 on
|
|
|
|
* error. Note: A cbmem_entry cannot be removed unless it was the last one
|
|
|
|
* added. */
|
|
|
|
int cbmem_entry_remove(const struct cbmem_entry *entry);
|
|
|
|
|
|
|
|
/* cbmem_entry accessors to get pointer and size of a cbmem_entry. */
|
|
|
|
void *cbmem_entry_start(const struct cbmem_entry *entry);
|
|
|
|
u64 cbmem_entry_size(const struct cbmem_entry *entry);
|
|
|
|
|
2014-01-06 16:20:31 +01:00
|
|
|
/* Returns 0 if old cbmem was recovered. Recovery is only attempted if
|
|
|
|
* s3resume is non-zero. */
|
|
|
|
int cbmem_recovery(int s3resume);
|
2013-03-13 18:41:44 +01:00
|
|
|
/* Add a cbmem entry of a given size and id. These return NULL on failure. The
|
|
|
|
* add function performs a find first and do not check against the original
|
|
|
|
* size. */
|
2009-10-26 18:04:28 +01:00
|
|
|
void *cbmem_add(u32 id, u64 size);
|
2013-03-13 18:41:44 +01:00
|
|
|
/* Find a cbmem entry of a given id. These return NULL on failure. */
|
2009-10-26 18:04:28 +01:00
|
|
|
void *cbmem_find(u32 id);
|
2013-03-13 18:41:44 +01:00
|
|
|
|
2015-06-09 20:54:10 +02:00
|
|
|
/* Indicate to each hook if cbmem is being recovered or not. */
|
|
|
|
typedef void (* const cbmem_init_hook_t)(int is_recovery);
|
|
|
|
void cbmem_run_init_hooks(int is_recovery);
|
2014-12-18 17:30:29 +01:00
|
|
|
|
2013-03-13 18:41:44 +01:00
|
|
|
/* Ramstage only functions. */
|
2014-02-19 04:55:02 +01:00
|
|
|
/* Add the cbmem memory used to the memory map at boot. */
|
|
|
|
void cbmem_add_bootmem(void);
|
2018-08-16 00:31:26 +02:00
|
|
|
/* Return the cbmem memory used */
|
|
|
|
void cbmem_get_region(void **baseptr, size_t *size);
|
2009-10-27 15:29:29 +01:00
|
|
|
void cbmem_list(void);
|
2015-09-30 19:26:54 +02:00
|
|
|
void cbmem_add_records_to_cbtable(struct lb_header *header);
|
2009-10-26 18:04:28 +01:00
|
|
|
|
2022-03-31 06:40:10 +02:00
|
|
|
#define _CBMEM_INIT_HOOK_UNUSED(init_fn_) __attribute__((unused)) \
|
|
|
|
static cbmem_init_hook_t init_fn_ ## _unused_ = init_fn_
|
|
|
|
|
|
|
|
#define _CBMEM_INIT_HOOK(init_fn_) \
|
2016-09-16 23:23:21 +02:00
|
|
|
static cbmem_init_hook_t init_fn_ ## _ptr_ __attribute__((used, \
|
2022-03-31 06:40:10 +02:00
|
|
|
section(".rodata.cbmem_init_hooks"))) = init_fn_
|
cbmem: Unify CBMEM init tasks with CBMEM_INIT_HOOK() API
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-01-07 03:48:43 +01:00
|
|
|
|
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-21 02:00:46 +02:00
|
|
|
/* Early hooks get executed before other hooks. Use sparingly for hooks that create
|
|
|
|
CBMEM regions which need to remain in a constant location across boot modes. */
|
2022-03-31 06:40:10 +02:00
|
|
|
#define _CBMEM_INIT_HOOK_EARLY(init_fn_) \
|
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-21 02:00:46 +02:00
|
|
|
static cbmem_init_hook_t init_fn_ ## _ptr_ __attribute__((used, \
|
2022-03-31 06:40:10 +02:00
|
|
|
section(".rodata.cbmem_init_hooks_early"))) = init_fn_
|
|
|
|
|
|
|
|
/* Use CBMEM_CREATION_HOOK for code that needs to be run when cbmem is initialized
|
|
|
|
for the first time. */
|
|
|
|
#if ENV_CREATES_CBMEM
|
|
|
|
#define CBMEM_CREATION_HOOK(x) _CBMEM_INIT_HOOK(x)
|
|
|
|
#else
|
|
|
|
#define CBMEM_CREATION_HOOK(x) _CBMEM_INIT_HOOK_UNUSED(x)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Use CBMEM_READY_HOOK for code that needs to run in all stages that have cbmem. */
|
|
|
|
#if ENV_HAS_CBMEM
|
|
|
|
#define CBMEM_READY_HOOK(x) _CBMEM_INIT_HOOK(x)
|
|
|
|
#define CBMEM_READY_HOOK_EARLY(x) _CBMEM_INIT_HOOK_EARLY(x)
|
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-21 02:00:46 +02:00
|
|
|
#else
|
2022-03-31 06:40:10 +02:00
|
|
|
#define CBMEM_READY_HOOK(x) _CBMEM_INIT_HOOK_UNUSED(x)
|
|
|
|
#define CBMEM_READY_HOOK_EARLY(x) _CBMEM_INIT_HOOK_UNUSED(x)
|
|
|
|
#endif
|
cbmem: Introduce "early" init hooks for console
Over the last couple of years we have continuously added more and more
CBMEM init hooks related to different independent components. One
disadvantage of the API is that it can not model any dependencies
between the different hooks, and their order is essentially undefined
(based on link order). For most hooks this is not a problem, and in fact
it's probably not a bad thing to discourage implicit dependencies
between unrelated components like this... but one resource the
components obviously all share is CBMEM, and since many CBMEM init hooks
are used to create new CBMEM areas, the arbitrary order means that the
order of these areas becomes unpredictable.
Generally code using CBMEM should not care where exactly an area is
allocated, but one exception is the persistent CBMEM console which
relies (on a best effort basis) on always getting allocated at the same
address on every boot. This is, technically, a hack, but it's a pretty
harmless hack that has served us reasonably well so far and would be
difficult to realize in a more robust way (without adding a lot of new
infrastructure). Most of the time, coreboot will allocate the same CBMEM
areas in the same order with the same sizes on every boot, and this all
kinda works out (and since it's only a debug console, we don't need to
be afraid of the odd one-in-a-million edge case breaking it).
But one reproducible difference we can have between boots is the vboot
boot mode (e.g. normal vs. recovery boot), and we had just kinda gotten
lucky in the past that we didn't have differences in CBMEM allocations
in different boot modes. With the recent addition of the RW_MCACHE
(which does not get allocated in recovery mode), this is no longer true,
and as a result CBMEM consoles can no longer persist between normal and
recovery modes.
The somewhat kludgy but simple solution is to just create a new class of
specifically "early" CBMEM init hooks that will always run before all
the others. While arbitrarily partitioning hooks into "early" and "not
early" without any precise definition of what these things mean may seem
a bit haphazard, I think it will be good enough in practice for the very
few cases where this matters and beats building anything much more
complicated (FWIW Linux has been doing something similar for years with
device suspend/resume ordering). Since the current use case only relates
to CBMEM allocation ordering and you can only really be "first" if you
allocate in romstage, the "early" hook is only available in romstage for
now (could be expanded later if we find a use case for it).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If2c849a89f07a87d448ec1edbad4ce404afb0746
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2021-05-21 02:00:46 +02:00
|
|
|
|
2016-12-14 21:40:43 +01:00
|
|
|
/*
|
|
|
|
* Returns 0 for the stages where we know that cbmem does not come online.
|
|
|
|
* Even if this function returns 1 for romstage, depending upon the point in
|
|
|
|
* bootup, cbmem might not actually be online.
|
|
|
|
*/
|
|
|
|
static inline int cbmem_possibly_online(void)
|
|
|
|
{
|
|
|
|
if (ENV_BOOTBLOCK)
|
|
|
|
return 0;
|
|
|
|
|
2020-06-04 05:06:58 +02:00
|
|
|
if (ENV_SEPARATE_VERSTAGE && !CONFIG(VBOOT_STARTS_IN_ROMSTAGE))
|
2016-12-14 21:40:43 +01:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-02-06 18:27:50 +01:00
|
|
|
/* Returns 1 after running cbmem init hooks, 0 otherwise. */
|
|
|
|
static inline int cbmem_online(void)
|
|
|
|
{
|
|
|
|
extern int cbmem_initialized;
|
|
|
|
|
|
|
|
if (!cbmem_possibly_online())
|
|
|
|
return 0;
|
|
|
|
|
2020-12-07 23:57:01 +01:00
|
|
|
return cbmem_initialized;
|
2020-02-06 18:27:50 +01:00
|
|
|
}
|
|
|
|
|
2013-03-13 18:41:44 +01:00
|
|
|
#endif /* _CBMEM_H_ */
|