Hi Wolfgang,
Thanks for the reply!
> Why using such an odd address as 0x8055b728?
That is a symptom of the system I'm working on...!
> Just follow the rules and never download the image to an address range
> that overlaps with the area where the image will be unpacked / loaded
> to.
I'd wondered if that was the case originally and tested this by
changing the download address to +32MB higher. This behaved with
exactly the same failure so I think that while it's a more sensible
thing to do it's a red herring with regards to what I'm seeing with
the memmove().
> Please be aware that is just 365 KB above your load address, and I
> guess your kernel image is way bigger than 365 KB.
Yep, I'm aware of this but I'm not keen to meddle too much with an
existing working system! Despite it being a bit dubious (and most
likely a failure if a compressed image) it works due to the way that
for uncompressed images memmove_wd() is implemented in that it copies
in smallish chunks and hence doesn't overwrite itself.
>> This actually copies the image 'payload' instead of the whole uImage
>> thereby dropping 64 bytes from the front of the copy and moving the
>> entry point. (I've verified this by breaking into the process and
> It does not "move the entry point". The entry point address is a
> constant address and does never move.
If I add some debugging, I find that in the situation previously
mentioned (and equivalently if I download higher too, see above) what
happens is that in bootm_load_os() I find that at the point we reach
the memmove_wd() to move the uncompressed image :
load_start = 0x8055b798
image_len = 0x4c11c0
blob_start = 0x8055b758
blob_end = 0x80a1c958
because the memmove_wd() is called to copy to load_start, as you can
see this copies from 64 bytes above the start of the uImage. Because
of this the whole image shifts down by 64 bytes relative to the
loadaddr compared to if we'd manually downloaded the uImage to the
load address (Also, note the value of image len - the actual size of
the uImage is 0x4c1200 - i.e. the same as blob_end - blob_start)
This logic looks like :
if (load == blob_start) {
printf (" XIP %s ... ", type_name);
} else {
printf (" Loading %s ... ", type_name);
memmove_wd ((void *)load, (void *)image_start,
image_len, CHUNKSZ);
}
The logic here checks (load == blob_start) for XIP i.e. that the blob
state resides at the load address. Following this logic in isolation,
why does the memmove_wd() move the image to image_start instead of
blob_start if we want that to be at loadaddr as in the first check for
XIP? My understanding is that after this logic the uImage should
reside at exactly the same location whether you have followed either
the if or the else path...?
Having said that, I just checked one of our non mips boards (ARM1176)
and it seems to handle this same situation OK so I'm wondering if it's
something peculiar to the port we're working with or perhaps the MIPS
code...? My guess is that maybe it's something kernel related rather
than in u-boot.
Cheers,
~Pev
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
