e8d8d9492d
* Remove empty security.md * Remove second H1 header from lib/index.md * Move two documents in appropriate subfolders * Fix file path * Drop document overview Change-Id: I0e9df6203e82003c01b84967ea6bd779d7583fef Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Martin Roth <martinroth@google.com>
1.2 KiB
ABI data consumption
This text describes the ABI coreboot presents to downstream users. Such users are payloads and/or operating systems. Therefore, this text serves at what can be relied on for downstream consumption. Anything not explicitly listed as consumable is subject to change without notice.
Background and Usage
coreboot passes information to downstream users using coreboot tables. These
table definitions can be found in
./src/commonlib/include/commonlib/coreboot_tables.h and
./payloads/libpayload/include/coreboot_tables.h respectively within coreboot
and libpayload. One of the most vital and important pieces of information
found within these tables is the memory map of the system indicating
available and reserved memory.
In 2009 cbmem was added to coreboot. The "CBMEM high table memory manager" serves a way for coreboot to bookkeep its own internal data. While some of this data may be exposed through the coreboot tables the data structures used to manage the data within the cbmem area is subject to change.
Provided the above, if one needs a piece of data exposed to the OS or payload it should reside within the coreboot tables. If it isn't there then a code change will be required to add it to the coreboot tables.