[coyotos-dev] Looking for ideas - image loading

Godfrey Vassallo GVassallo at afcosystems.com
Tue Jan 29 11:03:28 EST 2008

How about "CAT"ing the individual files and then setting the entry address in the multiboot header to the module that understands how the file was put together and what to do with it? In this way the loader has no knowledge of the construction process and believes its dealing with one file. Additional formatting information (e.g., elf ) could be used by the embedded module.


From: coyotos-dev-bounces at smtp.coyotos.org on behalf of Jonathan S. Shapiro
Sent: Tue 1/29/2008 10:07 AM
To: coyotos-dev
Subject: [coyotos-dev] Looking for ideas - image loading

On PC's we can use multiboot for image loading, and we can therefore
store the mkimage output in a different file than the kernel.

On mature embedded systems, we can flash the kernel and the mkimage
output to different locations.

But on immature embedded systems we often don't have any way to load
more than one file. This is also an issue with some netboot

I am therefore wondering whether there is some simple way to merge the
kernel and the mkimage file.

So far, the best that I have come up with is to proceed as follows:

  1. Instead of performing a static link on the kernel, link it
     with -r to form a relocatable that can be processed again by
     the linker.

     [ We would do the static link here anyway as a guard against
       missing symbols. ]

  2. Add the mkimage file to the kernel binary image as a loadable
     segment in a final link step.

  3. Implement a script "coymerge" that is really a link step in

Does anyone know of a cleaner/better way to do this that is ready to


coyotos-dev mailing list
coyotos-dev at smtp.coyotos.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4812 bytes
Desc: not available
Url : http://www.coyotos.org/pipermail/coyotos-dev/attachments/20080129/e2bcd997/attachment.bin 

More information about the coyotos-dev mailing list