kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: lroluk@gmail.com (luca ellero)
To: kernelnewbies@lists.kernelnewbies.org
Subject: How vmlinux is recognized?
Date: Thu, 12 May 2011 09:26:38 +0200	[thread overview]
Message-ID: <4DCB8BAE.9080500@gmail.com> (raw)
In-Reply-To: <BANLkTi=3LDkqN=TH7eryfVWgvkdLhCOsqQ@mail.gmail.com>

On 12/05/2011 8.21, Sudheer Divakaran wrote:
> On Thu, May 12, 2011 at 10:02 AM, Sudheer Divakaran
> <inbox1.sudheer@gmail.com>  wrote:
>> Hi Vikram,
>>
>> On Thu, May 12, 2011 at 9:02 AM, Vikram Narayanan<vikram186@gmail.com>  wrote:
>>> On Thu, May 12, 2011 at 1:51 AM, Mulyadi Santosa
>>> <mulyadi.santosa@gmail.com>  wrote:
>>>> On Thu, May 12, 2011 at 03:11, Vikram Narayanan<vikram186@gmail.com>  wrote:
>>>>> Yes. I agree. But how who converts the ELF binary to raw binary so
>>>>> that the processor understands. Or how is it actually done?
>>>>
>>>> OK I try my best to understand your question :)
>>>>
>>>> i think I got it...you probably guessed that vmlinux created first,
>>>> then vmlinuz... AFAIK, it's the other way around...or more precisely,
>>>> not both.
>>>
>>> I think you got it wrong. I will try to put my question more elaborately.
>>> 1) The system is on and BIOS code runs. It gives the control to the
>>> boot loader, say GRUB.
>>> 2) Grub picks up the kernel from the specific partition. (i.e a
>>> vmlinuz image), which denotes that it is compressed.
>>> 3) There are uncompression routines in the kernel itself, If I am not
>>> wrong. So the kernel uncompresses itself.
>>> 4) Now the uncompressed thing is the vmlinux image, right?
>>> 5) The vmlinux is in ELF format. Correct?
>>> 6) If the OS boots and if u try to run an ELF file, the loader knows
>>> how to load that in the RAM. (I mean it knows how to interpret the ELF
>>> format)
>>> 7) Coming back to the vmlinux image, Who takes care of the loading activity.?
>>> 8) Who recognizes that the image is ELF format and do the necessary
>>> things accordingly.?
>>>
>>> Hope I have my question clear now.
>>>
>>
>>
>>
>> If understand your question correctly, you believe that the
>> uncompressed kernel is in elf format. correct?. it is in binary
>> format, so elf interpretation is not required, #5 is wrong.
>>
>> You can see this by building the kernel using 'make V=1'  and note the
>> following line in the output,
>>
>> "arch/x86/boot/tools/build arch/x86/boot/setup.bin
>> arch/x86/boot/vmlinux.bin CURRENT>  arch/x86/boot/bzImage"
>>
>> means bzImage is made out of two binary files extracted from the elf images.
>
> One more info I want to clarify is,  vmlinux.bin mentioned in the
> above snippet contains the compressed binary image and some other
> routines. Just go through the 'make V=1' output, you can see that the
> build process is actually compressing binary file extracted from the
> vmlinux elf image, which is again combined with some object files,
> creates another elf and again extracts the binary and finally combined
> with the setup.bin to create the final bzImage. So, elf interpretation
>   doesn't happen on the uncompressed code.
>


Let's put some order here. The image that almost all bootloaders use is 
arch/x86/boot/bzImage which is made of a setup binary file (executable) 
joined with some compressed code (the real kernel) which is uncompressed 
in memory by the setup binary.

The big suggestion I can give is to check the hidden files which end 
with .cmd. There is one of these for every object created by the 
compilation process. For example there is a file called .bzImage.cmd 
which tell you how bzImage was made:

arch/x86/boot/tools/build -b arch/x86/boot/setup.bin 
arch/x86/boot/vmlinux.bin CURRENT > arch/x86/boot/bzImage

NOTE: I refer to a quite old kernel here, it's likely that the 
compilation process has changed somehow.

You can proceed now in reverse order to find how bzImage was made (if I 
understand correctly that is the one you are interested in).

Here is how is made on my kernel tree:

bzImage:
arch/x86/boot/tools/build -b arch/x86/boot/setup.bin 
arch/x86/boot/vmlinux.bin CURRENT > arch/x86/boot/bzImage

arch/x86/boot/vmlinux.bin:
objcopy  -O binary -R .note -R .comment -S 
arch/x86/boot/compressed/vmlinux arch/x86/boot/vmlinux.bin

arch/x86/boot/compressed/vmlinux:
ld -m elf_i386   -T arch/x86/boot/compressed/vmlinux_32.lds 
arch/x86/boot/compressed/head_32.o arch/x86/boot/compressed/misc.o 
arch/x86/boot/compressed/piggy.o -o arch/x86/boot/compressed/vmlinux

arch/x86/boot/compressed/piggy.o:
ld -m elf_i386   -r --format binary --oformat elf32-i386 -T 
arch/x86/boot/compressed/vmlinux.scr 
arch/x86/boot/compressed/vmlinux.bin.gz -o arch/x86/boot/compressed/piggy.o

arch/x86/boot/compressed/vmlinux.bin.gz:
gzip -f -9 < arch/x86/boot/compressed/vmlinux.bin > 
arch/x86/boot/compressed/vmlinux.bin.gz

arch/x86/boot/compressed/vmlinux.bin:
objcopy  -O binary -R .note -R .comment -S vmlinux 
arch/x86/boot/compressed/vmlinux.bin

vmlinux:
ld -m elf_i386 --build-id -o vmlinux -T arch/x86/kernel/vmlinux.lds 
arch/x86/kernel/head_32.o arch/x86/kernel/init_task.o  init/built-in.o 
--start-group  usr/built-in.o  arch/x86/kernel/built-in.o 
arch/x86/mm/built-in.o  arch/x86/mach-default/built-in.o 
arch/x86/crypto/built-in.o  arch/x86/vdso/built-in.o  kernel/built-in.o 
  mm/built-in.o  fs/built-in.o  ipc/built-in.o  security/built-in.o 
crypto/built-in.o  block/built-in.o  lib/lib.a  arch/x86/lib/lib.a 
lib/built-in.o  arch/x86/lib/built-in.o  drivers/built-in.o 
sound/built-in.o  arch/x86/math-emu/built-in.o  arch/x86/pci/built-in.o 
  arch/x86/power/built-in.o  net/built-in.o --end-group .tmp_kallsyms2.o

NOTE: there are 2 vmlinux (vmlinux and arch\x86\boot\compressed\vmlinux) 
and 2 vmlinux.bin (arch\x86\boot\compressed\vmlinux.bin and 
arch\x86\boot\vmlinux.bin) which are not the same


Hope this helps
Regards
Luca Ellero

  reply	other threads:[~2011-05-12  7:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 18:06 How vmlinux is recognized? Vikram Narayanan
2011-05-11 19:17 ` Dave Hylands
2011-05-11 19:31   ` Vikram Narayanan
2011-05-11 19:45     ` Mulyadi Santosa
2011-05-11 20:04       ` Vikram Narayanan
2011-05-11 20:09         ` Mulyadi Santosa
2011-05-11 20:11           ` Vikram Narayanan
2011-05-11 20:21             ` Mulyadi Santosa
2011-05-12  3:32               ` Vikram Narayanan
2011-05-12  4:32                 ` Sudheer Divakaran
2011-05-12  6:21                   ` Sudheer Divakaran
2011-05-12  7:26                     ` luca ellero [this message]
2011-05-12  8:17                 ` Mulyadi Santosa
2011-05-13  0:19                   ` Vikram Narayanan
2011-05-13  1:42                     ` Dave Hylands
2011-05-16  3:14                       ` Vikram Narayanan
2011-05-16  3:44                       ` Peter Teoh
2011-05-16 14:12                         ` Vikram Narayanan
2011-05-12  9:31                 ` अनुज
2011-05-11 20:33 ` Manohar Vanga
2011-05-12  3:34   ` Vikram Narayanan
2011-05-12 16:46   ` mindentropy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DCB8BAE.9080500@gmail.com \
    --to=lroluk@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).