the following patch was just integrated into master:
commit b142b84afb2f870f68a16bac59568242ac04600f
Author: Nicolas Reinecke <nr(a)das-labor.org>
Date: Sat Oct 3 17:32:38 2015 +0200
northbridge/intel/nehalem: Fix native VGA init
Building an image for the Lenovo X201 with native graphics
initialization selected fails due to the changes introduced by commit
a3b898aa (edid: Clean-up the edid struct).
Same as in 11738 / 11585 / 11491
Change-Id: I4233a4ce2f5423c7ebdad68e8059cd34ac61cfaa
Signed-off-by: Nicolas Reinecke <nr(a)das-labor.org>
Reviewed-on: http://review.coreboot.org/11787
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
See http://review.coreboot.org/11787 for details.
-gerrit
the following patch was just integrated into master:
commit 715a18e451a454ed5d6c3e9215802ad7b94885ee
Author: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Date: Fri Oct 2 17:01:22 2015 -0700
drivers/uart/Kconfig: Select 8250 mem when 8250 mem32 is enabled
Users of DRIVERS_UART_8250MEM_32 would have to also select
DRIVERS_UART_8250MEM to avoid missing Kconfig dependencies. Instead,
do what the OXPCIE driver dies and select the appropriate options.
Change-Id: I40d93df024fcb3a9ad6dc51d6a5966e7b1b6c07f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Reviewed-on: http://review.coreboot.org/11786
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
See http://review.coreboot.org/11786 for details.
-gerrit
Alexandru Gagniuc (mr.nuke.me(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11781
-gerrit
commit 36229de33d57157e2b01b65fcb80eba47234ba80
Author: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Date: Fri Oct 2 10:59:13 2015 -0700
x86/bootblock: Use LDFLAGS_bootblock to enable garbage collection
The x86 bootblock linking never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
---
src/arch/x86/Makefile.inc | 4 ++--
src/arch/x86/id.ld | 2 +-
src/cpu/intel/fit/fit.ld | 2 +-
src/cpu/x86/16bit/reset16.ld | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/arch/x86/Makefile.inc b/src/arch/x86/Makefile.inc
index f16edcd..1bda5f6 100644
--- a/src/arch/x86/Makefile.inc
+++ b/src/arch/x86/Makefile.inc
@@ -106,9 +106,9 @@ $(objgenerated)/bootblock.inc: $(src)/arch/x86/$(subst ",,$(CONFIG_BOOTBLOCK_SOU
$(objcbfs)/bootblock.debug: $(obj)/arch/x86/bootblock.bootblock.o $(obj)/arch/x86/bootblock.bootblock.ld
@printf " LINK $(subst $(obj)/,,$(@))\n"
ifeq ($(CONFIG_ARCH_BOOTBLOCK_X86_32),y)
- $(LD_bootblock) -m elf_i386 --oformat elf32-i386 -static -o $@ -L$(obj) $< -T $(obj)/arch/x86/bootblock.bootblock.ld
+ $(LD_bootblock) $(LDFLAGS_common) -m elf_i386 --oformat elf32-i386 -static -o $@ -L$(obj) $< -T $(obj)/arch/x86/bootblock.bootblock.ld
else
- $(LD_bootblock) -m elf_x86_64 --oformat elf64-x86-64 -static -o $@ -L$(obj) $< -T $(obj)/arch/x86/bootblock.bootblock.ld
+ $(LD_bootblock) $(LDFLAGS_common) -m elf_x86_64 --oformat elf64-x86-64 -static -o $@ -L$(obj) $< -T $(obj)/arch/x86/bootblock.bootblock.ld
endif
diff --git a/src/arch/x86/id.ld b/src/arch/x86/id.ld
index cfd091d..99d13f1 100644
--- a/src/arch/x86/id.ld
+++ b/src/arch/x86/id.ld
@@ -1,6 +1,6 @@
SECTIONS {
. = (0xffffffff - CONFIG_ID_SECTION_OFFSET) - (__id_end - __id_start) + 1;
.id (.): {
- *(.id)
+ KEEP(*(.id))
}
}
diff --git a/src/cpu/intel/fit/fit.ld b/src/cpu/intel/fit/fit.ld
index 9ccfe82..5817e1d 100644
--- a/src/cpu/intel/fit/fit.ld
+++ b/src/cpu/intel/fit/fit.ld
@@ -1,6 +1,6 @@
SECTIONS {
. = 0xffffffc0;
.fit_pointer (.): {
- *(.fit_pointer)
+ KEEP(*(.fit_pointer))
}
}
diff --git a/src/cpu/x86/16bit/reset16.ld b/src/cpu/x86/16bit/reset16.ld
index a31a580..d0c4096 100644
--- a/src/cpu/x86/16bit/reset16.ld
+++ b/src/cpu/x86/16bit/reset16.ld
@@ -9,7 +9,7 @@ SECTIONS {
_ROMTOP = 0xfffffff0;
. = _ROMTOP;
.reset . : {
- *(.reset)
+ KEEP(*(.reset));
. = 15 ;
BYTE(0x00);
}
Alexandru Gagniuc (mr.nuke.me(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11248
-gerrit
commit 2e092a39b94470337fdf1886d6b5833577653277
Author: Patrick Rudolph <siro(a)das-labor.org>
Date: Mon Aug 17 19:24:12 2015 +0200
northbridge/intel/sandybridge: Fix random raminit failures
Issue observed:
Intel raminit works in about 50% of all test-cases on lenovo x220.
Problem solution:
Prefer a smaller valid value over the measured one for
initial timB timings.
Final testing result:
Tests on x220 shows that the issue was resolved.
The test system booted successfully ten times in a row.
Tests on Gigabyte GA-B75M-D3H revealed no regressions.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMM: "Crucial 2GB 256Mx64 CT2566aBA160BJ"
Change-Id: I1a115a45d5febf351d89721ece79eaf43f7ee8a0
Signed-off-by: Patrick Rudolph <siro(a)das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
---
src/northbridge/intel/sandybridge/raminit.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/northbridge/intel/sandybridge/raminit.c b/src/northbridge/intel/sandybridge/raminit.c
index 76f62a6..f732b6e 100644
--- a/src/northbridge/intel/sandybridge/raminit.c
+++ b/src/northbridge/intel/sandybridge/raminit.c
@@ -2266,7 +2266,17 @@ static void discover_timB(ramctr_timing * ctrl, int channel, int slotrank)
}
FOR_ALL_LANES {
struct run rn = get_longest_zero_run(statistics[lane], 128);
- ctrl->timings[channel][slotrank].lanes[lane].timB = rn.start;
+ if (rn.start < rn.middle) {
+ ctrl->timings[channel][slotrank].lanes[lane].timB = rn.start;
+ } else {
+ /* In this case statistics[lane][7f] and statistics[lane][0] are
+ * both zero.
+ * Prefer a smaller value over rn.start to prevent failures in
+ * the following write tests.
+ */
+ ctrl->timings[channel][slotrank].lanes[lane].timB = 0;
+ }
+
if (rn.all)
die("timB discovery failed");
printram("Bval: %d, %d, %d, %x\n", channel, slotrank,
Alexandru Gagniuc (mr.nuke.me(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/11247
-gerrit
commit 623c29b4ce72bcd318cbcadcd2b3da5992961a24
Author: Patrick Rudolph <siro(a)das-labor.org>
Date: Sun Aug 16 17:06:30 2015 +0200
nb/intel/sandybridge/raminit: Add edge write discovery check
Make sure edge write test results are sane.
Check rn.all to make sure rn.start and rn.end are valid.
Most likely the following test is going to fail on the same
rank anyway.
Change-Id: Ifa601406e6c74ceb8d70063be5ce1bf6bc512c18
Signed-off-by: Patrick Rudolph <siro(a)das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
---
src/northbridge/intel/sandybridge/raminit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/northbridge/intel/sandybridge/raminit.c b/src/northbridge/intel/sandybridge/raminit.c
index 9df102a..76f62a6 100644
--- a/src/northbridge/intel/sandybridge/raminit.c
+++ b/src/northbridge/intel/sandybridge/raminit.c
@@ -3130,6 +3130,8 @@ static void discover_edges_write_real(ramctr_timing * ctrl, int channel,
upper[lane] =
min(rn.end - ctrl->edge_offset[i], upper[lane]);
edges[lane] = (lower[lane] + upper[lane]) / 2;
+ if (rn.all || (lower[lane] > upper[lane]))
+ die("edge write discovery failed");
}
}
the following patch was just integrated into master:
commit 959478a763c16688d43752adbae2c76e7764da45
Author: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Date: Sat Oct 3 13:49:23 2015 -0700
Remove FSP Rangeley SOC and mohonpeak board support
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin(a)das-labor.org>
See http://review.coreboot.org/11790 for details.
-gerrit