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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
