kernel startup

Hello,



The bootloader knows where the kernel image resides in memory, because it is
the same location the bootloader copied it into. But there are different
approaches of loading the kernel from disk.

LILO writes some sectors into the MBR which point to sectors on the hard
disk, thus locating the map-file. This map-file then specifies the location
of the kernel and initrd's sectors on the hard disk. LILO can't read a file
system and because of that, you need to run /sbin/lilo everytime you changed
your kernel or initrd image.

GRUB uses the same approach, with stage2's sectors written into the MBR.
But, in contrast to LILO, this stage2 can already read a file system and
tends to be less often modified than the kernel image itself. This way you
only need to run grub-install when you change the location of stage2.

Why do all this stuff? Simply because you can't fit Grub, Lilo or some other
bootloader into the 446 spare bytes of MBR (leaving out the partition table)
and still have a file system support there.



That's another thing. Other architectures may have a ROM which eliminates
this problem. As an example, I take the Linux D-Box2 project (Neutrino):

The flash contains the bootloader BMon. It is able to read a file system
from flash and execute a program sitting there, which it does after asking
for netboot. This program (U-Boot) works as a secondary bootloader calling
the kernel with appropriate parameters. U-Boot doesn't need to know the
exact sectors in flash where the kernel resides, as there's no size limit
and thus there's space for a file system driver.



I hope this helps,

Regards,
Sebastian

[skip]



I see, this is PC (x86) architecture limitation, right?



But why do we need BMon, if U-boot knows about filesystem and can
directly invoke kernel from it?



What is the most common embedded architecture? I suppose seperate flash
ROM for bootloader, and another flash for kernel+FS. Does it make sense?

Thank you ~

other
table)

Exactly. It is an inherited limitation made in 1981.


eliminates
BMon is the bootloader of the original software and specially
write-protected. You only change one variable, to get the box into debug
mode so that it will run non-signed software. If people had to flash the
complete BMon, many boxes would be dead by now. Apart from that, BMon
initializes some hardware which would need more reverse engineering to do by
U-Boot. On the other hand, BMon can't run the kernel directly, because it
isn't a linux loader.



I agree with you, but don't know for sure. I think here are people knowing
much more than I do.

Regards,
Sebastian

May be you can recommend me some simple open-source bootloader for inspection and
getting basic principles? It's better if it would support ARM and MIPS,
cause I'm studying it.

U-boot from my point of view is too complex for newbie.

Hello,


inspection and

I'm sorry that I can't help you, but I have no idea about embedded linux
apart from general knowledge. The only time I worked with ARM was trying to
get Debian Linux working on qemu-system-arm...



I have never looked at the source code, because I don't know anything about
C - only a bit about x86 assembly, VBasic and Delphi...

Regards,
Sebastian

| I have a newbie's question. Usually bootloader ends up with launching
| kernel image. How does it know where kernel resides. Is it developer
| responsibility to hardcode the location address in bootloader source?

Some bootloaders keep their own information.  If it stored the kernel, it
knows where it is located.  Other bootloaders are scripted and you have to
know where it is (where you put it, most likely) and code that into the
automatic start script.


| Or it's architecture specific and there's no common mechanism?

There are a variety of mechanisms, not all available on all architectures
or platforms.  Some have more than one to choose from.  Your vendor docs
should cover this.

Do I understand right that bootloaders maintain physical addresses, not
virtual? So we can fix in source code the start address of kernel residing
in flash?


Can you recommend some simple bootloader for studying - not very complex
code, small size, simple functionality?

Appreciate your comments.

Hi, Roman.  I am a newbie too and am working on a project to boot
an ARM (Marvell PXA300) from a SanDisk H3 DiskOnChip.  The best
guide for me has been ...linux/Documentation/arm/Booting.  Also
of some value is "Embedded Linux System Design and Development"
by Raghavan.

In the ARM/PXA300 case, I have to load some "tag" structures
into the first 16 KB of RAM, the the command line into the next
16 KB and finally the kernel into RAM starting 32 KB from the
start of RAM. You have to set up certain registers with certain
values and then a "call" instruction actually transfers control
to the kernel


Yes, it is the programmer of the bootloader who determines this.
*BUT* he has to understand the schematic of the board enough to
figure out where RAM is located.


Worse, it is board specific.

Hope this helps,
Bob