coreboot-gerrit March 2013

coreboot-gerrit@coreboot.org

1 participants
443 discussions

Patch merged into coreboot/master: 0135702 x86: mark .textfirst as allocatable and executable
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit 0135702802601c19937eec57513f3a6e2f4d1e00 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 20:23:17 2013 -0500 x86: mark .textfirst as allocatable and executable When the linking of ramstage was changed to use an intermeidate object with all ramstage objects in it the .textfirst section was introduced to keep the entry point at 0. However, the section was not marked allocatable or executable. Nor was it marked as @progbits. That didn't cause an issue on its own since .textfirst was directly called out in the linker script. However, the rmodule infrastructure relies on all the relocation entries being included in the rmodule. Without the proper section attributes the .rel.textfirst section entries were not being included in the final ramstage rmodule. Change-Id: I54e7055a19bee6c86e269eba047d9a560702afde Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2885 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 04:05:02 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:38:52 2013, giving +2 See http://review.coreboot.org/2885 for details. -gerrit

1 0

Patch merged into coreboot/master: b467f1d relocatable ramstage: fix linking
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit b467f1ddafb0ad4769b5d51b88563966af7d563c Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 19:59:52 2013 -0500 relocatable ramstage: fix linking The ramstage is now linked using an intermediate object that is created from the complete list of ramstage object files. The rmodule code was developed when ramstage was linked using an archive file. Because of the fact that the rmodule headers are not referenced from any other object the link could start by specifying the rmodule header object for ramstage. That, however, is not the case as all ramstage objects are included in the intermediate linked object. Therefore, the ramstage_module_header.ramstage.o object file needs to be removed from the object list for the ramstage rmodule. Change-Id: I6a79b6f8dd1dbfe40fdc7753297243c3c9b45fae Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2884 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 03:52:32 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:37:41 2013, giving +2 See http://review.coreboot.org/2884 for details. -gerrit

1 0

Patch merged into coreboot/master: c875e2a vboot module: fix compilation issues
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit c875e2aaabb1226b0ecbf98df6112ef8ce28dd41 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 19:48:39 2013 -0500 vboot module: fix compilation issues There were 3 things stopping the vboot module from being compiled: 1. The vboot_reference code removed in the firmware/arch/$(ARCH)/include directory. This caused romcc to fail because romcc fails if -I<dir> points to non-existent directory. 2. The rmodule API does not have the no-clearing-of-bss variant of the load function. 3. cbfs API changes. Change-Id: I1e1296c71c5831d56fc9acfaa578c84a948b4ced Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2881 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 03:08:00 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:34:57 2013, giving +2 See http://review.coreboot.org/2881 for details. -gerrit

1 0

Patch merged into coreboot/master: 1989b4b x86: expose console_tx_flush in romstage
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit 1989b4bd560045b524fad2f5d189907e4a8abe26 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 19:52:42 2013 -0500 x86: expose console_tx_flush in romstage The vboot module relied on being able to flush the console after it called vtxprintf() from its log wrapper function. Expose the console_tx_flush() function in romstage so the vboot module can ensure messages are flushed. Change-Id: I578053df4b88c2068bd9cc90eea5573069a0a4e8 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2882 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 03:25:31 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:35:54 2013, giving +2 See http://review.coreboot.org/2882 for details. -gerrit

1 0

Patch merged into coreboot/master: d23e292 rmodule: align ld script with latest x86 ld script
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit d23e292ef624ae1000b700399ece00c72946ede1 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 19:55:35 2013 -0500 rmodule: align ld script with latest x86 ld script The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 03:38:57 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:36:18 2013, giving +2 See http://review.coreboot.org/2883 for details. -gerrit

1 0

Patch merged into coreboot/master: 2bd2e37 cbfs: fix relocation ramstage compiler errors
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit 2bd2e37536a7bc31023233cf3b7c6682cbd8176b Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 19:46:16 2013 -0500 cbfs: fix relocation ramstage compiler errors There were some cbfs calls that did not get transitioned to the new cbfs API. Fix the callsites to conform to the actual cbfs, thus fixing the copilation errors. Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2880 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 02:54:46 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:34:15 2013, giving +2 See http://review.coreboot.org/2880 for details. -gerrit

1 0

Patch merged into coreboot/master: 73982c3 xcompile: honor LINKER_SUFFIX variable
by gerrit＠coreboot.org 23 Mar '13

23 Mar '13

the following patch was just integrated into master: commit 73982c3c685395b74b611cde7f13f0145b8c0a4d Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Mar 22 19:35:56 2013 -0500 xcompile: honor LINKER_SUFFIX variable In commit e820e5cb3aed810fa9ba6047ce9b8bf352335e32 titled "Make xcompile support multiple architectures" the LINKER_SUFFIX variable was introduced to bypass gold if the bfd linker was available. However, the LINKER_SUFFIX wasn't honored when the compiler evironment variables were set. Fix the original intention. Change-Id: I608f1e0cc3d0bea3ba1e51b167d88c66d266bceb Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2879 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Sat Mar 23 02:41:09 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sat Mar 23 19:32:43 2013, giving +2 See http://review.coreboot.org/2879 for details. -gerrit

1 0

New patch to review for coreboot: 1a63f0b x86: dynamic cbmem: fix acpi reservations
by Aaron Durbin 23 Mar '13

23 Mar '13

Aaron Durbin (adurbin(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2897 -gerrit commit 1a63f0b0fe329cfd2324ccf0a4f918e9317287ee Author: Aaron Durbin <adurbin(a)chromium.org> Date: Sat Mar 23 00:12:19 2013 -0500 x86: dynamic cbmem: fix acpi reservations If a configuration was not using RELOCTABLE_RAMSTAGE, but it was using HAVE_ACPI_RESUME then the ACPI memory was not being marked as reserved to the OS. The reason is that memory is marked as reserved during write_coreboot_table(). These reservations were being added to cbmem after the call to write_coreboot_table(). In the non-dynamic cbmem case this sequence is fine because cbmem area is a fixed size and is already reserved. For the dynamic cbmem case that no longer holds by the nature of the dynamic cbmem. Change-Id: I9aa44205205bfef75a9e7d9f02cf5c93d7c457b2 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> --- src/arch/x86/boot/tables.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/src/arch/x86/boot/tables.c b/src/arch/x86/boot/tables.c index 4448333..6355a1b 100644 --- a/src/arch/x86/boot/tables.c +++ b/src/arch/x86/boot/tables.c @@ -203,6 +203,22 @@ struct lb_memory *write_tables(void) } #endif + post_code(0x9e); + +#if CONFIG_HAVE_ACPI_RESUME +/* Only add CBMEM_ID_RESUME when the ramstage isn't relocatable. */ +#if !CONFIG_RELOCATABLE_RAMSTAGE + /* Let's prepare the ACPI S3 Resume area now already, so we can rely on + * it begin there during reboot time. We don't need the pointer, nor + * the result right now. If it fails, ACPI resume will be disabled. + */ + cbmem_add(CBMEM_ID_RESUME, HIGH_MEMORY_SAVE); +#endif +#if CONFIG_NORTHBRIDGE_AMD_AGESA_FAMILY14 || CONFIG_NORTHBRIDGE_AMD_AGESA_FAMILY15_TN + cbmem_add(CBMEM_ID_RESUME_SCRATCH, CONFIG_HIGH_SCRATCH_MEMORY_SIZE); +#endif +#endif + #define MAX_COREBOOT_TABLE_SIZE (32 * 1024) post_code(0x9d); @@ -230,22 +246,6 @@ struct lb_memory *write_tables(void) rom_table_start, rom_table_end); } - post_code(0x9e); - -#if CONFIG_HAVE_ACPI_RESUME -/* Only add CBMEM_ID_RESUME when the ramstage isn't relocatable. */ -#if !CONFIG_RELOCATABLE_RAMSTAGE - /* Let's prepare the ACPI S3 Resume area now already, so we can rely on - * it begin there during reboot time. We don't need the pointer, nor - * the result right now. If it fails, ACPI resume will be disabled. - */ - cbmem_add(CBMEM_ID_RESUME, HIGH_MEMORY_SAVE); -#endif -#if CONFIG_NORTHBRIDGE_AMD_AGESA_FAMILY14 || CONFIG_NORTHBRIDGE_AMD_AGESA_FAMILY15_TN - cbmem_add(CBMEM_ID_RESUME_SCRATCH, CONFIG_HIGH_SCRATCH_MEMORY_SIZE); -#endif -#endif - #if CONFIG_MULTIBOOT post_code(0x9d);

1 0

New patch to review for coreboot: 7823cef coreboot table: use memrange library
by Aaron Durbin 23 Mar '13

23 Mar '13

Aaron Durbin (adurbin(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2896 -gerrit commit 7823cef95619e5ee8c09270bea513df01186ffa5 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Sat Mar 23 00:06:36 2013 -0500 coreboot table: use memrange library Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Ic667df444586c2b5b5f2ee531370bb790d683a42 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> --- src/lib/coreboot_table.c | 271 +++++++++-------------------------------------- 1 file changed, 53 insertions(+), 218 deletions(-) diff --git a/src/lib/coreboot_table.c b/src/lib/coreboot_table.c index 84eb5a6..840470b 100644 --- a/src/lib/coreboot_table.c +++ b/src/lib/coreboot_table.c @@ -29,6 +29,7 @@ #include <stdlib.h> #include <cbfs.h> #include <cbmem.h> +#include <memrange.h> #if CONFIG_USE_OPTION_TABLE #include <option_table.h> #endif @@ -356,54 +357,7 @@ static struct lb_forward *lb_forward(struct lb_header *header, struct lb_header return forward; } -static void lb_memory_range(struct lb_memory *mem, - uint32_t type, uint64_t start, uint64_t size) -{ - int entries; - entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); - mem->map[entries].start = pack_lb64(start); - mem->map[entries].size = pack_lb64(size); - mem->map[entries].type = type; - mem->size += sizeof(mem->map[0]); -} - -static void lb_reserve_table_memory(struct lb_header *head) -{ -/* Dynamic cbmem has already reserved the memory where the coreboot tables - * reside. Therefore, there is nothing to fix up. */ -#if !CONFIG_DYNAMIC_CBMEM - struct lb_record *last_rec; - struct lb_memory *mem; - uint64_t start; - uint64_t end; - int i, entries; - - last_rec = lb_last_record(head); - mem = get_lb_mem(); - start = (unsigned long)head; - end = (unsigned long)last_rec; - entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); - /* Resize the right two memory areas so this table is in - * a reserved area of memory. Everything has been carefully - * setup so that is all we need to do. - */ - for(i = 0; i < entries; i++ ) { - uint64_t map_start = unpack_lb64(mem->map[i].start); - uint64_t map_end = map_start + unpack_lb64(mem->map[i].size); - /* Does this area need to be expanded? */ - if (map_end == start) { - mem->map[i].size = pack_lb64(end - map_start); - } - /* Does this area need to be contracted? */ - else if (map_start == start) { - mem->map[i].start = pack_lb64(end); - mem->map[i].size = pack_lb64(map_end - end); - } - } -#endif -} - -static unsigned long lb_table_fini(struct lb_header *head, int fixup) +static unsigned long lb_table_fini(struct lb_header *head) { struct lb_record *rec, *first_rec; rec = lb_last_record(head); @@ -411,9 +365,6 @@ static unsigned long lb_table_fini(struct lb_header *head, int fixup) head->table_bytes += rec->size; } - if (fixup) - lb_reserve_table_memory(head); - first_rec = lb_first_record(head); head->table_checksum = compute_ip_checksum(first_rec, head->table_bytes); head->header_checksum = 0; @@ -424,128 +375,53 @@ static unsigned long lb_table_fini(struct lb_header *head, int fixup) return (unsigned long)rec + rec->size; } -static void lb_cleanup_memory_ranges(struct lb_memory *mem) -{ - int entries; - int i, j; - entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); - - /* Sort the lb memory ranges */ - for(i = 0; i < entries; i++) { - uint64_t entry_start = unpack_lb64(mem->map[i].start); - for(j = i + 1; j < entries; j++) { - uint64_t temp_start = unpack_lb64(mem->map[j].start); - if (temp_start < entry_start) { - struct lb_memory_range tmp; - tmp = mem->map[i]; - mem->map[i] = mem->map[j]; - mem->map[j] = tmp; - } - } - } +/* Routines to extract part so the coreboot table or + * information from the coreboot table after we have written it. + * Currently get_lb_mem relies on a global we can change the + * implementaiton. + */ +static struct lb_memory *mem_ranges = NULL; - /* Merge adjacent entries */ - for(i = 0; (i + 1) < entries; i++) { - uint64_t start, end, nstart, nend; - if (mem->map[i].type != mem->map[i + 1].type) { - continue; - } - start = unpack_lb64(mem->map[i].start); - end = start + unpack_lb64(mem->map[i].size); - nstart = unpack_lb64(mem->map[i + 1].start); - nend = nstart + unpack_lb64(mem->map[i + 1].size); - if ((start <= nstart) && (end >= nstart)) { - if (start > nstart) { - start = nstart; - } - if (end < nend) { - end = nend; - } - /* Record the new region size */ - mem->map[i].start = pack_lb64(start); - mem->map[i].size = pack_lb64(end - start); - - /* Delete the entry I have merged with */ - memmove(&mem->map[i + 1], &mem->map[i + 2], - ((entries - i - 2) * sizeof(mem->map[0]))); - mem->size -= sizeof(mem->map[0]); - entries -= 1; - /* See if I can merge with the next entry as well */ - i -= 1; - } - } +struct lb_memory *get_lb_mem(void) +{ + return mem_ranges; } -static void lb_remove_memory_range(struct lb_memory *mem, - uint64_t start, uint64_t size) +/* This structure keeps track of the coreboot table memory ranges. */ +static struct memory_ranges lb_ranges; + +static struct lb_memory *build_lb_mem(struct lb_header *head) { - uint64_t end; - int entries; - int i; + struct lb_memory *mem; - end = start + size; - entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); - - /* Remove a reserved area from the memory map */ - for(i = 0; i < entries; i++) { - uint64_t map_start = unpack_lb64(mem->map[i].start); - uint64_t map_end = map_start + unpack_lb64(mem->map[i].size); - if ((start <= map_start) && (end >= map_end)) { - /* Remove the completely covered range */ - memmove(&mem->map[i], &mem->map[i + 1], - ((entries - i - 1) * sizeof(mem->map[0]))); - mem->size -= sizeof(mem->map[0]); - entries -= 1; - /* Since the index will disappear revisit what will appear here */ - i -= 1; - } - else if ((start > map_start) && (end < map_end)) { - /* Split the memory range */ - memmove(&mem->map[i + 1], &mem->map[i], - ((entries - i) * sizeof(mem->map[0]))); - mem->size += sizeof(mem->map[0]); - entries += 1; - /* Update the first map entry */ - mem->map[i].size = pack_lb64(start - map_start); - /* Update the second map entry */ - mem->map[i + 1].start = pack_lb64(end); - mem->map[i + 1].size = pack_lb64(map_end - end); - /* Don't bother with this map entry again */ - i += 1; - } - else if ((start <= map_start) && (end > map_start)) { - /* Shrink the start of the memory range */ - mem->map[i].start = pack_lb64(end); - mem->map[i].size = pack_lb64(map_end - end); - } - else if ((start < map_end) && (start > map_start)) { - /* Shrink the end of the memory range */ - mem->map[i].size = pack_lb64(start - map_start); - } - } -} + /* Record where the lb memory ranges will live */ + mem = lb_memory(head); + mem_ranges = mem; -void lb_add_memory_range(struct lb_memory *mem, - uint32_t type, uint64_t start, uint64_t size) -{ - lb_remove_memory_range(mem, start, size); - lb_memory_range(mem, type, start, size); - lb_cleanup_memory_ranges(mem); + /* Fill the memory map out. The order of operations is important in + * that each overlapping range will take over the next. Therefore, + * add cacheable resources as RAM then add the reserved resources. */ + memory_ranges_init(&lb_ranges, IORESOURCE_CACHEABLE, + IORESOURCE_CACHEABLE, LB_MEM_RAM); + memory_ranges_add_resources(&lb_ranges, IORESOURCE_RESERVE, + IORESOURCE_RESERVE, LB_MEM_RESERVED); + + return mem; } -static void lb_dump_memory_ranges(struct lb_memory *mem) +static void commit_lb_memory(struct lb_memory *mem) { - int entries; + struct memory_range *r; + struct lb_memory_range *lb_r; int i; - entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]); - printk(BIOS_DEBUG, "coreboot memory table:\n"); - for(i = 0; i < entries; i++) { - uint64_t entry_start = unpack_lb64(mem->map[i].start); - uint64_t entry_size = unpack_lb64(mem->map[i].size); + lb_r = &mem->map[0]; + i = 0; + + memory_ranges_each_entry(r, &lb_ranges) { const char *entry_type; - switch (mem->map[i].type) { + switch (memory_range_tag(r)) { case LB_MEM_RAM: entry_type="RAM"; break; case LB_MEM_RESERVED: entry_type="RESERVED"; break; case LB_MEM_ACPI: entry_type="ACPI"; break; @@ -557,58 +433,25 @@ static void lb_dump_memory_ranges(struct lb_memory *mem) } printk(BIOS_DEBUG, "%2d. %016llx-%016llx: %s\n", - i, entry_start, entry_start+entry_size-1, entry_type); + i, memory_range_base(r), memory_range_end(r)-1, + entry_type); - } -} - -/* Routines to extract part so the coreboot table or - * information from the coreboot table after we have written it. - * Currently get_lb_mem relies on a global we can change the - * implementaiton. - */ -static struct lb_memory *mem_ranges = NULL; - -struct lb_memory *get_lb_mem(void) -{ - return mem_ranges; -} + lb_r->start = pack_lb64(memory_range_base(r)); + lb_r->size = pack_lb64(memory_range_size(r)); + lb_r->type = memory_range_tag(r); -static void build_lb_mem_range(void *gp, struct device *dev, struct resource *res) -{ - struct lb_memory *mem = gp; - lb_memory_range(mem, LB_MEM_RAM, res->base, res->size); -} - -static struct lb_memory *build_lb_mem(struct lb_header *head) -{ - struct lb_memory *mem; - - /* Record where the lb memory ranges will live */ - mem = lb_memory(head); - mem_ranges = mem; - - /* Build the raw table of memory */ - search_global_resources( - IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM | IORESOURCE_CACHEABLE, - build_lb_mem_range, mem); - lb_cleanup_memory_ranges(mem); - return mem; + i++; + lb_r++; + mem->size += sizeof(struct lb_memory_range); + } } -static void lb_add_rsvd_range(void *gp, struct device *dev, struct resource *res) +void lb_add_memory_range(struct lb_memory *mem, + uint32_t type, uint64_t start, uint64_t size) { - struct lb_memory *mem = gp; - lb_add_memory_range(mem, LB_MEM_RESERVED, res->base, res->size); + insert_memory_range(&lb_ranges, start, size, type); } -static void add_lb_reserved(struct lb_memory *mem) -{ - /* Add reserved ranges */ - search_global_resources( - IORESOURCE_MEM | IORESOURCE_RESERVE, IORESOURCE_MEM | IORESOURCE_RESERVE, - lb_add_rsvd_range, mem); -} unsigned long write_coreboot_table( unsigned long low_table_start, unsigned long low_table_end, @@ -623,7 +466,7 @@ unsigned long write_coreboot_table( head = lb_table_init(low_table_end); lb_forward(head, (struct lb_header*)rom_table_end); - low_table_end = (unsigned long) lb_table_fini(head, 0); + low_table_end = (unsigned long) lb_table_fini(head); printk(BIOS_DEBUG, "Table forward entry ends at 0x%08lx.\n", low_table_end); low_table_end = ALIGN(low_table_end, 4096); @@ -682,17 +525,9 @@ unsigned long write_coreboot_table( high_tables_base, high_tables_size); #endif /* CONFIG_DYNAMIC_CBMEM */ - /* Add reserved regions */ - add_lb_reserved(mem); - - lb_dump_memory_ranges(mem); - - /* Note: - * I assume that there is always memory at immediately after - * the low_table_end. This means that after I setup the coreboot table. - * I can trivially fixup the reserved memory ranges to hold the correct - * size of the coreboot table. - */ + /* No other memory areas can be added after the memory table has been + * committed as the entries won't show up in the serialize mem table. */ + commit_lb_memory(mem); /* Record our motherboard */ lb_mainboard(head); @@ -721,5 +556,5 @@ unsigned long write_coreboot_table( add_cbmem_pointers(head); /* Remember where my valid memory ranges are */ - return lb_table_fini(head, 1); + return lb_table_fini(head); }

1 0

New patch to review for coreboot: 3a73b5d dynamic cbmem: fix memconsole and timestamps
by Aaron Durbin 23 Mar '13

23 Mar '13

Aaron Durbin (adurbin(a)google.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2895 -gerrit commit 3a73b5de23b9c67bc21bb42b30d1aa63d7b27a0c Author: Aaron Durbin <adurbin(a)chromium.org> Date: Sat Mar 23 00:00:54 2013 -0500 dynamic cbmem: fix memconsole and timestamps There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM rely on EARLY_CBMEM_INIT. This isn't true in the face of DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT. Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem implementation when COLLECT_TIMESTAMPS is selected. Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> --- src/Kconfig | 2 +- src/console/Kconfig | 2 +- src/lib/Makefile.inc | 3 ++- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index 18b5bad..c3cc6bf 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -189,7 +189,7 @@ config DYNAMIC_CBMEM config COLLECT_TIMESTAMPS bool "Create a table of timestamps collected during boot" - depends on EARLY_CBMEM_INIT + depends on (EARLY_CBMEM_INIT || DYNAMIC_CBMEM) help Make coreboot create a table of timer-ID/timer-value pairs to allow measuring time spent at different phases of the boot process. diff --git a/src/console/Kconfig b/src/console/Kconfig index 7fbed4a..d2cff57 100644 --- a/src/console/Kconfig +++ b/src/console/Kconfig @@ -219,7 +219,7 @@ config CONSOLE_NE2K_IO_PORT boundary, qemu needs broader align) config CONSOLE_CBMEM - depends on EARLY_CBMEM_INIT + depends on (EARLY_CBMEM_INIT || DYNAMIC_CBMEM) bool "Send console output to a CBMEM buffer" default n help diff --git a/src/lib/Makefile.inc b/src/lib/Makefile.inc index e8ed4f4..9d3588e 100644 --- a/src/lib/Makefile.inc +++ b/src/lib/Makefile.inc @@ -47,7 +47,8 @@ romstage-$(CONFIG_CONSOLE_SERIAL8250MEM) += uart8250mem.c romstage-$(CONFIG_CONSOLE_CBMEM) += cbmem_console.c romstage-$(CONFIG_CONSOLE_NE2K) += ne2k.c romstage-$(CONFIG_USBDEBUG) += usbdebug.c -romstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c cbmem.c +romstage-$(CONFIG_COLLECT_TIMESTAMPS) += timestamp.c +romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c romstage-y += compute_ip_checksum.c romstage-y += memmove.c romstage-$(CONFIG_ARCH_X86) += gcc.c

1 0

← Newer
1
...
27
28
29
30
31
32
33
...
45
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit March 2013