Dear Mike Frysinger,
In message 201001181955.55856.vapier@gentoo.org you 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.
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)
We wanted to use uImages (to keep the checksum verification etc.), and this old format did not provide any spare flags for information like XIP etc. This is where the code is coming from.
I am aware that it is ugly and most likely does not even work wih recent kernels, not even on PPC.
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.
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!]
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.
Best regards,
Wolfgang Denk