coreboot March 2013

coreboot@coreboot.org

46 participants
782 discussions

Patch merged into coreboot/master: 1570260 haswell: Fix BDSM and BGSM indicies in memory map
by gerrit＠coreboot.org 15 Mar '13

15 Mar '13

the following patch was just integrated into master: commit 1570260ba15692e8eafe6af1718aebbbf4ab6a43 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Dec 21 22:18:58 2012 -0600 haswell: Fix BDSM and BGSM indicies in memory map This wasn't previously spotted because the printk's were correct. However if one needed to get the value of the BDSM or BGSM register the value would reflect the other register's value. Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2689 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Thu Mar 14 23:33:54 2013, giving +1 See http://review.coreboot.org/2689 for details. -gerrit

1 0

Patch merged into coreboot/master: 1fef1f5 haswell: reserve default SMRAM space
by gerrit＠coreboot.org 15 Mar '13

15 Mar '13

the following patch was just integrated into master: commit 1fef1f51779307ff65a82b8fd86ff9fa6d2bcae0 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Wed Dec 19 17:15:43 2012 -0600 haswell: reserve default SMRAM space Currently the OS is free to use the memory located at the default SMRAM space because it is not marked reserved in the e820. This can lead to memory corruption on S3 resume because SMM setup doesn't save this range before using it to relocate SMRAM. Resulting tables: 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-00000000acebffff: RAM 8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 9. 00000000ad000000-00000000af9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 13 items: 0: 0000000000000000 - 0000000000030000 = 1 RAM 1: 0000000000030000 - 0000000000040000 = 2 RESERVED 2: 0000000000040000 - 000000000009f400 = 1 RAM 3: 000000000009f400 - 00000000000a0000 = 2 RESERVED 4: 00000000000f0000 - 0000000000100000 = 2 RESERVED 5: 0000000000100000 - 0000000000f00000 = 1 RAM 6: 0000000000f00000 - 0000000001000000 = 2 RESERVED 7: 0000000001000000 - 00000000acec0000 = 1 RAM 8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 12: 0000000100000000 - 000000018f600000 = 1 RAM Booted and checked e820 as well as coreboot table information. Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2688 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 00:05:34 2013, giving +1 See http://review.coreboot.org/2688 for details. -gerrit

1 0

Patch merged into coreboot/master: c12ef97 haswell: resource allocation
by gerrit＠coreboot.org 15 Mar '13

15 Mar '13

the following patch was just integrated into master: commit c12ef9723efac1006307c7fae13e34cb444cee36 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Tue Dec 18 14:22:49 2012 -0600 haswell: resource allocation The previous code w.r.t. resource allocation was getting lucky based on the way fixed mmio resources on the system were being chosen. Namely, PCIEXBAR was the lowest mmio space and the other fixed non-standar BARs were above it. The resource allocator would then start allocating standard BARs below that. On top of that other resources were being added when dev_ops->set_resources() was being called on the PCI domain. At that point the PCI range limit were already picked for where to start allocating from. To ensure we no longer get lucky during resource allocation add the fixed resources in the host bridge and add the memory controller cacheable memory areas. With those resources added the range limit for standard PCI BARs is chosen properly. Depending on haswell board configurations we may need to adjust and pass in the size of physical address space needed for PCI resources to the reference code. For the time being the CRBs appear to be OK. Lastly, remove the SNB workaround for reserving 2MiB at 1GiB and 512MiB. Output from 6GiB memory configuration: MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000018f600000 = 1 RAM Output from 4GiB memory configuration: MC MAP: TOM: 0x100000000 MC MAP: TOUUD: 0x14f600000 MC MAP: MESEG_BASE: 0xff000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x14f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000014f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000014f600000 = 1 RAM Output from 2GiB memory configuration: MC MAP: TOM: 0x40000000 MC MAP: TOUUD: 0x100600000 MC MAP: MESEG_BASE: 0x3f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x1005fffff MC MAP: TOLUD: 0x3ea00000 MC MAP: BDSM: 0x3ca00000 MC MAP: BGSM: 0x3c800000 MC MAP: TESGMB: 0x3c000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-000000003bebffff: RAM 6. 000000003bec0000-000000003bffffff: CONFIGURATION TABLES 7. 000000003c000000-000000003e9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 000000003bec0000 = 1 RAM 6: 000000003bec0000 - 000000003ea00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 0000000100600000 = 1 RAM Verified through debug messages that range limits as well as resources were being properly honored. Change-Id: I2faa7d8a2a34a6a411a2885afb3b5c3fa1ad9c23 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2687 Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Tested-by: build bot (Jenkins) Build-Tested: build bot (Jenkins) at Thu Mar 14 23:55:00 2013, giving +1 See http://review.coreboot.org/2687 for details. -gerrit

1 0

New patch to review for coreboot: 00db8c8 i945: Replace some magic values by defined names
by Patrick Georgi 15 Mar '13

15 Mar '13

Patrick Georgi (patrick(a)georgi-clan.de) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2733 -gerrit commit 00db8c892313582629613f4b121a7733cb2e9cd8 Author: Patrick Georgi <patrick.georgi(a)secunet.com> Date: Fri Mar 15 14:11:37 2013 +0100 i945: Replace some magic values by defined names Cleanup. Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> --- src/northbridge/intel/i945/raminit.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/northbridge/intel/i945/raminit.c b/src/northbridge/intel/i945/raminit.c index 758a97e..bbd6528 100644 --- a/src/northbridge/intel/i945/raminit.c +++ b/src/northbridge/intel/i945/raminit.c @@ -295,18 +295,18 @@ static void sdram_detect_errors(struct sys_info *sysinfo) pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xa2, reg8); /* clear self refresh status if check is disabled or not a resume */ - if (!CONFIG_CHECK_SLFRCS_ON_RESUME || sysinfo->boot_path != 2) { - MCHBAR8(0xf14) |= 3; + if (!CONFIG_CHECK_SLFRCS_ON_RESUME || sysinfo->boot_path != BOOT_PATH_RESUME) { + MCHBAR8(SLFRCS) |= 3; } else { /* Validate self refresh config */ if (((sysinfo->dimm[0] != SYSINFO_DIMM_NOT_POPULATED) || (sysinfo->dimm[1] != SYSINFO_DIMM_NOT_POPULATED)) && - !(MCHBAR8(0xf14) & (1<<0))) { + !(MCHBAR8(SLFRCS) & (1<<0))) { do_reset = 1; } if (((sysinfo->dimm[2] != SYSINFO_DIMM_NOT_POPULATED) || (sysinfo->dimm[3] != SYSINFO_DIMM_NOT_POPULATED)) && - !(MCHBAR8(0xf14) & (1<<1))) { + !(MCHBAR8(SLFRCS) & (1<<1))) { do_reset = 1; } }

1 0

Patch set updated for coreboot: f37bd76 Super i/o W83627DHG UARTB could not function properly.
by Wolfgang Kamp 15 Mar '13

15 Mar '13

Wolfgang Kamp (wmkamp(a)datakamp.de) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2626 -gerrit commit f37bd7638f3279dc194c12c96913f7de622dfb7d Author: Wolfgang Kamp <wmkamp(a)datakamp.de> Date: Mon Mar 11 16:35:42 2013 +0100 Super i/o W83627DHG UARTB could not function properly. Pins 78-85 are set to GPIO after power on or reset. Pins must be redirected to UARTB if enabled. Look at W83627DHG databook version 1.4 page 185 Chip (global) Control Register CR2C. Change-Id: I12b094a60d9c5cb2447a553be4679a4605e19845 Signed-off-by: Wolfgang Kamp <wmkamp(a)datakamp.de> --- src/superio/winbond/w83627dhg/superio.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/superio/winbond/w83627dhg/superio.c b/src/superio/winbond/w83627dhg/superio.c index 26f2921..bbde26a 100644 --- a/src/superio/winbond/w83627dhg/superio.c +++ b/src/superio/winbond/w83627dhg/superio.c @@ -37,6 +37,17 @@ void pnp_exit_ext_func_mode(device_t dev) outb(0xaa, dev->path.pnp.port); } +static void w83627dhg_enable_UR2(device_t dev) +{ + u8 reg8; + + pnp_enter_ext_func_mode(dev); + reg8 = pnp_read_config(dev, 0x2c); + reg8 |= (0x3); + pnp_write_config(dev, 0x2c, reg8); // Set pins 78-85-> UART B + pnp_exit_ext_func_mode(dev); +} + static void w83627dhg_init(device_t dev) { struct superio_winbond_w83627dhg_config *conf = dev->chip_info; @@ -45,6 +56,9 @@ static void w83627dhg_init(device_t dev) return; switch(dev->path.pnp.device) { + case W83627DHG_SP2: + w83627dhg_enable_UR2(dev); + break; case W83627DHG_KBC: pc_keyboard_init(&conf->keyboard); break;

1 0

Patch set updated for coreboot: 944484c Revert "haswell: remove CONFIG_GFXUMA"
by Hung-Te Lin 15 Mar '13

15 Mar '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2732 -gerrit commit 944484c6e32b9800c31c1dbef6612ffb054e9dd1 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Mar 15 11:18:39 2013 +0100 Revert "haswell: remove CONFIG_GFXUMA" This reverts commit ed7b52d3cb4c5f3f4ecfd43d93c0c5e2d459fe23 There are still UMA stuff in pci_domain_set_resources and add_fixed_resources function from northbridge/intel/haswell/northbridge.c. We can't remove CONFIG_GFXUMA unless those are also removed, otherwise building intel/baskingridge will fail (http://qa.coreboot.org/job/coreboot-gerrit/5202/) Change-Id: Ie7a6196c252442ba11f56d7602988a3556bb01af Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- src/mainboard/intel/baskingridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mainboard/intel/baskingridge/Kconfig b/src/mainboard/intel/baskingridge/Kconfig index 830c650..a8478a8 100644 --- a/src/mainboard/intel/baskingridge/Kconfig +++ b/src/mainboard/intel/baskingridge/Kconfig @@ -14,6 +14,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy select HAVE_MAINBOARD_RESOURCES select MMCONF_SUPPORT select HAVE_SMI_HANDLER + select GFXUMA select CHROMEOS select EXTERNAL_MRC_BLOB

1 0

New patch to review for coreboot: 1e12401 Revert "haswell: remove CONFIG_GFXUMA"
by Hung-Te Lin 15 Mar '13

15 Mar '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2732 -gerrit commit 1e124017f0deb7de171618939fb2c72922d63fbb Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Mar 15 11:18:39 2013 +0100 Revert "haswell: remove CONFIG_GFXUMA" This reverts commit ed7b52d3cb4c5f3f4ecfd43d93c0c5e2d459fe23 There are still UMA stuff in pci_domain_set_resources and add_fixed_resources function from northbridge/intel/haswell/northbridge.c. We can't remove CONFIG_GFXUMA unless those are also removed. Change-Id: Ie7a6196c252442ba11f56d7602988a3556bb01af --- src/mainboard/intel/baskingridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mainboard/intel/baskingridge/Kconfig b/src/mainboard/intel/baskingridge/Kconfig index 830c650..a8478a8 100644 --- a/src/mainboard/intel/baskingridge/Kconfig +++ b/src/mainboard/intel/baskingridge/Kconfig @@ -14,6 +14,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy select HAVE_MAINBOARD_RESOURCES select MMCONF_SUPPORT select HAVE_SMI_HANDLER + select GFXUMA select CHROMEOS select EXTERNAL_MRC_BLOB

1 0

Patch set updated for coreboot: 8e65481 cbfstool: Fix initial empty space in image creation.
by Hung-Te Lin 15 Mar '13

15 Mar '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2731 -gerrit commit 8e654817b7812540330abdc668aec1eacfa4eba4 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Mar 15 17:40:08 2013 +0800 cbfstool: Fix initial empty space in image creation. When calculating initial CBFS empty entry space, the size of header itself must be not included (with the reserved space for entry name). This is a regression of the old cbfstool size bug. Before this fix, in build process we see: OBJCOPY cbfs/fallback/romstage_null.bin W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... And checking the output binary: cbfstool build/coreboot.pre1 print -v -v DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes) DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30 W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00. coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64 Name Offset Type Size (empty) 0x0 null 261296 DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0 After this fix, no more alerts in build process. Verified to build successfully on x86/qemu and arm/snow configurations. Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- util/cbfstool/cbfs_image.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/util/cbfstool/cbfs_image.c b/util/cbfstool/cbfs_image.c index 2cdbf23..19362f1 100644 --- a/util/cbfstool/cbfs_image.c +++ b/util/cbfstool/cbfs_image.c @@ -142,6 +142,7 @@ int cbfs_image_create(struct cbfs_image *image, struct cbfs_header *header; struct cbfs_file *entry; uint32_t cbfs_len; + size_t entry_header_len; DEBUG("cbfs_image_create: bootblock=0x%x+0x%zx, " "header=0x%x+0x%zx, entries_offset=0x%x\n", @@ -205,9 +206,10 @@ int cbfs_image_create(struct cbfs_image *image, entries_offset, align); return -1; } - if (entries_offset + sizeof(*entry) > size) { + entry_header_len = cbfs_calculate_file_header_size(""); + if (entries_offset + entry_header_len > size) { ERROR("Offset (0x%x+0x%zx) exceed ROM size(0x%zx)\n", - entries_offset, sizeof(*entry), size); + entries_offset, entry_header_len, size); return -1; } entry = (struct cbfs_file *)(image->buffer.data + entries_offset); @@ -218,7 +220,7 @@ int cbfs_image_create(struct cbfs_image *image, cbfs_len = bootblock_offset; if (header_offset > entries_offset && header_offset < cbfs_len) cbfs_len = header_offset; - cbfs_len -= entries_offset + align; + cbfs_len -= entries_offset + align + entry_header_len; cbfs_create_empty_entry(image, entry, cbfs_len, ""); LOG("Created CBFS image (capacity = %d bytes)\n", cbfs_len); return 0;

1 0

New patch to review for coreboot: f096ce1 cbfstool: Fix initial empty space in image creation.
by Hung-Te Lin 15 Mar '13

15 Mar '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2731 -gerrit commit f096ce19f8b454e52f04d842ee619ad1ca4cf45f Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Mar 15 17:40:08 2013 +0800 cbfstool: Fix initial empty space in image creation. When calculating initial CBFS empty entry space, the size of header itself must be included (with the reserved space for entry name). This is a regression of old cbfstool size bug. Before this fix, in build process we see: OBJCOPY cbfs/fallback/romstage_null.bin W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... And checking the output binary: cbfstool build/coreboot.pre1 print -v -v DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes) DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30 W: CBFS image was created with old cbfstool with size bug. Fixing size in last entry... DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00. coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64 Name Offset Type Size (empty) 0x0 null 261296 DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0 After this fix, no longer alerts in build process. Verified to build successfully on x86/qemu and arm/snow configurations. Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- util/cbfstool/cbfs_image.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/util/cbfstool/cbfs_image.c b/util/cbfstool/cbfs_image.c index 2cdbf23..7b43e35 100644 --- a/util/cbfstool/cbfs_image.c +++ b/util/cbfstool/cbfs_image.c @@ -142,6 +142,7 @@ int cbfs_image_create(struct cbfs_image *image, struct cbfs_header *header; struct cbfs_file *entry; uint32_t cbfs_len; + size_t entry_header_len; DEBUG("cbfs_image_create: bootblock=0x%x+0x%zx, " "header=0x%x+0x%zx, entries_offset=0x%x\n", @@ -205,9 +206,10 @@ int cbfs_image_create(struct cbfs_image *image, entries_offset, align); return -1; } - if (entries_offset + sizeof(*entry) > size) { + entry_header_len = cbfs_calculate_file_header_size(""); + if (entries_offset + entry_header_len > size) { ERROR("Offset (0x%x+0x%zx) exceed ROM size(0x%zx)\n", - entries_offset, sizeof(*entry), size); + entries_offset, entry_header_len, size); return -1; } entry = (struct cbfs_file *)(image->buffer.data + entries_offset); @@ -218,7 +220,8 @@ int cbfs_image_create(struct cbfs_image *image, cbfs_len = bootblock_offset; if (header_offset > entries_offset && header_offset < cbfs_len) cbfs_len = header_offset; - cbfs_len -= entries_offset + align; + DEBUG("align: %d, entry_header_len: %d\n", align, entry_header_len); + cbfs_len -= entries_offset + align + entry_header_len; cbfs_create_empty_entry(image, entry, cbfs_len, ""); LOG("Created CBFS image (capacity = %d bytes)\n", cbfs_len); return 0;

1 0

New patch to review for coreboot: b361bde cbfstool: Allow smaller alignment size for locate command.
by Hung-Te Lin 15 Mar '13

15 Mar '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2730 -gerrit commit b361bdea249884d62163923956fcd09c5c44958f Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Mar 15 14:44:05 2013 +0800 cbfstool: Allow smaller alignment size for locate command. The "locate" command was primarily used to finding a location for ELF stage to fit in (one) memory page. To support adding data blobs that only need alignment without memory page boundary limitation, we can extend the locate command to allow any alignment (even smaller than input file size). Verified by manually testing a file (324 bytes) with alignment=0x10: cbfstool coreboot.rom locate -f test -n test -a 0x10 # output: 0x71fdd0 cbfstool coreboot.rom add -f test -n test -t raw -b 0x71fdd0 cbfstool coreboot.rom print -v -v # output: test 0x71fd80 raw 324 # output: cbfs_file=0x71fd80, offset=0x50, content_address=0x71fdd0+0x144 Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- util/cbfstool/cbfs_image.c | 83 ++++++++++++++++++---------------------------- util/cbfstool/cbfs_image.h | 4 +-- 2 files changed, 35 insertions(+), 52 deletions(-) diff --git a/util/cbfstool/cbfs_image.c b/util/cbfstool/cbfs_image.c index 2cdbf23..d3e502d 100644 --- a/util/cbfstool/cbfs_image.c +++ b/util/cbfstool/cbfs_image.c @@ -773,54 +773,50 @@ int cbfs_create_empty_entry(struct cbfs_image *image, struct cbfs_file *entry, return 0; } -/* Finds a place to hold whole stage data in same memory page. - */ -static int is_in_same_page(uint32_t start, uint32_t size, uint32_t page) { - if (!page) - return 1; - return (start / page) == (start + size - 1) / page; +/* Finds a place in given range (start, end) to hold <size> of bytes and aligned + * to <align> of bytes; otherwise return 0. */ +static uint32_t fit_in_range(uint32_t start, uint32_t end, uint32_t size, + uint32_t align) { + uint32_t offset = align_up(start, align); + + /* 0 is used to indicate failure so start can't be 0. This is typically + * true because we usually have a header before start address. */ + assert(start != 0); + + while (offset < start) + offset += align; + + if (offset >= start && offset + size <= end) + return offset; + + return 0; } int32_t cbfs_locate_entry(struct cbfs_image *image, const char *name, - uint32_t size, uint32_t page_size) { + uint32_t size, uint32_t align) { struct cbfs_file *entry; size_t need_len; - uint32_t addr, addr_next, addr2, addr3, header_len; - assert(size < page_size); + uint32_t addr, addr_next, offset, header_len; - if (page_size % ntohl(image->header->align)) - WARN("locate_entry: page does not align with CBFS image.\n"); + if (!align) + align = 1; + + if (align % ntohl(image->header->align)) + WARN("%s: Alignment (%d) is smaller than CBFS image (%d).\n", + __func__, align, ntohl(image->header->align)); /* TODO Old cbfstool always assume input is a stage file (and adding * sizeof(cbfs_stage) for header. We should fix that by adding "-t" - * (type) param in future. For right now, follow old behavior. */ + * (type) param in future. For right now, we assume cbfs_stage is the + * largest structure and add it into header size. */ + assert(sizeof(struct cbfs_stage) >= sizeof(struct cbfs_payload)); header_len = (cbfs_calculate_file_header_size(name) + sizeof(struct cbfs_stage)); need_len = header_len + size; - // Merge empty entries to build get max available pages. + // Merge empty entries to build get max available alignment. cbfs_walk(image, cbfs_merge_empty_entry, NULL); - /* Three cases of content location on memory page: - * case 1. - * | PAGE 1 | PAGE 2 | - * | <header><content>| Fit. Return start of content. - * - * case 2. - * | PAGE 1 | PAGE 2 | - * | <header><content> | Fits when we shift content to align - * shift-> | <header>|<content> | at starting of PAGE 2. - * - * case 3. (large content filling whole page) - * | PAGE 1 | PAGE 2 | PAGE 3| - * | <header>< content > | | Can't fit. If we shift content to - * | { free space . } PAGE 2, header can't fit in free - * | shift-> <header><content> space, so we must use PAGE 3. - * - * The returned address will be used to re-link stage file, and then - * assigned to add-stage command (-b), which will be then re-calculated - * by ELF loader and positioned by cbfs_add_entry. - */ for (entry = cbfs_find_first_entry(image); entry && cbfs_is_valid_entry(image, entry); entry = cbfs_find_next_entry(image, entry)) { @@ -834,24 +830,11 @@ int32_t cbfs_locate_entry(struct cbfs_image *image, const char *name, image, entry)); if (addr_next - addr < need_len) continue; - if (is_in_same_page(addr + header_len, size, page_size)) { - DEBUG("cbfs_locate_entry: FIT (PAGE1)."); - return addr + header_len; - } - addr2 = align_up(addr, page_size); - if (addr2 < addr_next && addr_next - addr2 >= size && - addr2 - addr >= header_len) { - DEBUG("cbfs_locate_entry: OVERLAP (PAGE2)."); - return addr2; - } - - addr3 = addr2 + page_size; - if (addr3 < addr_next && addr_next - addr3 >= size && - addr3 - addr >= header_len) { - DEBUG("cbfs_locate_entry: OVERLAP+ (PAGE3)."); - return addr3; - } + offset = fit_in_range(addr + header_len, addr_next, size, + align); + if (offset) + return offset; } return -1; } diff --git a/util/cbfstool/cbfs_image.h b/util/cbfstool/cbfs_image.h index 57bbfa1..16ba568 100644 --- a/util/cbfstool/cbfs_image.h +++ b/util/cbfstool/cbfs_image.h @@ -76,10 +76,10 @@ int cbfs_remove_entry(struct cbfs_image *image, const char *name); int cbfs_create_empty_entry(struct cbfs_image *image, struct cbfs_file *entry, size_t len, const char *name); -/* Finds a location to put given content in same memory page. +/* Finds a location to put given content in aligned location. * Returns a valid offset, or -1 on failure. */ int32_t cbfs_locate_entry(struct cbfs_image *image, const char *name, - uint32_t size, uint32_t page_size); + uint32_t size, uint32_t align); /* Callback function used by cbfs_walk. * Returns 0 on success, or non-zero to stop further iteration. */

1 0

← Newer
1
...
30
31
32
33
34
35
36
...
79
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2013