On 04.02.2008 00:32, ron minnich wrote:
> On Feb 3, 2008 3:26 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> 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)
{
return CONFIG_DEFAULT_CONSOLE_LOGLEVEL;
@@ -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);
va_end(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
version?
Thanks,
Carl-Daniel
--
coreboot mailing list
[email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
