Within my links on right side now there is the pdf document that describe the entire Linux boot process adapted for arm i.MX31: after the bootloader work through the execution of /sbin/init!
Taste it! Bye!
venerdì 3 aprile 2009
giovedì 2 aprile 2009
Very deep focus on ARM Boot process
Here Peter Pearse make a very deep and up-to-date focus analysis of SMP ARM Boot process:
http://www.linux-arm.org/LinuxBootLoader/SMPBoot
Thanks a lot to him :)
With little adjusting Voilà! the single core ARM Boot process!
The context where I have to work and without I will not understand nothing :p
http://www.linux-arm.org/LinuxBootLoader/SMPBoot
Thanks a lot to him :)
With little adjusting Voilà! the single core ARM Boot process!
The context where I have to work and without I will not understand nothing :p
What Run First
Form Arm-Linux Mailing list, posted by Russell King
http://lists.arm.linux.org.uk/lurker/message/20011005.154003.5d698445.html
What runs first depends on what type of kernel you start running.
Compressed kernel (aka zImage):
This is where we join the uncompressed kernel startup.
http://lists.arm.linux.org.uk/lurker/message/20011005.154003.5d698445.html
What runs first depends on what type of kernel you start running.
Compressed kernel (aka zImage):
- the startup code in arch/arm/boot/compressed/head.S (start label)
(and maybe some other architecture specific code in other head-*.S files in that directory). - Decompressor proper (via decompress_kernel) in arch/arm/boot/compressed/misc.c which gunzips the kernel.
- We then relocate the kernel if required, and call it.
This is where we join the uncompressed kernel startup.
- arch/arm/kernel/head-armv.S (Edit head.S and head-*.S ) describes this, and includes such things as:
page table initialization and processor cache initialization
(via support stuff in arch/arm/mm/proc-*.S). - We then proceed to start_kernel in init/main.c, and everything follows from that point on.
- The only other thing to note is that the various drivers are initialized via a table built by the linker from the __initcall() and module_init() statements scattered throughout the kernel source. The code which calls them can be found in init/main.c: do_initcalls().
Etichette:
arm,
decompress,
head-armv.S,
head.S,
Image,
linux,
main.c,
relocate,
start_kernel,
startup,
zImage
mercoledì 1 aprile 2009
All begin by main.c
All the time I spent since now was for looking to understand the real order in booting/init procedure (not counting time spent for diffs over different kernel source and bsp's)
Here I found an effective utile documentation: http://www.linux-arm.org/LinuxKernel/LinuxNewPlatformPort
In Kernel Boot section we can find that the function init/main.c:start_kernel() starts the kernel over all architecture, and give the real order of the initialization sequence.
Sorry it it was obvious I am a sort of Davide that fight with Golia in this work :)
Anyway every tutorial/docs I've found is related to old kernel version..
Here I found an effective utile documentation: http://www.linux-arm.org/LinuxKernel/LinuxNewPlatformPort
In Kernel Boot section we can find that the function init/main.c:start_kernel() starts the kernel over all architecture, and give the real order of the initialization sequence.
Sorry it it was obvious I am a sort of Davide that fight with Golia in this work :)
Anyway every tutorial/docs I've found is related to old kernel version..
C Preprocessor and Macro, symbol ##
It is easy to see in kernel sources within macros the symbol ## but what it mean??
It is used to Concatenate "token" of text source: when the macro is expanded first the preprocessor substitute the variables name with their values and then concatenate tokens divided by ##
Reference: http://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
It is used to Concatenate "token" of text source: when the macro is expanded first the preprocessor substitute the variables name with their values and then concatenate tokens divided by ##
#define init_func(prefix_name, arg) prefix_name##_init(arg)so calling:
init_func(armadillo, null)expands in:
armadillo_init(null)fox!
Reference: http://gcc.gnu.org/onlinedocs/cpp/Concatenation.html#Concatenation
Fermo per un pò.. ma riprendo!
Dopo gli eventi della settimana scorsa ho ripreso il lavoro..
Ora mi stò concentrando sulla creazione del supporto ad armadillo 500 per la versione corrente del kernel: 2.6.29 Questo perché:
Ora mi stò concentrando sulla creazione del supporto ad armadillo 500 per la versione corrente del kernel: 2.6.29 Questo perché:
- Atmark con la loro bsp si sono strafregati dello sviluppo mailine del kernel..
- -> La bsp risultate è difficile da portare su kernel recenti.
- Se devo fare lo sforzo di rivedere l'intera bsp, cosa mi trattiene da farlo fatto bene in modo che possa convivere con tutte le altre??
- Per Android è già presente la versione del kernel 2.6.29..! skeggie! :)
Iscriviti a:
Post (Atom)
