Dear Alexander Stein,
In message <201008090857.32705.alexander.st...@systec-electronic.com> you wrote:
>
> > > common/image.c | 11 ++++++++---
> > > 1 files changed, 8 insertions(+), 3 deletions(-)
> >
> > Why would this be needed? Do you have an error scenario?
>
> IIRC the problem arose when i downloaded my image to 0x20000000 (SD-RAM)
> using
> TFTP and my Linux kernel entry point was at 0x20008000. So when
Don;t do this, then. Such kind of overlap has never been supported.
Even if it would work in your case of uncompressed images, it is bound
to fail for compressed ones where the uncompressed code grows faster
then compressed data get consumed.
> > > + if (to <= from)
> > > + {
> > > + memmove (to, from, tail);
> > > + to += tail;
> > > + from += tail;
> > > + } else {
> > > + memmove (to + len - tail, from + len - tail, tail);
> >
> > In which way is this supposed to allow overlapping memory areas?
>
> With this change u-boot starts to copy from the end to the beginning thus
> preventing overriding the source. This change was adopted from memmove
> (lib/string.c) which handles this case correctly.
You are just shifting the problem to another area, but you are not
solving it. Without your patch there is a problem when the initial
area overlaps, with your problem there is one when the tail overlaps.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The two most common things in the universe are hydrogen and stupi-
dity."
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
