summaryrefslogtreecommitdiff
path: root/src/include/cbmem.h
AgeCommit message (Collapse)Author
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)
2012-03-28Initialize CBMEM early.Vadim Bendebury
We want to be able to share data between different phases of firmware (rom stage/ram stage/payload). Coreboot CBMEM seems an appropriate location for this data, but normally it is not initialized until coreboot reaches the ram stage. This change initializes the CBMEM while still in rom stage in case CONFIG_EARLY_CBMEM_INIT is set. Note that there is a discrepancy in how coreboot determines the size of DRAM at rom and ram stages, get_top_of_ram() is used at rom stage and is not defined for all platforms. Those platforms will have to define this function should they enable the CONFIG_EARLY_CBMEM_INIT flag. Change-Id: I81691d45e28de59496fb227f2cca4e8c15ece717 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/711 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-09Increase size of the coreboot table areaStefan Reinauer
Packing a device tree into the coreboot table can easily make the table exceed the current limit of 8KB. However, right now there is no error handling in place to catch that case. Increase the maximum memory usable for all tables from 64KB to 128KB and increase the maximum coreboot table size from 8KB to 32KB. Change-Id: I2025bf070d0adb276c1cd610aa8402b50bdf2525 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/704 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-08-26Add automatic SMBIOS table generationSven Schnelle
Change-Id: I0ae16dda8969638a8f70fe1d2e29e992aef3a834 Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/152 Tested-by: build bot (Jenkins)
2010-12-13Compile cbmem.c instead of including it in romstage,Rudolf Marek
and do that only if resume is done. Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Acked-by: Patrick Georgi <patrick@georgi-clan.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6174 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-13We hardcode highmemory size in every northbridge! This is bad, and ↵Rudolf Marek
especially if suspend to ram is involved. Let the default be taken from cbmem.h which also handles the suspend logic. Abuild tested. Please check all changes if I did not make any wrong while converting this to bytes. Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6171 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-11Following patch makes just one fadt.c file. For SB700.Rudolf Marek
Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Acked-by: Uwe Hermann <uwe@hermann-uwe.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6165 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-221) wraps the s3 parts of chipset code/memory init code with if ↵Rudolf Marek
CONFIG_HAVE_ACPI_RESUME == 1 getting rid of ugly define in romstage.c 2) the patch implements get_cbmem_toc in chipset specific way if defined. On Intel targets it should be unchanged. On K8T890 the the cbmem_toc is read from NVRAM. Why you ask? Because we cannot do it as on intel, because the framebuffer might be there making it hard to look for it in memory (and remember we need it so early that everying is uncached) 3) The patch removes hardcoded limits for suspend/resume save area (it was 1MB) on intel. Now it computes right numbers itself. 4) it impelements saving the memory during CAR to reserved range in sane way. First the sysinfo area (CAR data) is copied, then the rest after car is disabled (cached copy is used). I changed bit also the the copy of CAR area is now done uncached for target which I feel is more right. I think I did not change the Intel suspend/resume behaviour but best would be if someone can test it. Please note this patch was unfinished on my drive since ages and it would be very nice to get it in to prevent bit rotten it again. Now I feel it is done good way and should not break anything. I did a test with abuild and it seems fine. Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Acked-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6117 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-27Add few missing prototypes, and remove few unused (thus lonelly) variables.Maciej Pijanka
TODO - x86emu need (imo) some common header with prototypes at least - clog2, ulzma, hardwaremain prototypes added by this patch probably should be moved to some header too. - in src/devices/device_util.c prototype is before function because seems, it is used only within same file, if not it should be moved to debug section of prototypes in include/device/device.h Signed-off-by: Maciej Pijanka <maciej.pijanka@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4871 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-26CBMEM high table memory manager.Stefan Reinauer
This code adds a very simple toc based memory manager for the high tables area. The purpose of this code is to make it simpler and more reliable to find certain data structures in memory. This will also make it possible to have ACPI S3 Resume working without an ugly hole at 31MB. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4860 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-28 17:32:04 +0000