[U-Boot] boot-up time optimization. Where to start?

[Alexander Stein]

Dear Wolfgang,

Am Montag, 2. Mai 2011, 19:00:47 schrieb Wolfgang Denk:
> In message <201105021640.27241.alexander.stein at systec-electronic.com> you 
wrote:
> > Ok, let me be more precise on this.
> > We used U-Boot v2010.09 on a custom board running on an I.MX35 (ARM1136).
> 
> Let's summarize known facts:
> 
> 1. You are talking about an out-of-tree port, i. e. code which is
>    completely unknown here, so it is basicly impossible to comment.
>    We can barely speculate.

I'm aware of that. But on the other hand, cmd_nvedit.c and console.c are both 
generic parts.
As Detlev have written, this is not the cause of the problem. Let's see if I 
find time again for this.

> 2. This is an ARM board.
> 
> 3. This is an old version before cache support for ARM was added.

This specific version was selected due to relocation problems on ARM. But I 
expect the dcache doesn't have that big influence on the named code part as 
the environment is already in RAM.

> > We noticed the following code snippet took relatively long.
> > 
> > From common/console.c in console_init_r(void):
> > > /* Setting environment variables */
> > > for (i = 0; i < 3; i++) {
> > > 
> > > 	setenv(stdio_names[i], stdio_devices[i]->name);
> > > 
> > > }
> > 
> > We added PIN toggling around this part of code and measured something
> > >100ms. A collegue said it was ~100ms, I remembered ~500ms. Dunno who is
> > right.
> 
> Both numbers are way off.
> 
> Let me speculate: (I) you have a _huge_ environment allocated for your
> board, probably > 100 KiB or more;

> Environment size: 2098/131067 bytes

So, no.

> (II) you are loading it from a slow
> storage device, probably NAND flash;

The environment is stored in NOR-Flash. So, no.

> (III) you are running on a narrow
> system bus (16 bit) with non-optimal RAM timings;

It is using a 32-Bit RAM-Bus. So, no.

> (IV) you do all this
> with caches turned off;

dcaches should be off, while icaches are on. So yes and no.

> (V) you measure some numbers but you don;t
> understand what they mean.

These numbers show me that this part of code increases the start time of a 
considerable amount.
The workaround resulted in a faster startup without notable side effect.
I'm aware this is not the fix of the problem.
So yes and no.

> I bet some beer that at least 3 of these speculations hit the point.

You better not want to bet here :-)

Regards,
Alexander