[U-Boot] 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
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
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
Dear Mike Frysinger,
In message 201001190415.22075.vapier@gentoo.org you wrote:
...
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.
See the attachment to the web page I referenced above.
hmm, i'm not sure we've done speed tests yet. i'll poke our guys about it.
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 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.
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
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@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
participants (3)
-
Ken MacLeod -
Mike Frysinger -
Wolfgang Denk