coreboot-gerrit January 2017

coreboot-gerrit@coreboot.org

1 participants
852 discussions

Patch set updated for coreboot: util/cbfstool: avoid memleaks and off-by-ones
by Patrick Georgi 23 Jan '17

23 Jan '17

Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18134 -gerrit commit a6cbbcf1bf0ec9cdace91c3a1682bf473af3319b Author: Patrick Georgi <pgeorgi(a)chromium.org> Date: Fri Jan 13 13:30:54 2017 +0100 util/cbfstool: avoid memleaks and off-by-ones Change-Id: Iac136a5dfe76f21aa7c0d5ee4e974e50b955403b Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Found-by: scan-build 3.8 --- util/cbfstool/cbfs_image.c | 8 ++++++++ util/cbfstool/cbfscomptool.c | 5 +++++ util/cbfstool/fmd.c | 2 +- 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/util/cbfstool/cbfs_image.c b/util/cbfstool/cbfs_image.c index e530224..a24a03d 100644 --- a/util/cbfstool/cbfs_image.c +++ b/util/cbfstool/cbfs_image.c @@ -1152,11 +1152,15 @@ static int cbfs_payload_make_elf(struct buffer *buff, uint32_t arch) break; } + if (!name) + ERROR("out of memory\n"); if (elf_writer_add_section(ew, &shdr, &tbuff, name)) { ERROR("Unable to add ELF section: %s\n", name); + free(name); goto out; } + free(name); if (empty_sz != 0) { struct buffer b; @@ -1168,10 +1172,14 @@ static int cbfs_payload_make_elf(struct buffer *buff, uint32_t arch) shdr.sh_addr = segs[i].load_addr + segs[i].len; shdr.sh_size = empty_sz; name = strdup(".empty"); + if (!name) + ERROR("out of memory\n"); if (elf_writer_add_section(ew, &shdr, &b, name)) { ERROR("Unable to add ELF section: %s\n", name); + free(name); goto out; } + free(name); } } diff --git a/util/cbfstool/cbfscomptool.c b/util/cbfstool/cbfscomptool.c index 9e80486..3430809 100644 --- a/util/cbfstool/cbfscomptool.c +++ b/util/cbfstool/cbfscomptool.c @@ -49,6 +49,7 @@ int benchmark() } char *compressed_data = malloc(bufsize); if (!compressed_data) { + free(data); fprintf(stderr, "out of memory\n"); return 1; } @@ -64,6 +65,8 @@ int benchmark() comp_func_ptr comp = compression_function(algo->type); if (comp == NULL) { printf("no handler associated with algorithm\n"); + free(data); + free(compressed_data); return 1; } @@ -80,6 +83,8 @@ int benchmark() bufsize, outsize, t_e.tv_sec - t_s.tv_sec); } + free(data); + free(compressed_data); return 0; } diff --git a/util/cbfstool/fmd.c b/util/cbfstool/fmd.c index afd8701..7a289d7 100644 --- a/util/cbfstool/fmd.c +++ b/util/cbfstool/fmd.c @@ -289,7 +289,7 @@ static void print_with_prefix(const struct flashmap_descriptor *tree, if (tree->list_len) { puts(":"); - char child_prefix[strlen(pre) + 1]; + char child_prefix[strlen(pre) + 2]; strcpy(child_prefix, pre); strcat(child_prefix, "\t"); fmd_foreach_child(each, tree)

1 0

Patch set updated for coreboot: [RFC] Allow to add a second bootblock at a 64K offset for BUC.TS
by Arthur Heymans 23 Jan '17

23 Jan '17

Arthur Heymans (arthur(a)aheymans.xyz) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18148 -gerrit commit 65c5bc37c3e52811970f76f144fcf2fae393c594 Author: Arthur Heymans <arthur(a)aheymans.xyz> Date: Sun Jan 15 14:24:56 2017 +0100 [RFC] Allow to add a second bootblock at a 64K offset for BUC.TS This allows to add a second bootblock at an offset of 64K in order for it to be used if the BUC.TS bit, RCBA(0x3414)[BITO], is set. This method is often used to flash coreboot when the vendor BIOS only write protects its bootblock at the bottom of flash (e.g. Lenovo thinkpad X60 and T60), but can also be used to have a backup while hacking on bootblock code. TESTED on Thinkpad x200 with BIT0 of RCBA(0x3410) unset (not default in coreboot). Some questions, remarks: - How to do this with cbfstool could also simply be documented instead of integrated in the build system; - Is this Makefile code a good way to achieve this? - Kconfig: Should this be board specific instead of southbridge specific, since it is mainly aimed at flashing coreboot from vendor BIOS? It really depends on the vendor BIOS bootblock if this Backed Up Control Top Swap trick works. Change-Id: I37e288e710edbe41651d09d2a6981a571df69bde Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> --- Makefile.inc | 7 +++++++ src/southbridge/intel/common/Kconfig | 18 ++++++++++++++++++ src/southbridge/intel/i82801gx/Kconfig | 1 + src/southbridge/intel/i82801ix/Kconfig | 1 + 4 files changed, 27 insertions(+) diff --git a/Makefile.inc b/Makefile.inc index c5ce30f..01c0869 100644 --- a/Makefile.inc +++ b/Makefile.inc @@ -844,6 +844,13 @@ ifeq ($(CONFIG_ARCH_X86),y) -n bootblock \ -t bootblock \ -b -$(call file-size,$(objcbfs)/bootblock.bin) $(cbfs-autogen-attributes) +ifeq ($(CONFIG_BUCTS_BOOTBLOCK),y) + $(CBFSTOOL) $@.tmp add \ + -f $(objcbfs)/bootblock.bin \ + -n bootblock_bucts \ + -t bootblock \ + -b -$(call int-add,$(call file-size,$(objcbfs)/bootblock.bin) $(CONFIG_BOOTBLOCK_SIZE)) $(cbfs-autogen-attributes) +endif # ifeq CONFIG_BUCTS_BOOTBLOCK else # ifeq ($(CONFIG_ARCH_X86),y) $(CBFSTOOL) $@.tmp write -u \ -r BOOTBLOCK \ diff --git a/src/southbridge/intel/common/Kconfig b/src/southbridge/intel/common/Kconfig index 7bc686d..31f37dc 100644 --- a/src/southbridge/intel/common/Kconfig +++ b/src/southbridge/intel/common/Kconfig @@ -2,3 +2,21 @@ config SOUTHBRIDGE_INTEL_COMMON def_bool n config SOUTHBRIDGE_INTEL_COMMON_GPIO def_bool n +config HAVE_BUCTS + bool + default n +config BUCTS_BOOTBLOCK + bool "Include a BUC.TS bootblock" + default n + depends on HAVE_BUCTS + help + Some vendor BIOS only write protect their bootblock. + Using the buc.ts register RCBA[0x3414], it is possible to have + the southbridge look for the bootblock at a 64K offset + instead of the usual top of flash, which might not be + write protected. + Select this to put a 'second' bootblock at a 64K offset. +config BOOTBLOCK_SIZE + hex + depends on BUCTS_BOOTBLOCK + default 0x10000 diff --git a/src/southbridge/intel/i82801gx/Kconfig b/src/southbridge/intel/i82801gx/Kconfig index b2265c4..4eb2835 100644 --- a/src/southbridge/intel/i82801gx/Kconfig +++ b/src/southbridge/intel/i82801gx/Kconfig @@ -24,6 +24,7 @@ config SOUTHBRIDGE_INTEL_I82801GX select HAVE_SMI_HANDLER select COMMON_FADT select SOUTHBRIDGE_INTEL_COMMON_GPIO + select HAVE_BUCTS if SOUTHBRIDGE_INTEL_I82801GX diff --git a/src/southbridge/intel/i82801ix/Kconfig b/src/southbridge/intel/i82801ix/Kconfig index e4d1f91..0928a8a 100644 --- a/src/southbridge/intel/i82801ix/Kconfig +++ b/src/southbridge/intel/i82801ix/Kconfig @@ -25,6 +25,7 @@ config SOUTHBRIDGE_INTEL_I82801IX select HAVE_USBDEBUG_OPTIONS select SOUTHBRIDGE_INTEL_COMMON_GPIO select HAVE_INTEL_FIRMWARE + select HAVE_BUCTS if SOUTHBRIDGE_INTEL_I82801IX

1 0

Patch set updated for coreboot: [RFC] Allow to add a second bootblock at a 64K offset for BUC.TS
by Arthur Heymans 23 Jan '17

23 Jan '17

Arthur Heymans (arthur(a)aheymans.xyz) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18148 -gerrit commit 2a6158b76d962a9cbb03c39b4d019dd86bb88bb3 Author: Arthur Heymans <arthur(a)aheymans.xyz> Date: Sun Jan 15 14:24:56 2017 +0100 [RFC] Allow to add a second bootblock at a 64K offset for BUC.TS This allows to add a second bootblock at an offset of 64K in order for it to be used if the BUC.TS bit, RCBA(0x3414)[BITO], is set. This method is often used to flash coreboot when the vendor BIOS only write protects its bootblock at the bottom of flash (e.g. Lenovo thinkpad X60 and T60), but can also be used to have a backup while hacking on bootblock code. TESTED on Thinkpad x200 with BIT0 of RCBA(0x3410) unset (not default in coreboot). Some questions, remarks: - How to do this with cbfstool could also simply be documented instead of integrated in the build system; - Is this Makefile code a good way to achieve this? - Kconfig: Should this be board specific instead of southbridge specific, since it is mainly aimed at flashing coreboot from vendor BIOS? It really depends on the vendor BIOS bootblock if this Backed Up Control Top Swap trick works. Change-Id: I37e288e710edbe41651d09d2a6981a571df69bde Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> --- Makefile.inc | 7 +++++++ src/southbridge/intel/common/Kconfig | 18 ++++++++++++++++++ src/southbridge/intel/i82801gx/Kconfig | 1 + src/southbridge/intel/i82801ix/Kconfig | 1 + 4 files changed, 27 insertions(+) diff --git a/Makefile.inc b/Makefile.inc index c5ce30f..01c0869 100644 --- a/Makefile.inc +++ b/Makefile.inc @@ -844,6 +844,13 @@ ifeq ($(CONFIG_ARCH_X86),y) -n bootblock \ -t bootblock \ -b -$(call file-size,$(objcbfs)/bootblock.bin) $(cbfs-autogen-attributes) +ifeq ($(CONFIG_BUCTS_BOOTBLOCK),y) + $(CBFSTOOL) $@.tmp add \ + -f $(objcbfs)/bootblock.bin \ + -n bootblock_bucts \ + -t bootblock \ + -b -$(call int-add,$(call file-size,$(objcbfs)/bootblock.bin) $(CONFIG_BOOTBLOCK_SIZE)) $(cbfs-autogen-attributes) +endif # ifeq CONFIG_BUCTS_BOOTBLOCK else # ifeq ($(CONFIG_ARCH_X86),y) $(CBFSTOOL) $@.tmp write -u \ -r BOOTBLOCK \ diff --git a/src/southbridge/intel/common/Kconfig b/src/southbridge/intel/common/Kconfig index 7bc686d..12d84af 100644 --- a/src/southbridge/intel/common/Kconfig +++ b/src/southbridge/intel/common/Kconfig @@ -2,3 +2,21 @@ config SOUTHBRIDGE_INTEL_COMMON def_bool n config SOUTHBRIDGE_INTEL_COMMON_GPIO def_bool n +config HAVE_BUCTS + bool + default n +config BUCTS_BOOTBLOCK + bool "Include a BUC.TS bootblock" + default n + depends on HAVE_BUCTS + help + Some vendor BIOS only write protect their bootblock. + Using the buc.ts register RCBA[0x3414], it is possible to have + the southbridge look for the bootblock at a 64K offset + instead of the usual top of flash, which might not be + write protected. + Select this to put a 'second' bootblock at a 64K offset. +config BOOTBLOCK_SIZE + hex + depends on BUCTS_BOOTBLOCK + default 0x10000 \ No newline at end of file diff --git a/src/southbridge/intel/i82801gx/Kconfig b/src/southbridge/intel/i82801gx/Kconfig index b2265c4..4eb2835 100644 --- a/src/southbridge/intel/i82801gx/Kconfig +++ b/src/southbridge/intel/i82801gx/Kconfig @@ -24,6 +24,7 @@ config SOUTHBRIDGE_INTEL_I82801GX select HAVE_SMI_HANDLER select COMMON_FADT select SOUTHBRIDGE_INTEL_COMMON_GPIO + select HAVE_BUCTS if SOUTHBRIDGE_INTEL_I82801GX diff --git a/src/southbridge/intel/i82801ix/Kconfig b/src/southbridge/intel/i82801ix/Kconfig index e4d1f91..0928a8a 100644 --- a/src/southbridge/intel/i82801ix/Kconfig +++ b/src/southbridge/intel/i82801ix/Kconfig @@ -25,6 +25,7 @@ config SOUTHBRIDGE_INTEL_I82801IX select HAVE_USBDEBUG_OPTIONS select SOUTHBRIDGE_INTEL_COMMON_GPIO select HAVE_INTEL_FIRMWARE + select HAVE_BUCTS if SOUTHBRIDGE_INTEL_I82801IX

1 0

Patch set updated for coreboot: nb/intel/x4x: Refactor dram freq and cas selection
by Arthur Heymans 22 Jan '17

22 Jan '17

Arthur Heymans (arthur(a)aheymans.xyz) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18156 -gerrit commit affb0559dd314fb498a0f81e25ef388765a4d35d Author: Arthur Heymans <arthur(a)aheymans.xyz> Date: Mon Jan 16 23:32:02 2017 +0100 nb/intel/x4x: Refactor dram freq and cas selection Inspired by i945 code. The code did not check for tAC and for tCLK potentially selected the wrong spd offset for minimum cycle time. Adds some debugging output for freq and cas selection. The code is also written to be easily extendable for officially unsported dram frequencies like 533MHz and 400MHz which some vendor bios seem to support. Change-Id: Ie0d8326af50d3125bf35918ba645a6df27dd2ee4 Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> --- src/northbridge/intel/x4x/raminit.c | 111 ++++++++++++++++++++++-------------- 1 file changed, 68 insertions(+), 43 deletions(-) diff --git a/src/northbridge/intel/x4x/raminit.c b/src/northbridge/intel/x4x/raminit.c index 86f63f1..35be4f0 100644 --- a/src/northbridge/intel/x4x/raminit.c +++ b/src/northbridge/intel/x4x/raminit.c @@ -160,13 +160,6 @@ static void sdram_read_spds(struct sysinfo *s) } } -static u8 msbpos(u8 val) //Reverse -{ - u8 i; - for (i = 7; (i >= 0) && ((val & (1 << i)) == 0); i--); - return i; -} - static void mchinfo_ddr2(struct sysinfo *s) { const u32 eax = cpuid_ext(0x04, 0).eax; @@ -199,13 +192,29 @@ static void sdram_detect_ram_speed(struct sysinfo *s) { u8 i; u8 commoncas = 0; + u8 highest_commoncas; u8 currcas; u8 currfreq; u8 maxfreq; u8 freq = 0; + u8 highest_supported_cas[TOTAL_DIMMS]; + u8 idx; + u8 tclk, tclk_target; + u8 tac, tac_target; + + const u8 ddr2_speeds_table[] = { + 0x50, 0x60, /* DDR2 400: tCLK = 5.0ns tAC = 0.6ns */ + 0x3d, 0x50, /* DDR2 533: tCLK = 3.75ns tAC = 0.5ns */ + 0x30, 0x45, /* DDR2 667: tCLK = 3.0ns tAC = 0.45ns */ + 0x25, 0x40, /* DDR2 800: tCLK = 2.5ns tAC = 0.40ns */ + }; + + const u8 spd_lookup_table[] = { + SPD_MIN_CYCLE_TIME_AT_CAS_MAX, SPD_ACCESS_TIME_FROM_CLOCK, + SPD_SDRAM_CYCLE_TIME_2ND, SPD_ACCESS_TIME_FROM_CLOCK_2ND, + SPD_SDRAM_CYCLE_TIME_3RD, SPD_ACCESS_TIME_FROM_CLOCK_3RD, + }; - // spdidx,cycletime @CAS 5 6 - u8 idx800[7][2] = {{0,0}, {0,0}, {0,0}, {0,0}, {0,0}, {23,0x30}, {9,0x25}}; int found = 0; // Find max FSB speed @@ -225,57 +234,73 @@ static void sdram_detect_ram_speed(struct sysinfo *s) break; } - // Max RAM speed if (s->spd_type == DDR2) { - - maxfreq = MEM_CLOCK_800MHz; - - // Choose common CAS latency from {6,5}, 4 does not work - commoncas = 0x60; - + /* Only CAS 5 and 6 are supported */ + commoncas = SPD_CAS_LATENCY_DDR2_6 | SPD_CAS_LATENCY_DDR2_5; FOR_EACH_POPULATED_DIMM(s->dimms, i) { + if (s->dimms[i].cas_latencies & SPD_CAS_LATENCY_DDR2_7) { + highest_supported_cas[i] = 7; + } else if (s->dimms[i].cas_latencies & SPD_CAS_LATENCY_DDR2_6) { + highest_supported_cas[i] = 6; + } else if (s->dimms[i].cas_latencies & SPD_CAS_LATENCY_DDR2_5) { + highest_supported_cas[i] = 5; + } /* Don't check for lower CAS since not supported */ commoncas &= s->dimms[i].cas_latencies; } - if (commoncas == 0) { + if (commoncas == 0) die("No common CAS among dimms\n"); - } + else if (commoncas & SPD_CAS_LATENCY_DDR2_6) + highest_commoncas = 6; + else + highest_commoncas = 5; + + /* + * FIXME: datasheets say only 667MHz and 800MHz are supported + * but vendor bios also support 533MHz and possibly 400MHz + */ + /* Test from higher to lower frequency, from lower to higher CAS latency */ + for (currfreq = MEM_CLOCK_800MHz; currfreq >= MEM_CLOCK_667MHz; currfreq--) { + printk(BIOS_DEBUG, "Trying DDR2: "); + switch (currfreq) { + case MEM_CLOCK_400MHz: + printk(BIOS_DEBUG, "%dMHz\n", 400); + case MEM_CLOCK_533MHz: + printk(BIOS_DEBUG, "%dMHz\n", 533); + case MEM_CLOCK_667MHz: + printk(BIOS_DEBUG, "%dMHz\n", 667); + case MEM_CLOCK_800MHz: + printk(BIOS_DEBUG, "%dMHz\n", 800); + } - // Working from fastest to slowest, - // fast->slow 5@800 6@800 5@667 - found = 0; - for (currcas = 5; currcas <= msbpos(commoncas); currcas++) { - currfreq = maxfreq; - if (currfreq == MEM_CLOCK_800MHz) { + for (currcas = 5; currcas <= highest_commoncas; currcas++) { + printk(BIOS_DEBUG, " Trying CAS: %d\n", currcas); found = 1; FOR_EACH_POPULATED_DIMM(s->dimms, i) { - if (s->dimms[i].spd_data[idx800[currcas][0]] > idx800[currcas][1]) { - // this is too fast + idx = highest_supported_cas[i] - currcas; + printk(BIOS_DEBUG, " dimm: %d, idx: %d\n", i, idx); + + tclk = s->dimms[i].spd_data[spd_lookup_table[2 * idx]]; + tclk_target = ddr2_speeds_table[2 * currfreq]; + tac = s->dimms[i].spd_data[spd_lookup_table[2 * idx + 1]]; + tac_target = ddr2_speeds_table[2 * currfreq + 1]; + printk(BIOS_DEBUG, " tCLK: 0x%x , tCLK_target: 0x%x\n", tclk, tclk_target); + printk(BIOS_DEBUG, " tAC: 0x%x , tAC_target: 0x%x\n", tac, tac_target); + if ((tclk > tclk_target) && (tac > tac_target)) { + printk(BIOS_DEBUG, " Timing too fast\n"); found = 0; + break; /* No need to check other dimms for these timings */ } } - if (found) - break; - } - } - - if (!found) { - currcas = 5; - currfreq = MEM_CLOCK_667MHz; - found = 1; - FOR_EACH_POPULATED_DIMM(s->dimms, i) { - if (s->dimms[i].spd_data[9] > 0x30) { - // this is too fast - found = 0; + if (found) { + s->selected_timings.mem_clk = currfreq; + s->selected_timings.CAS = currcas; + return; } } } - if (!found) die("No valid CAS/frequencies detected\n"); - s->selected_timings.mem_clk = currfreq; - s->selected_timings.CAS = currcas; - } else { // DDR3 // Limit frequency for MCH maxfreq = (s->max_ddr2_mhz == 800) ? MEM_CLOCK_800MHz : MEM_CLOCK_667MHz;

1 0

Patch merged into coreboot/master: .gitignore: Don’t track Tint directory
by gerrit＠coreboot.org 22 Jan '17

22 Jan '17

the following patch was just integrated into master: commit 35d7d361e33bea244a6ca4b270061f6ab92f7cd8 Author: Paul Menzel <pmenzel(a)molgen.mpg.de> Date: Fri Jan 20 17:33:19 2017 +0100 .gitignore: Don’t track Tint directory This is done already for the other payloads. Change-Id: I98eb05404c0e181ad99a61d8c97987ceadd9a53c Signed-off-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Reviewed-on: https://review.coreboot.org/18188 Reviewed-by: Martin Roth <martinroth(a)google.com> Tested-by: Martin Roth <martinroth(a)google.com> See https://review.coreboot.org/18188 for details. -gerrit

1 0

Patch merged into coreboot/master: gru: kevin: define GPIOs used on both platforms
by gerrit＠coreboot.org 22 Jan '17

22 Jan '17

the following patch was just integrated into master: commit f1343df54c2de10c69730e205052db623ef26cf1 Author: Vadim Bendebury <vbendeb(a)chromium.org> Date: Sun May 22 15:53:37 2016 -0700 gru: kevin: define GPIOs used on both platforms The same GPIOs are used on both platforms, definitions are added an a new .h to make it easier to re-use them across the code. BRANCH=none BUG=chrome-os-partner:51537 TEST=panel backlight still enabled on Gru as before. The rest of the GPIOs are used in the upcoming patches. Change-Id: I54ef3e8dd79670bdb037baeec91430113d11bcc1 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: c58788026f28af52c650da0159b93d97269ca4a9 Original-Change-Id: I1a6c5b5beb82ffcc5fea397e8e9ec2f183f4a7e0 Original-Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/346219 Original-Tested-by: Shunqian Zheng <zhengsq(a)rock-chips.com> Reviewed-on: https://review.coreboot.org/18176 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth(a)google.com> See https://review.coreboot.org/18176 for details. -gerrit

1 0

Patch merged into coreboot/master: nb/x4x/raminit: Fix programming dram timings
by gerrit＠coreboot.org 22 Jan '17

22 Jan '17

the following patch was just integrated into master: commit eee4f6b224b897184327539fcbeb23f9b26f02d9 Author: Arthur Heymans <arthur(a)aheymans.xyz> Date: Tue Jan 3 00:49:45 2017 +0100 nb/x4x/raminit: Fix programming dram timings The results were obtained by comparing the MCHBAR registers of vendor bios with coreboot at the same dram timings. This fixes 2 issues: * 1333MHz fsb CPUs were limited to 667MHz ddr2 speeds, because with 800MHz raminit failed; * 1067MHz fsb CPUs did not boot when second dimm slot was populated. TESTED on ga-g41m-es2l on 800, 1067 and 1333MHz CPUs with DDR2 667 and 800MHz dimms. Change-Id: I70f554f97b44947c2c78713b4d73a47c06d7ba60 Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> Reviewed-on: https://review.coreboot.org/18022 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h(a)gmx.de> See https://review.coreboot.org/18022 for details. -gerrit

1 0

Patch merged into coreboot/master: Makefile.inc: Explicitly set GNU11 as C language standard
by gerrit＠coreboot.org 22 Jan '17

22 Jan '17

the following patch was just integrated into master: commit acbb70b810c6eb17e403c37fa2888b479e5b23a9 Author: Paul Menzel <pmenzel(a)molgen.mpg.de> Date: Tue Nov 29 10:30:44 2016 +0100 Makefile.inc: Explicitly set GNU11 as C language standard Different compiler versions use a different C language standard by default. GCC 4.9 uses GNU89 by default [1], while GCC 5.x uses GNU11 [2]. The discussion on the mailing list in thread *[RFC] Setting C99 by default* [3] resulted in the preference of C11, which results in build errors. So explicitly set it to GNU11, which is also what the current coreboot toolchain with GCC 5.3 is using. [1] https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/C-Dialect-Options.html [2] https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Standards.html [3] https://www.coreboot.org/pipermail/coreboot/2016-November/082541.html Change-Id: If1569618f8044925ff72dcf3543480b34d4f90d6 Signed-off-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Reviewed-on: https://review.coreboot.org/17636 Reviewed-by: Julius Werner <jwerner(a)chromium.org> Reviewed-by: Arthur Heymans <arthur(a)aheymans.xyz> Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply(a)raptorengineeringinc.com> See https://review.coreboot.org/17636 for details. -gerrit

1 0

Patch merged into coreboot/master: mainboard/google/reef: Increase TSR1 trigger point
by gerrit＠coreboot.org 22 Jan '17

22 Jan '17

the following patch was just integrated into master: commit 72353056852f5fec15763f2b8ab42e6931c354fb Author: Tim Chen <Tim-Chen(a)quantatw.com> Date: Fri Jan 20 11:23:44 2017 +0800 mainboard/google/reef: Increase TSR1 trigger point Update the DPTF parameters based on thermal test result. (ZHT_DPTF_EVT2_v0.4_20170120.xlsx) 1. Update DPTF TSR1 passive trigger point. TSR1 passive point: 46 BUG=chrome-os-partner:60038 BRANCH=master TEST=build and boot on electro dut Change-Id: If35e4cf2dbf7c506534c52a052598f6204d5315a Signed-off-by: Tim Chen <Tim-Chen(a)quantatw.com> Reviewed-on: https://review.coreboot.org/18183 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin(a)chromium.org> See https://review.coreboot.org/18183 for details. -gerrit

1 0

Patch merged into coreboot/master: google/eve: Fixes for devicetree settings
by gerrit＠coreboot.org 22 Jan '17

22 Jan '17

the following patch was just integrated into master: commit 949e34c3ee85524f5b0a27b72d3064752aa3d097 Author: Duncan Laurie <dlaurie(a)chromium.org> Date: Sat Jan 21 19:11:37 2017 -0800 google/eve: Fixes for devicetree settings The devicetree settings were incorrect in a few places with respect to the SOC and board design: - IMVP8 VR workaround is for MP2939 and not MP2949 on Eve - IccMax values are incorrect according to KBL-Y EDS - USB2[6] is incorrectly labeled - I2C touch devices do not need probed as they are not optional - PCIe Root Port 5 should be enabled - I2C5 device should not be enabled as it is unused BUG=chrome-os-partner:58666 TEST=manually tested on Eve board Change-Id: I74e092444ead4b40c6d8091b80a691d44e2c6c7d Signed-off-by: Duncan Laurie <dlaurie(a)chromium.org> Reviewed-on: https://review.coreboot.org/18200 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin(a)chromium.org> See https://review.coreboot.org/18200 for details. -gerrit

1 0

← Newer
1
...
22
23
24
25
26
27
28
...
86
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit January 2017