Discussion:
How to boot with bzImage ?
matrix reloaded
2004-09-17 09:00:52 UTC
Permalink
Hi,
I would like to know about the memory layout of kernel when it boots with
bzImage [i.e Big kernel]. I understand the following things :-

1. Boot loader code [512 bytes] is loaded at 07c0:0000 address [i.e. 0x7c00
Physical address] using int 0x19 by the BIOS after POST thing.
2. Boot loader code [here I assume that it's Linux Kernel Legacy bootloader and not
any other LILO or Grub] then moves itself to location 0x90000.
3. Then it loades the setup code at 0x90200 location.
4. After this, bool loader loades compressed kernel image [zImage] at address
0x10000 and then jumps to address 0x90200 [i.e at setup code].
5. Setup code then moves kernel from 0x10000 to 0x1000 location overwriting
firmware code previously present there. Now setup code changes real mode to
protected mode and transfers control to 0x1000.
6. Now, you have compressed kernel Image at location 0x1000 whose intial code is
head.S code. This code uncompresses the kernel at location 0x100000 and starts
executing from there.

FYI the above explaination is about zImage whose size can't be more than 512 KB.
Can anyone tell me what happens in case of bzImage.

What I understand is bzImage can't be loaded at location 0x10000 by the bootloader
code [Explained in step 4], as we have limited space available only from 0x10000 to
0x90000 [i.e 512 KB], but generally the size of bzImage is > 512 KB. So it can't be
loaded there completely.
Moreover, bootloader can't load kernel at high memory [0x100000] because CPU is
running in real mode.

Is bzImage partially loaded at 0x10000 and then this partial bzImage is moved to
0x100000 instead of 0x1000 by setup code [after changing to real mode] ? If it is
so, then there should be some code in head.S or misc.c [Which are the heads of
bzImage] to load the rest portion of the bzImage, but I don't see this.

Anyone please clear this doubt related to booting with bzImage.

Thanks in advance.
Sumit Sharma.
manish regmi
2004-09-20 07:16:36 UTC
Permalink
Post by matrix reloaded
Hi,
I would like to know about the memory layout of kernel when it boots with
bzImage [i.e Big kernel]. I understand the following things :-
1. Boot loader code [512 bytes] is loaded at 07c0:0000 address [i.e. 0x7c00
Physical address] using int 0x19 by the BIOS after POST thing.
2. Boot loader code [here I assume that it's Linux Kernel Legacy bootloader
and not
any other LILO or Grub] then moves itself to location 0x90000.
3. Then it loades the setup code at 0x90200 location.
4. After this, bool loader loades compressed kernel image [zImage] at
address
0x10000 and then jumps to address 0x90200 [i.e at setup code].
5. Setup code then moves kernel from 0x10000 to 0x1000 location overwriting
firmware code previously present there. Now setup code changes real mode to
protected mode and transfers control to 0x1000.
6. Now, you have compressed kernel Image at location 0x1000 whose intial
code is
head.S code. This code uncompresses the kernel at location 0x100000 and
starts
executing from there.
FYI the above explaination is about zImage whose size can't be more than
512 KB.
Can anyone tell me what happens in case of bzImage.
What I understand is bzImage can't be loaded at location 0x10000 by the
bootloader
code [Explained in step 4], as we have limited space available only from
0x10000 to
0x90000 [i.e 512 KB], but generally the size of bzImage is > 512 KB. So it
can't be
loaded there completely.
Moreover, bootloader can't load kernel at high memory [0x100000] because
CPU is
running in real mode.
Is bzImage partially loaded at 0x10000 and then this partial bzImage is
moved to
0x100000 instead of 0x1000 by setup code [after changing to real mode] ? If
it is
so, then there should be some code in head.S or misc.c [Which are the heads
of
bzImage] to load the rest portion of the bzImage, but I don't see this.
Anyone please clear this doubt related to booting with bzImage.
Thanks in advance.
Sumit Sharma.
Hi,
While loading bzImage the kernel does memory transfer from low memory to
high memory (64K chunks) .
see setup.S line 836

also see 2.4 kernel internals
http://www.faqs.org/docs/kernel_2_4/lki-1.html#ss1.2
Post by matrix reloaded
Moreover, bootloader can't load kernel at high memory [0x100000] because
CPU is
running in real mode.
NOTE: In real mode we can access the 4G address space . It in
known as Unreal Mode.
and grub runs in Protected mode. It contains code to switch itself to
protected mode and switch back when reqd.

regards manish

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
matrix reloaded
2004-09-20 08:55:43 UTC
Permalink
Hi Maneesh,
Thanks for making the things more clear. Now I got the point that in case of
bzImage kernel is loaded at 0x1000 only, but as soon as you have loaded 64k of it,
it will be moved to high mem [i.e. 0x100000]... tell me if I am wrong. So bzImage is
never placed at physical location 0x1000. It means that now uncompression
routines are loaded at 0x100000 [instead of 0x10000 with zImage] and then head.S
and misc.c [which have been moved to 0x100000] will then uncompress the kernel
at 0x100000 again ?? Please clear these points also...

TIA.
Sumit Sharma.
Post by matrix reloaded
Hi,
I would like to know about the memory layout of kernel when it boots with
bzImage [i.e Big kernel]. I understand the following things :-
1. Boot loader code [512 bytes] is loaded at 07c0:0000 address [i.e. 0x7c00
Physical address] using int 0x19 by the BIOS after POST thing.
2. Boot loader code [here I assume that it's Linux Kernel Legacy bootloader and
not
Post by matrix reloaded
any other LILO or Grub] then moves itself to location 0x90000.
3. Then it loades the setup code at 0x90200 location.
4. After this, bool loader loades compressed kernel image [zImage] at address
0x10000 and then jumps to address 0x90200 [i.e at setup code].
5. Setup code then moves kernel from 0x10000 to 0x1000 location overwriting
firmware code previously present there. Now setup code changes real mode to
protected mode and transfers control to 0x1000.
6. Now, you have compressed kernel Image at location 0x1000 whose intial code
is
Post by matrix reloaded
head.S code. This code uncompresses the kernel at location 0x100000 and
starts
Post by matrix reloaded
executing from there.
FYI the above explaination is about zImage whose size can't be more than 512
KB.
Post by matrix reloaded
Can anyone tell me what happens in case of bzImage.
What I understand is bzImage can't be loaded at location 0x10000 by the
bootloader
Post by matrix reloaded
code [Explained in step 4], as we have limited space available only from
0x10000 to
Post by matrix reloaded
0x90000 [i.e 512 KB], but generally the size of bzImage is > 512 KB. So it can't
be
Post by matrix reloaded
loaded there completely.
Moreover, bootloader can't load kernel at high memory [0x100000] because CPU
is
Post by matrix reloaded
running in real mode.
Is bzImage partially loaded at 0x10000 and then this partial bzImage is moved to
0x100000 instead of 0x1000 by setup code [after changing to real mode] ? If it is
so, then there should be some code in head.S or misc.c [Which are the heads of
bzImage] to load the rest portion of the bzImage, but I don't see this.
Anyone please clear this doubt related to booting with bzImage.
Thanks in advance.
Sumit Sharma.
Hi,
While loading bzImage the kernel does memory transfer from low memory to high
memory (64K chunks) .
see setup.S line 836
also see 2.4 kernel internals
http://www.faqs.org/docs/kernel_2_4/lki-1.html#ss1.2
Post by matrix reloaded
Moreover, bootloader can't load kernel at high memory [0x100000] because CPU
is
Post by matrix reloaded
running in real mode.
NOTE: In real mode we can access the 4G address space . It in known
as Unreal Mode.
and grub runs in Protected mode. It contains code to switch itself to protected
mode and switch back when reqd.
regards manish
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
manish regmi
2004-09-22 07:16:16 UTC
Permalink
Hi Manish,
Thanks for making the things more clear. Now I got the point that in case
of
bzImage kernel is loaded at 0x1000 only, but as soon as you have loaded 64k
of it,
it will be moved to high mem [i.e. 0x100000]... tell me if I am wrong. So
bzImage is
never placed at physical location 0x1000. It means that now uncompression
routines are loaded at 0x100000 [instead of 0x10000 with zImage] and then
head.S
and misc.c [which have been moved to 0x100000] will then uncompress the
kernel
at 0x100000 again ?? Please clear these points also...
TIA.
Sumit Sharma.
Yes,
In bzImage, the image is loaded at 100000 using (int 15).
Then, the kernel jumps at 100000 using jmpi

see setup.S line 803

Now, the code executed there is decompression routine. i.e.
compressed/head.S

There are codes to decompress the bzImage to 100000.

regards manish

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
matrix reloaded
2004-09-22 08:04:12 UTC
Permalink
ok fine. But if kernel is loaded at 0x100000 and then deompresstion routine
[head.S] decompresses the kernel at 0x100000 only, there is a possibility of
overwriting the decompression routine's code by that of the decompressed kernel,
as both are happening at the same place...so what about that ?

Thanks.
Sumit Sharma.
Post by manish regmi
Hi Manish,
Thanks for making the things more clear. Now I got the point that in case of
bzImage kernel is loaded at 0x1000 only, but as soon as you have loaded 64k of
it,
Post by manish regmi
it will be moved to high mem [i.e. 0x100000]... tell me if I am wrong. So bzImage
is
Post by manish regmi
never placed at physical location 0x1000. It means that now uncompression
routines are loaded at 0x100000 [instead of 0x10000 with zImage] and then
head.S
Post by manish regmi
and misc.c [which have been moved to 0x100000] will then uncompress the
kernel
Post by manish regmi
at 0x100000 again ?? Please clear these points also...
TIA.
Sumit Sharma.
Yes,
In bzImage, the image is loaded at 100000 using (int 15).
Then, the kernel jumps at 100000 using jmpi
see setup.S line 803
Now, the code executed there is decompression routine. i.e. compressed/head.S
There are codes to decompress the bzImage to 100000.
regards manish
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
matrix reloaded
2004-09-22 09:11:10 UTC
Permalink
basically, with zImage bootsect.S code moves itself from 0x7c00 location to
0x90000 location and then loads setup.S code at 0x90200 location. After that
bootsector code only loads kernel image [zImage] at 0x10000 location and then it
transfers the control to setup.S code. setup.S code then moves zImage from
0x10000 to 0x1000 [where firmware code was earlier] and transfers the control to
zImage [at 0x1000] after changing to protected mode. In case of bzImage,
bootsector code loads setup.S at the same location [0x90200] and then loads
bzImage also at the same location [0x10000], but simultaneously using
bootsect_kludge function this bzImage is moved to 0x100000. After transferring the
whole bzImage to 0x100000, control is transferred to setup.S as usual and then
setup.S changes to protected mode and transfers the control to bzImage at
0x100000. bzImage's head.S then decompresses the kernel at 0x100000 only.

I think that the above explaination is correct barring one thing that who takes care of
the fact that decompression routine itself is not overwritten by the uncompressed
kernel.

One more question here is, if you see at the starting of bootsect.S, you'll find the
following comments :-

NOTE! currently system is at most (8*65536-4096) bytes long. This should
be no problem, even in the future. I want to keep it simple. This 508 kB
kernel size should be enough, especially as this doesn't contain the
buffer cache as in minix (and especially now that the kernel is
compressed :-)

Here, I don't understand why we are taking (8*65536 - 4096) as the size of current
kernel. Because if you see the boottime memory layout as mentioned in
"Documentation/i386/boot.txt", you will find that actually it should be
(9*65536 - 4096), because our bootsect.S starts from 0x90000 and the memory
area before 0x1000 is reserved for MBR, BIOS and similar stuff. So actually, we
have memory available from 0x1000 to 0x90000, which concludes to
[9*65536 - 4096] bytes for system size.

Anyone please suggest me why the factor of 8 is there instead of 9 and the details
of bzImage more deeply.

TAI.
Sumit Sharma,
IBM, Bangalore.
Post by matrix reloaded
ok fine. But if kernel is loaded at 0x100000 and then deompresstion routine
[head.S] decompresses the kernel at 0x100000 only, there is a possibility of
overwriting the decompression routine's code by that of the decompressed
kernel,
Post by matrix reloaded
as both are happening at the same place...so what about that ?
Thanks.
Sumit Sharma.
exactly,
But you can see in head.s, there is code for moving something to 1000 for
bzImage.
frankly i did not understand how. so i called it magic code..
regards manish
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Continue reading on narkive:
Loading...