Dear:

I start to learn linux Boot and Kernel.

But I don not find which is the first process when my UBoot(Or RedBoot) ends and gives the contol rights to Kernel. Or the first file in kernel code.

my kernel version : 2.6.29.1.

thank you

There is no one "first file in kernel code" - it's architecture dependent. You could try ../arch/<your_arch>/boot/header.S and meander from there.
Trying to read the kernel from the beginning will be an interesting challenge. I'd suggest you try small bites first.
www.kernelnewbies.org might be a good place to visit.

Hi, jsjcaowei -

syg00 is correct - the answer to "what is the first process" or "what is the source code for the first process" is, unfortunately:

"It depends".

However, in general, the "first process" can safely be considered "init". Its source code code, "init/main.c", can be seen here:

http://lxr.linux.no/#linux+v2.6.31/init/main.c

Good, high-level descriptions of the boot process can be found here:

http://www.redhat.com/docs/manuals/l...n-process.html

http://tldp.org/LDP/sag/html/boot-process.html

A good, high-level overview of the kernel itself: particularly the relationship between the kernel, user-space Linux programs running under the kernel, and hardware resources managed by the kernel, can be found here:

http://www.ibm.com/developerworks/li...-linux-kernel/

'Hope that helps .. PSM

It basically goes like this:

1. When you boot the computer, a special program called a boot loader is brought into memory. It, in turn, loads a kernel image into memory (replacing itself), and hands over control of the system to it.
2. The kernel manually constructs all of the various lists and data-structures that it will use in the course of normal operations ... the memory heaps, the basic device-tables, and the process list. When built, the process list contains (usually) one entry: a very special process that by-definition is not allowed to die. That process is called init.
3. Once this initialization is finished, the kernel switches into virtual-memory mode and then activates the process-dispatcher ... which is now able to do its job because "a process" does exist: the process-list is not empty and it never will become so. From this point forward, init, and the various other processes that it spawns, "run the show."

As you may have guessed, this picture is somewhat over-simplified, but "for our purposes here, it will suffice."

1 members found this post helpful.

Dear syg00 and paulsm4:
thank you.