J-P V-R

[Log in to get rid of this advertisement]

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 ) ?

Can you explain me the principle under that ?

Best regards,


Jean - Pierre

jailbait

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.

-----------------------
Steve Stites

Drakeo

D O S system use virtual ram this is called the swap file system hope this helps.
http://winmac.mvps.org/virtual.html

theNbomr

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.

J-P V-R

Thanks a lot for all of your explanations !

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

theNbomr

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

--- rod.

jailbait

The kernel uncompresses itself.

---------------------
Steve Stites

J-P V-R

Perfect, You answered my question => I am going to sleep in peace this night...


Thank you infinitely !



Jean - Pierre