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

| 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.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org)  /  Do not send to the address below |
| first name lower case at ipal.net   /  spamtrap-2007-04-02-0827@ipal.net |
|------------------------------------/-------------------------------------|

[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 ~

--
Best regards, Roman

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.

--
Best regards, Roman

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

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.

--
Best regards, Roman

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