mkimage and XIP vs entry point

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.

the Blackfin kernel has long been using an entry point way in the middle of the text. as an example, the typical output of our last release:

$ bfin-uclinux-mkimage -l /tftpboot/uImage
Image Name:   Linux-2.6.28.10-ADI-2009R1.1-svn
Created:      Fri Jan 15 17:45:22 2010
Image Type:   Blackfin Linux Kernel Image (gzip compressed)
Data Size:    6370016 Bytes = 6220.72 kB = 6.07 MB
Load Address: 00001000
Entry Point:  002f3938

this is because we store most of head.S (like __start) in the .init.text section. this code is never going to be returned to, so putting it in .text or even the very start of .text is pointless. when we added ROM kernel support, this no longer worked -- mkimage demands that the entry point be located right after the load address / uimage header.

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 ?
-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/20100118/462640fd/attachment.pgp

Dear Mike Frysinger,

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.

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

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: wd at denx.de
In accord with UNIX philosophy, Perl gives you enough  rope  to  hang
yourself.              - L. Wall & R. L. Schwartz, _Programming Perl_

thanks for the background

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

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

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

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

Dear Mike Frysinger,

...

See the attachment to the web page I referenced above.

We repeated such tests some times later, not for XIP but for the root file system. The results were basicly the same - it was faster to load compressed data from NOR than to read the compressed data.

I doubt you can fit it in a conceptually clean way into the uImage concept. But feel free to give it a try.

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: wd at denx.de

Re. XIP, we recently did some boot time optimizations and found that if we loaded the uncompressed kernel-only uImage to RAM (diskboot) with the load address in the uImage the same as the load address given to diskboot and the execute addres at +64 then we shaved off 0.15 seconds by letting the kernel do its own relocation instead of U-Boot relocating the whole image. (PPC8247 at 66MHz bus, 2.9MB kernel)

Just to be clear, we're *not* using an XIP kernel, we're just letting it trigger the XIP start condition in cmd_bootm and letting the kernel do its own relocation magic. Using an XIP kernel at the RAM-loaded location would have saved the other 0.10 seconds but it didn't seem worth the effort to update and integrate the XIP patch.

-- Ken