[U-Boot] Image copy to ram

[U-Boot] Image copy to ram

[Matthias Weißer]

Hi

I looked into the documentation but I can't find a command which copies 
an image from one address to another. This would be extremly useful for 
me as reading from (uncached) flash is way slower then reading from 
cached SDRAM. Currently booting is done by a simple bootm. This requires 
that the image is read from flash twice (once for checksum and once for 
decompression) If the image is copied to DRAM first it has to be read 
from flash only once. Checksum calculation and decompression is done in 
SDRAM which saves me about 500ms on my system. A further optimization 
would be to do the checksum calculation while copying the image to SDRAM 
which would save some more ms.

So, if there is no such command I am willing to implemt 'imcpy'.


Regards,
Matthias

[U-Boot] Image copy to ram

[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' ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110412/e9932e74/attachment.pgp 

[U-Boot] Image copy to ram

[Matthias Weisser]

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.

Regars,
Matthias

[U-Boot] Image copy to ram

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

dont compression routines have crc checking built into them anyways ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110412/c2e48aca/attachment.pgp 

[U-Boot] Image copy to ram

[Matthias Weisser]

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