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

[Alexander Stein]

Dear Wolfgang,

Am Donnerstag, 5. Mai 2011, 07:32:20 schrieb Wolfgang Denk:
> 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.

I was digging into this problem for a short time. And yes, the CRC 
checksumcalculation takes about 25ms each run. So setenv is called for each 
stdin,stdout and stderr. which sums up to ~75ms.
So you're right this is the old environment code. Here a dcache will speed up 
the execution of course.
But our standard startup just stars U-Boot and copies the Linux kernel into 
RAM and starts it. There is not much use of dcache during copy here.

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

It is connected 16-bit like most devices only support, but it is setup to use 
page read mode.

> And your memory timings?

Should be pretty good.

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

Yes, from RAM to RAM, dcache will help a lot. But we neither copy from RAM to 
RAM nor do we uncompressing.

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

Mh, this might be an option for further ports.

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

Well, as already said this is related to CRC calculation of environment. I did 
a fast port to v2011.03 and the setenv is a lot faster, which is due the new 
env code base.
But I also noticed the time until kernel_entry is called is about 30ms later 
after reset than on the old code base. But I didn't investigate any time 
further to see what caused this. But AFAICS also the new U-Boot code doesn't 
enable dcache on ARM1136 either.

Regards,
Alexander