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

[Wolfgang Denk]

Dear Alexander Stein,

In message <201105030848.17576.alexander.stein at systec-electronic.com> you wrote:
> 
> 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.

Your expectation is most likely completely wrong.  Reading from /
writing to uncached RAM is painfully slow compared to a system with
caches turned on.  And if you - as I speculate - need to checksum a
huge amount of data, this will delay things without need.


Are you also still using the old environment code in your port, or is
the new, hash table based one?  When using the old code, there are
additional penalties for using a needlessly big environment as each
call to setenv() will recalculate the checksum.


> > 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.

So, yes!  You cannot even read your own numbers correctly.

131067 = 128 KiB which _is_ > 100 KiB.

> > (II) you are loading it from a slow
> > storage device, probably NAND flash;
> 
> The environment is stored in NOR-Flash. So, no.

Especially on NOR flash there is no reason to use an environment size
of 128 KiB when you only use 2 KiB of it.

> > (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.

And your NOR flash?

And your memory timings?

> > (IV) you do all this
> > with caches turned off;
> 
> dcaches should be off, while icaches are on. So yes and no.

DC of makes things awfully slow.  See comments of commits c3330e9,
95c6f6d and 7e4a9e6 - for plain RAM bound operations like
copying/uncompressing an image from RAM to RAM switchign on the DC can
accelerate the system by a factor of up to >15.

> > (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.

You don;t even understand that you have > 100 KiB of environment size
which gets checksummed without need.

> 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 :-)

It appears I was right on accounts (I), (IV) and (V), it seems ;-)
And (III) is not clear yet.

Fact is, the code that you claim takes 100 (or 500) ms to run has no
potential for such a long run time unless your system is seriously
misconfigured.  I guess it runs at least 100 times faster on all
systems I have access to.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I dislike companies that have a we-are-the-high-priests-of-hardware-
so-you'll-like-what-we-give-you attitude. I like commodity markets in
which iron-and-silicon hawkers know that they exist to  provide  fast
toys for software types like me to play with..."    - Eric S. Raymond