[coreboot-gerrit] Patch merged into coreboot/master: df3a109 cbmem: dynamic cbmem support

[gerrit at coreboot.org]

the following patch was just integrated into master:
commit df3a109b72907419d503c81257ea241becdbb915
Author: Aaron Durbin <adurbin at chromium.org>
Date:   Wed Mar 13 12:41:44 2013 -0500

    cbmem: dynamic cbmem support
    
    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 at chromium.org>
    Reviewed-on: http://review.coreboot.org/2848
    Tested-by: build bot (Jenkins)
    Reviewed-by: Ronald G. Minnich <rminnich at gmail.com>

Build-Tested: build bot (Jenkins) at Wed Mar 20 23:30:02 2013, giving +1
Reviewed-By: Ronald G. Minnich <rminnich at gmail.com> at Thu Mar 21 23:24:19 2013, giving +2
See http://review.coreboot.org/2848 for details.

-gerrit