Kernel Startup

Getting the kernel loaded into memory isn’t even half the fun of starting a Linux system. The boot loader’s job is to get the operating system from storage (flash, TFTP) into a place where it can be executed (RAM) and then go away. Most of the time, the kernel is stored as compressed data. To
uncompress the data, the kernel build process tacks a decompression code on the front of the kernel image, so the first output visible to you is like this:

Uncompressing
Linux..........................................................................
done,

This isn’t really the kernel running; it’s the decompression program for the kernel. These dots are
quickly followed by

booting the kernel.

That output means the kernel has finished going through the processor and board-specific initialization code and is now in the kernel_start or main entry point for the kernel. It’s important to know what happens in this area, even though you’ll probably never touch this code.

After decompression, the next code that runs is in the head.S used to build the kernel. For example, if you use a PowerPC 32-bit processor, you find this code at

arch/powerpc/kernel/head_32.S

The processor family is the one selected during the configuration of the kernel. If you’re building an ARM-based system, the entry-point file later links to a file containing the processor-specific initialization:

arch/arm/kernel/head.S

Both of these files do the same thing; they perform processor-specific configuration:
1. Initialize the MMU.
2. If the processor is multicore, get the second processor ready to run.
3. Get the kernel command line from the boot loader (before it’s overwritten), and copy the command line into memory where it can be safely passed to the kernel’s entry point.
4. Configure hooks for hardware debuggers.
5. Flush the processor’s cache.

Looking in the directory for the architecture reveals many more files than those mentioned. The kernel type you choose during the configuration step specifies what additional files are linked into the final initialization object code. No matter what initialization code happens to run, all initialization programs end by jumping to start_kernel.

Source of Information : Pro Linux Embedded Systems