All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.