Where a processor runing Linux read his code after boot ?
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Where a processor runing Linux read his code after boot ?
Dear All,
First, please excuse my bad English, I am speaking normaly French, I will
do my best !
Second, a Happy New Year 2009 to you !!!
So, I work normaly with 8 bit µC like PIC 16F or 18F series and I am new to the embedded world of Linux.
Normaly, a 8 bit µC execute a code stored into an internal Flash, ROM or extrnal EEPROM with an internal programm counter.
In the Linux case, I have read that the boot loader ( like U - BOOT )
start the system with loading the Kernel into RAM and pass the control
to the O/S.
My question is as following => when the Kernel has been loaded into the RAM, where the processor take is code for runing ?
In others words, in a 8 bits µC, the only way for the processor to read his code is from the Flash ( or EPROM ) => the programm counter address
the Flash ( or EPROM ) and pass the code readed to the instructions decoder that drive the ALU and the system ( right ??? ).
But, with a processor runing Linux ( and also a PC ), what is the principle ( in the case of a PC, the hard disk drive is not always
readed by the processor => it seems that the processor run is code only
from the RAM ) ?
When booting on a multi-cpu system Linux boots on the first CPU just as if it is booting on a single CPU system. Once the kernel is established and set up it then goes into multi-cpu mode by scheduling threads on all of the available CPUs.
Once the kernel reaches this stage it is no longer sitting on a "master" CPU scheduling "slave" CPUs. All CPUs are equal.
Each processor is not running Linux per se. Each processor is running the thread it is currently assigned and executes application code and kernel code as the thread demands. Interrupts are processed by the CPU on which the interrupt causing event was generated. Thus the kernel interrupt code runs on which ever CPU has the latest interrupt. Likewise the scheduler runs on each CPU when that CPU reaches the next scheduling event.
So at any moment in time, after boot completes, you could have several CPUs running kernel code or one CPU running kernel code or no CPUs running kernel code.
The boot process starts the same as your microcontroller; executing code from non-volatile memory at a CPU-dependent address as the CPU comes out of reset. The exact nature of this is hardware platform dependent. This code is often called a BIOS. The BIOS determines from where to load further code. It could be from spinning media, a network share, or other non-volatile media. In any case, it would copy the code and data into memory, and pass execution to that code. In the case of Linux on a PC, this code would normally be a boot loader. The boot loader is a little smarter, and knows how to find an operating system; again, from any number of sources. The process is still the same, though. It copies the code and data into memory, and passes execution to it. Ultimately, the OS is executed, and it knows how to proceed, in part based on arguments given to it by the bootloader. If it is Linux, it has a filesystem containing drivers and essential files to proceed with it's startup. That filesystem is typically in a ramdisk, which the bootloader sets up for it (I think; someone correct me on that part). Eventually, it starts a process called 'init', which reads a script from the filesystem (typically called 'inittab'), and it uses the inittab file to perform a full boot, loading drivers and configuring higher level processes.
Make sense?
--- rod.
In resume, can I say that the processor as the ability to execute directly his programm code from RAM instead of the ROM
after the Kernel startup ( I suppose that the processor have special instructions and register for do that ) ?
In resume, can I say that the processor as the ability to execute directly his programm code from RAM instead of the ROM
after the Kernel startup ( I suppose that the processor have special instructions and register for do that ) ?
Jean - Pierre
No special instructions are required. The code and data are moved into RAM using methods appropriate for the source, and then a CALL, JUMP, or soft interrupt instruction invokes the specified code. This aspect would be very much CPU dependent. On a x86 family CPU, there may be IO instructions (different from memory read and write instructions) used to access such things as spinning media, network shares, flash drives, etc. These would be used simply to copy the code and data into RAM, at which point it becomes directly executable. This whole business is distinct from those microcontollers that have different address spaces for memory of different types, notably the Intel 8051 family, with it's plethora of addressing modes.
At an advanced phase of the boot sequence, the code may use sharable object libraries. The 'copy to RAM' phase may involve some adjustments by a linking loader, so that libraries' code is loaded, the public symbols are found and the the external references to these are resolved.
Ok, now that I've thought about the process, I have a question of my own. For a compressed kernel image, does the bootloader need to uncompress the kernel image, or does the kernel do that itself, as it begins execution? Inquiring minds wish to know...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.