[U-Boot] Image copy to ram
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
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
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
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
participants (3)
-
Matthias Weisser -
Matthias Weißer
-
Mike Frysinger