[U-Boot] Image copy to ram

[Matthias Weisser <weisserm@arcor.de>]

Am 12.04.2011 21:12, schrieb Mike Frysinger:
> On Tuesday, April 12, 2011 14:47:46 Matthias Weisser wrote:
>> Am 12.04.2011 18:20, schrieb Mike Frysinger:
>>> On Tuesday, April 12, 2011 04:01:18 Matthias Wei?er wrote:
>>>> I looked into the documentation but I can't find a command which copies
>>>> an image from one address to another.
>>>
>>> you mean 'cp' ?
>>
>> Well, not exactly. cp doesn't know anything about the size of an image
>> and is, compared to a simple memcpy or even an optimized version of
>> memcpy, painfully slow which would eat up my expected performance
>> improvements. A quick hack showed that a "imcpy" command could save me
>> some 400ms on boot time which is about 50% of the total time spend in
>> u-boot.
> 
> it prob makes more sense to make it an optional subcommand to bootm.  however, 

Good point. I'll have a look into this.

I suggested an extra command so that nothing will be broken by the new code.

> i wonder why even bother with the double reads.  if we assume that a valid crc 
> is going to happen the vast majority of the time, we should tailor to that, 
> and taking a perf hit in the edge cases where the crc is invalid is fine.
> 
> in other words, let's see about merging the decompression and verification 
> steps so that there is only ever one read.

This could be done I think. But you will then still pay for the 8 bit
memory accesses (on a 16 bit flash device) and/or noneffective usage of
page mode flash. It would be a bigger change to read only small chunks
(say 1k or so) of the image to RAM and decompress them "on the fly".
This would be nicest solution but way harder to implement.

I did some measurements and I think the simplest way is to copy the
whole image to RAM and then checksum and decompress it. The flash
reading is then near the theoretical limit (I can do some additional
measurements tomorrow) and if the stuff is in RAM we have much higher
data rates and caching (if enabled) which boosts performance quite a bit.

> dont compression routines have crc checking built into them anyways ?

Don't know. But after quick scanning of the LZO decompression I found
this comment:

/* don't care about the file name, and skip checksum */ :-)

Regards,
Matthias