Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2822
-gerrit
commit 15f7993590b90e61ee85ce4bf1d9a3e8b5b5787f
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Fri Mar 1 17:00:39 2013 -0600
rmodule: correct ordering of bss clearing
This patch fixes an issue for rmodules which are copied into memory
at the final load/link location. If the bss section is cleared for
that rmodule the relocation could not take place properly since the
relocation information was wiped by act of clearing the bss. The
reason is that the relocation information resides at the same
address as the bss section. Correct this issue by performing the
relocation before clearing the bss.
Change-Id: I01a124a8201321a9eaf6144c743fa818c0f004b4
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
---
src/lib/rmodule.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/lib/rmodule.c b/src/lib/rmodule.c
index 60c89f0..d36f9f3 100644
--- a/src/lib/rmodule.c
+++ b/src/lib/rmodule.c
@@ -241,14 +241,18 @@ static int __rmodule_load(void *base, struct rmodule *module, int clear_bss)
* In order to load the module at a given address, the following steps
* take place:
* 1. Copy payload to base address.
- * 2. Clear the bss segment.
- * 3. Adjust relocations within the module to new base address.
+ * 2. Adjust relocations within the module to new base address.
+ * 3. Clear the bss segment last since the relocations live where
+ * the bss is. If an rmodule is being loaded from its load
+ * address the relocations need to be processed before the bss.
*/
module->location = base;
rmodule_copy_payload(module);
+ if (rmodule_relocate(module))
+ return -1;
if (clear_bss)
rmodule_clear_bss(module);
- return rmodule_relocate(module);
+ return 0;
}
int rmodule_load(void *base, struct rmodule *module)
the following patch was just integrated into master:
commit 94998c4d3fa1c9f1f0aaf3623a070e8c7e364f8b
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Tue Jan 22 13:54:12 2013 -0600
lynxpoint: Add cbfs_load_payload() implementation
SPI accesses can be slow depending on the setup and the access pattern.
The current SPI hardware setup to cache and prefetch. The alternative
cbfs_load_payload() function takes advantage of the caching in the CPU
because the ROM is cached as write protected as well as the SPI's
hardware's caching/prefetching implementation. The CPU will fetch
consecutive aligned cachelines which will hit the ROM as
cacheline-aligned addresses. Once the payload is mirrored into RAM the
segment loading can take place by reading RAM instead of ROM.
With the alternative cbfs_load_payload() the boot time on a baskingridge
board saves ~100ms. This savings is observed using cbmem.py after
performing warm reboots and looking at TS_SELFBOOT_JUMP (99) entries.
This is booting with a depthcharge payload whose payload file fits
within the SMM_DEFAULT_SIZE (0x10000 bytes).
Datapoints with TS_LOAD_PAYLOAD (90) & TS_SELFBOOT_JUMP (99) cbmem entries:
Baseline Alt
-------- --------
90:3,859,310 (473) 90:3,863,647 (454)
99:3,989,578 (130,268) 99:3,888,709 (25,062)
90:3,899,450 (477) 90:3,860,926 (463)
99:4,029,459 (130,008) 99:3,890,583 (29,657)
90:3,834,600 (466) 90:3,890,564 (465)
99:3,964,535 (129,934) 99:3,920,213 (29,649)
Booted baskingridge many times and observed 100ms reduction in
TS_SELFBOOT_JUMP times (time to load payload).
Change-Id: I27b2dec59ecd469a4906b4179b39928e9201db81
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2783
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Build-Tested: build bot (Jenkins) at Tue Mar 19 19:14:14 2013, giving +1
Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Tue Mar 19 20:21:49 2013, giving +2
See http://review.coreboot.org/2783 for details.
-gerrit
David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2832
-gerrit
commit d3e6ce1ffd918180713069e30b128abc289ceeae
Author: David Hendricks <dhendrix(a)chromium.org>
Date: Tue Mar 19 11:55:44 2013 -0700
Remove __PRE_RAM__ guard around log2 prototype
The prototype for log2() should be visible everywhere except romcc,
which is handled by an #ifndef __ROMCC__ just above this guard.
Change-Id: I713569ed95bd5427db0e5dc3e3f0499bd1914297
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
---
src/include/lib.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/include/lib.h b/src/include/lib.h
index 9d81085..31b8669 100644
--- a/src/include/lib.h
+++ b/src/include/lib.h
@@ -24,10 +24,8 @@
#include <stdint.h>
#ifndef __ROMCC__ /* romcc doesn't support prototypes. */
-#ifndef __PRE_RAM__ /* Conflicts with romcc_io.h */
-/* Defined in src/lib/clog2.c */
+/* Defined in src/lib/clog2.c (note: conflicts with romcc_io.h) */
unsigned long log2(unsigned long x);
-#endif
/* Defined in src/lib/lzma.c */
unsigned long ulzma(unsigned char *src, unsigned char *dst);
Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2826
-gerrit
commit baa3d3c366630243bf074bde32e82964d07ddbf7
Author: David Hendricks <dhendrix(a)chromium.org>
Date: Mon Mar 18 23:27:09 2013 -0700
google/snow: workaround a buggy recovery mode GPIO reading
We don't really have a recovery mode GPIO. Instead it's fed into
the SoC by another chip. And for whatever reason we're reading
a weird value.
Hard-code as a workaround.
Change-Id: I02703e80c953d463706757c9398b6afda4941f8d
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
---
src/mainboard/google/snow/chromeos.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mainboard/google/snow/chromeos.c b/src/mainboard/google/snow/chromeos.c
index 1a98244..6694b59 100644
--- a/src/mainboard/google/snow/chromeos.c
+++ b/src/mainboard/google/snow/chromeos.c
@@ -63,7 +63,8 @@ void fill_lb_gpios(struct lb_gpios *gpios)
/* Recovery: active high */
gpios->gpios[1].port = EXYNOS5_GPY1;
gpios->gpios[1].polarity = ACTIVE_HIGH;
- gpios->gpios[1].value = s5p_gpio_get_value(&gpio_pt1->y1, FORCE_RECOVERY_MODE);
+// gpios->gpios[1].value = s5p_gpio_get_value(&gpio_pt1->y1, FORCE_RECOVERY_MODE);
+ gpios->gpios[1].value = 0;
strncpy((char *)gpios->gpios[1].name,"recovery", GPIO_MAX_NAME_LENGTH);
/* Lid: the "switch" comes from the EC */
Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2825
-gerrit
commit d08a9b37cd48993e0987ff823abc1fe39efd9e32
Author: David Hendricks <dhendrix(a)chromium.org>
Date: Mon Mar 18 21:54:13 2013 -0700
google/snow: fix a GPIO array index
This fixes a trivial error with the recovery mode GPIO index.
Change-Id: I7290c1e23cdddaf91c9021d4e4252c0c772b6eab
Signed-off-by: David Hendricks <dhendrix(a)chromium.org>
---
src/mainboard/google/snow/chromeos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mainboard/google/snow/chromeos.c b/src/mainboard/google/snow/chromeos.c
index 14da49c..1a98244 100644
--- a/src/mainboard/google/snow/chromeos.c
+++ b/src/mainboard/google/snow/chromeos.c
@@ -63,7 +63,7 @@ void fill_lb_gpios(struct lb_gpios *gpios)
/* Recovery: active high */
gpios->gpios[1].port = EXYNOS5_GPY1;
gpios->gpios[1].polarity = ACTIVE_HIGH;
- gpios->gpios[2].value = s5p_gpio_get_value(&gpio_pt1->y1, FORCE_RECOVERY_MODE);
+ gpios->gpios[1].value = s5p_gpio_get_value(&gpio_pt1->y1, FORCE_RECOVERY_MODE);
strncpy((char *)gpios->gpios[1].name,"recovery", GPIO_MAX_NAME_LENGTH);
/* Lid: the "switch" comes from the EC */
the following patch was just integrated into master:
commit 633f11274fcbc9442be0be0d0bc531f43a74981b
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Wed Feb 6 15:28:40 2013 -0600
x86: remove stack definition in linker script
In order to prepare the ramstage to be linked by the rmodule linker the
stack needs to be self-contained within the ramstage objects. The
reasoning is that the rmodule linker provides a way to define a heap,
but it doesn't currently have a region for the stack.
The downside to this is that memory footprint of the ramstage can change
when compared before this change. The size difference stems from the
link ordering of the objects as the stack is now defined within
c_start.S. The size fluctuation ranges from 0 to CONFIG_STACK_SIZE - 1
because of the previous behavior or aligning to CONFIG_STACK_SIZE. It
should be noted that such an alignment is unnecessary for 32-bit x86 as
the alignment requirement for the stacks are 4 byte alignment. Also the
memory footprint is still dominated by CONFIG_RAMTOP and CONFIG_RAMBASE.
Change-Id: I63a4ddd249104bc27aff2ab6b39fc6db12b54028
Signed-off-by: Aaron Durbin <adurbin(a)chromium.org>
Reviewed-on: http://review.coreboot.org/2785
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones(a)se-eng.com>
Build-Tested: build bot (Jenkins) at Tue Mar 19 03:35:58 2013, giving +1
See http://review.coreboot.org/2785 for details.
-gerrit