I loved this reply.......can I annotate it with references to the linux kernel sources?<br><br><div class="gmail_quote">On Fri, May 13, 2011 at 9:42 AM, Dave Hylands <span dir="ltr">&lt;<a href="mailto:dhylands@gmail.com" target="_blank">dhylands@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vikram,<br>
<br>
...snip...<br>
<div>&gt; So when compiling the kernel, what is the purpose of the other<br>
&gt; files(mentioned below)<br>
&gt; linux-2.6/vmlinux - ELF executable, not stripped<br>
&gt; linux-2.6/arch/x86/boot/vmlinux.bin - Raw binary (Guess this is the<br>
&gt; one which is inside the bzImage)<br>
&gt; linux-2.6/arch/x86/boot/compressed/vmlinux.bin - ELF executable, stripped<br>
&gt; linux-2.6/arch/x86/boot/compressed/vmlinux - ELF executable, not stripped<br>
<br>
</div>Take luca&#39;s email and start at the bottom working towards the top.<br>
<br>
linux-2.6/vmlinux is the output of the linker. As such, it is an ELF file.<br>
A binary is then extracted from this to create<br>
<div>arch/x86/boot/compressed/vmlinux.bin<br></div></blockquote><div><br></div><div>yes:</div><div><br></div><div>See ./arch/x86/boot/Makefile</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>
</div>This binary is then compressed to produce<br>
arch/x86/boot/compressed/vmlinux.bin.gz<br></blockquote><div><br></div><div>See ./arch/x86/boot/compressed/Makefile</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



This gzipped binary is then converted into an object file (which just<br>
contains the gzipped data) but now we&#39;re back to having an ELF file<br></blockquote><div><br></div><div>./arch/x86/boot/compressed/mkpiggy.c is compiled into a commandline binary - mkpiggy which will generate the piggy.o.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
called arch/x86/boot/compressed/piggy.o<br>
The linker then compiles a decompressor (misc.o) and piggy.o together<br></blockquote><div><br></div><div>Yes, the routine is called &quot;decompress_kernel&quot;, residing inside ./arch/x86/boot/compressed/misc.c.   And this routine is called from ./arch/x86/boot/compressed/head_32.S (or head_64.S) and at runtime, the gzipped data is decompressed and immediately jumped into (perhaps after some relocation if needed):</div>


<div><br></div><div><div>/*</div><div> * Do the decompression, and jump to the new kernel..</div><div> */</div><div>        leal    z_extract_offset_negative(%ebx), %ebp</div><div>                                /* push arguments for decompress_kernel: */</div>


<div>        pushl   %ebp            /* output address */</div><div>        pushl   $z_input_len    /* input_len */</div><div>        leal    input_data(%ebx), %eax</div><div>        pushl   %eax            /* input_data */</div>


<div>        leal    boot_heap(%ebx), %eax</div><div>        pushl   %eax            /* heap area */</div><div>        pushl   %esi            /* real mode pointer */</div><div>        call    decompress_kernel</div><div>


        addl    $20, %esp</div><div><br></div><div><br></div></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
to produce arch/x86/boot/compressed/vmlinux (an ELF file).<br>
objcopy is used again to convert this ELF into a binary:<br>
arch/x86/boot/compressed/vmlinux arch/x86/boot/vmlinux.bin<br>
Finally, the binary is compressed to produce bzImage.<br></blockquote><div><br></div><div>Inside arch/x86/boot/Makefile:</div><div><br></div><div>Creating the vmlinux.bin from vmlinux via objcopy (note that this operation will throw all relocation information):</div>

<div><br></div><div><div>$(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE</div><div>        $(call if_changed,objcopy)</div></div><div><br></div><div>And then packing together linearly to form the &quot;bzImage&quot; (output from make):</div>

<div><br></div><div><div>make -f scripts/Makefile.build obj=arch/x86/boot arch/x86/boot/bzImage</div><div><br></div><div>make -f scripts/Makefile.build obj=arch/x86/boot/compressed arch/x86/boot/compressed/vmlinux</div><div>
<br></div><div>arch/x86/boot/tools/build arch/x86/boot/setup.bin arch/x86/boot/vmlinux.bin CURRENT &gt; arch/x86/boot/bzImage</div></div><div><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
So what you get is a compressed binary which contains a decompressor<br>
and another compressed binary, this inner compressed binary being the<br>
kernel.<br>
<br>
GRUB loads bzImage into memory and decompresses it and then executes<br>
the resulting binary.<br></blockquote><div><br></div><div>To be more precise, grub will load bzImage and jump into the startup_32 function located in arch/x86/boot/compressed/head_32.S at the following fixed address (from source code):</div>
<div><br></div><div><div>/*</div><div> *  head.S contains the 32-bit startup code.</div><div> *</div><div> * NOTE!!! Startup happens at absolute address 0x00001000, which is also where</div><div> * the page directory will exist. The startup code will be overwritten by</div>
<div> * the page directory. [According to comments etc elsewhere on a compressed</div><div> * kernel it will end up at 0x1000 + 1Mb I hope so as I assume this. - AC]</div><div> *</div><div> * Page 0 is deliberately kept safe, since System Management Mode code in</div>
<div> * laptops may need to access the BIOS data stored there.  This is also</div><div> * useful for future device drivers that either access the BIOS via VM86</div><div> * mode.</div><div> */</div></div><div><br></div><div>
More info:</div><div><br></div><div><a href="http://books.google.com/books?id=e8BbHxVhzFAC&amp;pg=PA1224&amp;lpg=PA1224&amp;dq=grub+head_32.S&amp;source=bl&amp;ots=0MSdKwBoM6&amp;sig=2RyEpprl25zueiqi332TQHLIj0E&amp;hl=en&amp;ei=y5vQTY7eBNDNrQeI3bTCCg&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=3&amp;ved=0CCkQ6AEwAg#v=onepage&amp;q=grub%20head_32.S&amp;f=false">http://books.google.com/books?id=e8BbHxVhzFAC&amp;pg=PA1224&amp;lpg=PA1224&amp;dq=grub+head_32.S&amp;source=bl&amp;ots=0MSdKwBoM6&amp;sig=2RyEpprl25zueiqi332TQHLIj0E&amp;hl=en&amp;ei=y5vQTY7eBNDNrQeI3bTCCg&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=3&amp;ved=0CCkQ6AEwAg#v=onepage&amp;q=grub%20head_32.S&amp;f=false</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This binary starts with a decompressor which then decompresses the<br>
kernel, and executes the resulting binary.<br>
This binary may relocate itself (probably depends on the architecture)<br>
to a different spot in memory, and then runs.<br>
The kernel is now running.<br>
<div><br>
--<br>
Dave Hylands<br>
Shuswap, BC, Canada<br>
<a href="http://www.davehylands.com" target="_blank">http://www.davehylands.com</a><br>
<br>
_______________________________________________<br>
</div><div><div></div><div>K</div></div></blockquote></div><br>-- <br>Regards,<br>Peter Teoh<br>