summaryrefslogtreecommitdiff
path: root/src/lib/cbmem.c
AgeCommit message (Collapse)Author
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-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-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-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-14Tell CBMEM code about ACPI GNVS sectionStefan Reinauer
We moved GNVS to it's own section, but forgot to tell the cbmem code about it. This is purely cosmetical, but add it anyways. Change-Id: Icb3788c0325ea79cc1efff4a876412d07da7936e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1782 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-05-03Tell CBMEM pretty printer about MRC cacheStefan Reinauer
Sandybridge memory initialization produces some amount of training data that has to be kept around in CBMEM. Add a descriptive name to the CBMEM pretty printer to prevent it from just printing the hex value. Change-Id: I587c0bc3dfcf389ba298d445d2594eef73bc69a8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/990 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-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-28Include arch/acpi.h instead of manually adding acpi_slp_type.Stefan Reinauer
acpi_slp_type is defined in arch/acpi.h, so let's use that instead of manually spreading extern u8 acpi_slp_type throughout the code. Change-Id: Ia5eb420364c15ab5a764bc328bbd201ca9cb7837 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/714 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>
2011-09-12Add acpi_get_sleep_type() to i82371eb and P2B _PTS/_WAK methodsTobias Diedrich
Build fix for src/arch/i386/boot/acpi.c if !CONFIG_SMP Also check for acpi_slp_type 2 in acpi_is_wakeup, since S2 uses the same acpi wakeup vector as S3. Add _PTS/_WAK methods to turn off/on the CPU/case fans and blink the power LED while sleeping. acpi_get_sleep_type() is in a seperate file i82371eb_wakeup.c because it is used in both romstage and ramstage after patch 3/3, whereas i82371eb_early_pm.c is used only in romstage. I used the name acpi_get_sleep_type instead of acpi_is_wakeup_early because I think acpi_is_wakeup_early is a bit misleading as a name since it doesn't return a boolean value. Other chipsets so far only ever set acpi_slp_type to 0 and 3, so the added check for acpi_slp_type == 2 (resume from S2) should not change behaviour of other boards: northbridge/intel/i945/northbridge.c:256:extern u8 acpi_slp_type; northbridge/intel/i945/northbridge.c:263: acpi_slp_type=0; northbridge/intel/i945/northbridge.c:267: acpi_slp_type=3; northbridge/intel/i945/northbridge.c:271: acpi_slp_type=0; southbridge/intel/i82801gx/i82801gx_lpc.c:171:extern u8 acpi_slp_type; southbridge/via/vt8237r/vt8237r_lpc.c:149:extern u8 acpi_slp_type; southbridge/via/vt8237r/vt8237r_lpc.c:238: acpi_slp_type = ((tmp & (7 << 10)) >> 10) == 1 ? 3 : 0 ; southbridge/via/vt8237r/vt8237r_lpc.c:239: printk(BIOS_DEBUG, "SLP_TYP type was %x %x\n", tmp, acpi_slp_type); Change-Id: I13feff0b8f49aa988e5467cdbef02981f0a6be8a Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/188 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-13Following patch adds support for suspend/resume functions. I had to change ↵Rudolf Marek
the get_cbmem_toc because macro magic did not work well. The writes to NVRAM are not used in asrock board (k8 pre rev f) but they should work when used with am2 boards. In fact maybe the suspend will work on mahogany or others ;) - with some simple patch which follows for asrock. 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@6173 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-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
2010-11-10Debugging facility improvements.Uwe Hermann
- Hook up malloc() debug code via CONFIG_DEBUG_MALLOC. Only show it in menuconfig if at least DEBUG or SPEW are selected as loglevel, as this code does additional printk(BIOS_DEBUG, ...) calls which would otherwise not be visible anyway. - Similarly, make DEBUG_CAR and REALMODE_DEBUG only visible if thr DEBUG or SPEW loglevel is selected. - Get rid of a custom "debug" macro, use printk() as usual. Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6054 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-04-27Since some people disapprove of white space cleanups mixed in regular commitsStefan Reinauer
while others dislike them being extra commits, let's clean them up once and for all for the existing code. If it's ugly, let it only be ugly once :-) Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-31Consolidate ifdefs in src/lib/cbmem.c for readability.Myles Watson
Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Stefan Reinauer <stepan@coresystems.de> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5343 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-03-22printk_foo -> printk(BIOS_FOO, ...)Stefan Reinauer
Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5266 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-02-22This is a general cleanup patchStefan Reinauer
- drop include/part and move files to include/ - get rid lots of warnings - make resource allocator happy with w83627thg - trivial cbmem resume fix - fix payload and log level settings in abuild - fix kontron mptable for virtual wire mode - drop some dead includes and dead code. Signed-off-by: Stefan Reinauer <stepan@coresystems.de> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5136 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-11-12Add CONFIG_WARNINGS_ARE_ERRORS and set it for qemu.Myles Watson
Remove all remaining warnings from qemu. Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Ronald G. Minnich <rminnich@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4939 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-11-06Split the two usages of __ROMCC__:Myles Watson
__ROMCC__ now means "Don't use prototypes, since romcc doesn't support them." __PRE_RAM__ means "Use simpler versions of functions, and no device tree." There are probably some places where both are tested, but only one is needed. Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4921 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2009-10-27Remove redundant declarations. Trivial.Myles Watson
Signed-off-by: Myles Watson <mylesgw@gmail.com> Acked-by: Myles Watson <mylesgw@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4873 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-20 17:45:59 +0000