[U-Boot] mkimage and XIP vs entry point

[Mike Frysinger]

On Tuesday 19 January 2010 03:55:15 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > the current mkimage requires XIP images to have their entry point set to
> > the load address + 64 bytes.  my question is simply, why ?  why cant the
> > entry point be an arbitrary location ?  i cant seem to find any technical
> > reason for this restriction.
> 
> It's a quick & dirty hack which has only hysterical reasons.

thanks for the background

> The reason for the 64 byte offset is that the classic uImage header
> takes 64 bytes, and that PowerPC always hat the entry point right at
> the start of the image. When we implemented this some 8 years ago we
> had only PowerPC (actually only MPC8xx) in mind, and AFAICT it has
> not been much used on other platforms or even more recent kernels
> than the 2.4.4 version we've been using by then (for details please
> see http://www.denx.de/wiki/view/DULG/ConfigureLinuxForXIP)

is that based on custom patches ?  i grepped arch/powerpc/ for "xip" (case 
insensitive) and got 0 results.

> We lost interest in this feature after we had it running and were
> able to measure actual results. The thing is, that with XIP you can
> save a few MB of RAM (2...3 with the 2.4.4 kernel), but you need much
> larger NOR flash (which is way more expensive than RAM), and boot
> time will usually become longer - on the systems we tested we usually
> found that it's faster to load a compressed image to RAM and
> uncompress it (ideally on the fly, but it's still faster when done in
> a second stage) and run it form RAM. Given the fact that processors
> have become much faster (compared to 8 years ago when we did these
> tests) but memory bandwidth is still about the same, the results today
> will be probably even more in favour of not using XIP.

hmm, i'm not sure we've done speed tests yet.  i'll poke our guys about it.

> > so what am i missing ?  or should i submit a patch to delete this check
> > from the mkimage tool and let the entry point be arbitrary like non-xip ?
> 
> If you have any configuration that is actually working for you, then
> please feel free to rework the code as needed. Don't be afraid of
> breaking anything - I don't think the existing code has been tested at
> all in the last N years, N > 5. [Any actual users of this please speak
> up - here and now!]

sounds good ... i'll put something together then

> Note that I would not attampt to support this feature today based on
> the old plain uImage format. I would rather see this being based on a
> FIT image.

i know you would ;).  but we dont do FIT kernels with Blackfin and dont 
currently have plans for doing them since this isnt a trivial thing to add 
support for.
-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/20100119/6fbd8951/attachment.pgp