[U-Boot-Users] Uncompression of image takes time.

[Jerry Van Baren]

> Adarsh Babu wrote:
>> Jerry Van Baren <gerald.vanbaren <at> smiths-aerospace.com> writes:
>> 
>>> Adarsh Babu wrote:
>>>> Hi,
>>>>
>>>> I have an image which is 1.5MB in size after compression, thats is done 
>> for 
>>>> MCF5271. When i try to load this on a MCF5271 eval board using u-boot 
>> 1.2.0 it 
>>>> takes about 25 secs to just uncompress. I loaded a MCF5272 eval board with 
>> U-
>>>> Boot 1.2.0 and then tried to start the same image(which was done for 
>> MCF5271). 
>>>> It was very fast. The checksum verification finish off in a second and 
>>>> uncompression in 10 seconds ! 
>>>>
>>>> The clock configurations for both are provided below:
>>>> M5272C3.h
>>>> define CFG_HZ			1000
>>>> #define CFG_CLK			66000000
>>>>
>>>> M5271EVB.h:
>>>> define CFG_HZ			1000000
>>>> #define CFG_CLK			100000000
>>>>
>>>> What should I do to get the image to uncompress faster in the MCF5271 EVB?
>>>>
>>>> Regards,
>>>> Adarsh.
>>> 1) Your CFG_HZ looks like a problem: it should be 1000 and your timer 
>>> tick interrupt should be running 1000 times per second to match.  If you 
>>> are indeed ticking 1,000,000 times per second, you are spending all of 
>>> your processor time in your timer ISR.
>>>
>>> 2) Why is your image 1.5MB?  I suspect you have large unused areas of 
>>> memory (typically due to ISR vectors, followed by a huge unused gap, 
>>> followed by the code).  If you fix your image size (assuming it is 
>>> broken), the checksum and uncompress will be much faster.
>>>
>>> gvb
>>>
>> 
>> Hi Jerry,
>> 
>> I tried the same after modifying the CFG_HZ to 1000. But i still get the same 
>> result. Its as if there is no effect. The image size is 1.5MB becos its just 
>> not a kernel image. Its kernel + our application. Could this be a problem with 
>> the timer initialization and cofiguration?
>> 
>> Regards,
>> Adarsh.
> 
> Hi Adarsh,
> 
> I don't have any M527x experience, so I cannot say anything with detail. 
>   Just changing CFG_HZ quite likely is not sufficient - usually you need 
> to configure the timers in your hardware initialization routines and 
> CFG_HZ simply reflects the choices you (or someone) made at 
> initialization time.
> 
> If this is the case, and if you timer is really ticking at 1/100 your 
> master clock rate, that would cause serious slowing of execution.  You 
> will have to chase down what CFG_HZ is used for and how your hardware 
> timer is initialized.  I simply don't have the knowledge or information.
> 
> HTH,
> gvb

Hi Adarsh,

Other generic things that can cause slow execution are:
* Caches disabled (data and/or instruction)
   * Caches are very sharp knives: they can slice and
       dice quickly and finely, or they can turn on
       you and slice your fingers off.  For initial board
       bring-up, caches are usually disabled.
* Memory configuration
   * The memory interface is typically initialized with
       the slowest settings possible on power up: if they
       are not optimized, the CPU will run slower than it
       could run.

Let us know what you find, so the next person down this path will find 
the solution  rather than just the problem.  (The internet: the worlds 
largest knowledge base hidden in a vast wasteland of ignorance.)

HTH,
gvb