[coreboot] patch: init gx cache earlier.

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Feb 4 02:32:46 CET 2008

On 04.02.2008 00:32, ron minnich wrote:
> On Feb 3, 2008 3:26 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> Have you tried adding a "fillup" file to the lar which occupies the
>> remaing unsused space? That should help a lot.
> That's no longer the big time item. The big time item is now the
> decompress, which seems to run
> at 4 kilobytes per second.

Ouch. That really hurts. We probably want to add print_conf() from
v2/src/mainboard/pcengines/alix1c/mainboard.c to v3. Comparing the v3
output of print_conf to the v2 output may be enlightening. I don't have
any Geode LX boards, so I can't really test.

>> Besides that, having a boot time breakdown to find the worst offenders
>> is an investment into the future. But how should we implement that?
>> Maybe a Kconfig variable which adds TSC timestamps to all printk()
>> calls? While rdtsc() is slow, it is not slow enough to actually show up
>> in profiles if we use it together with printk.
> we can just put the option in kconfig. we had this option in v2.

Sorry, I can't find such an option in v2 and the svn log also didn't
turn up any hits. Could you point me to a specific file and/or revision?
I have a (wrong due to varargs for vtxprintf) prototype patch for v3:

Index: lib/console.c
--- lib/console.c	(Revision 571)
+++ lib/console.c	(Arbeitskopie)
@@ -7,6 +7,8 @@
 int vtxprintf(void (*)(unsigned char, void *arg), 
 		void *arg, const char *, va_list);
+#define rdtscl(low) __asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx")
 static int console_loglevel(void)
@@ -34,11 +36,15 @@
 	va_list args;
 	int i;
+	u32 tstamp;
 	if (msg_level > console_loglevel()) {
 		return 0;
+	rdtscl(tstamp);
+	vtxprintf(console_tx_byte, (void *)0, "[tsc %d] ", tstamp);
 	va_start(args, fmt);
 	i = vtxprintf(console_tx_byte, (void *)0, fmt, args);

>> I'm not sure about this patch. It increases stage0/stage1 size and seems
>> to move northbridge init to a generic arch directory. How northbridge
>> specific is geodelxinit.c? Is it a piece of northbridge code? We could
>> link northbridge/amd/geodelx/geodelxinit.c into stage1 even if it is
>> inside the northbridge dir.
> The LX does not have the kind of clean breakdown of components we are
> used to on other systems. I don't think you can say geodelxinit is
> "northbridge specific" or not. I am happy to move it back to the
> northbridge directory and just link it in.

Ah yes, the Geode architecture.

> We've got to run this in stage1 IMHO. We can't wait until stage2 phase
> 2 to turn on cache. It's just way too slow.

Indeed. Without the file move, the patch is fine. Could you post a new


More information about the coreboot mailing list