c - How to optimize U-boot to kernel hand-off code? -

c - How to optimize U-boot to kernel hand-off code? -

platform: linux on arm cortex a9 on xilinx zynq soc.

i asked question : why kernel boot starting late

basically trying understand , minimize delay between these 2 events:

[sat apr 12 19:33:50.692 2014] starting kernel ... [sat apr 12 19:33:50.692 2014] [sat apr 12 19:33:51.298 2014] booting linux on physical cpu 0x0

the first line tells command beingness given kernel now, while thesecond line tells command kernel , beingness executed cpu.

this hand-off u-boot kernel taking much time our application.

to understand going on between these 2 events inserted printf statements in:

1- bootm.c

i set next line @ end of function static void boot_jump_linux(bootm_headers_t *images, int flag)

} if (!fake) {printf("above kernel_entry in boot_jump_linux in bootm.c\n"); kernel_entry(0, machid, r2); printf("below kernel_entry boot_jump_linux in bootm.c\n"); } }

2- main.c

i set statement in start_kernel function:

asmlinkage void __init start_kernel(void) { printk("i first statement in start_kernel in main.c" ); char * command_line; extern const struct kernel_param __start___param[], __stop___param[];

then compiled u-boot , kernel , new log message has next lines:

[sat apr 12 19:33:50.692 2014] starting kernel ... [sat apr 12 19:33:50.692 2014] above kernel_entry in boot_jump_linux in bootm.c [sat apr 12 19:33:51.298 2014] first statement in start_kernel in main.c [sat apr 12 19:33:51.298 2014] booting linux on physical cpu 0x0

(in fact set printf statements @ many places thsoe comming either above "starting kernel..." or below "booting linux on physical cpu 0x0", ignoring in discussion. used ftrace see hotspot, not reporting u-boot functions).

i observed "below kernel_entry in boot_jump_linux in bootm.c" never printed anywhere in log message. shows command not homecoming after function kernel_entry(0, machid, r2); called because linux has command , beingness executed.

so aim know function beingness executed during these 2 events.

now understand happening (which not yet clear after inserting printf/printk messages) asked next questions:

1- in u-boot, kernel_entry points function?

2- trying understand usage of function pointer

based on answers there suspecting hot spot i.e code taking much time located in 1 of next files:

1- https://github.com/xilinx/linux-xlnx/blob/master/arch/arm/kernel/head.s

2- https://github.com/xilinx/linux-xlnx/blob/master/arch/arm/kernel/head-common.s

3- https://github.com/xilinx/linux-xlnx/blob/master/arch/arm/boot/compressed/head.s

my questions:

1- understanding right should focus on above files ?

2- after phone call kernel_entry(0, machid, r2); made, command goes of above code , line?

i suspecting file https://github.com/xilinx/linux-xlnx/blob/master/arch/arm/boot/compressed/head.s of no utilize me since required decompression, kernel decompressed, since next line can seen much in u-boot log:

[sat apr 12 19:33:50.596 2014] uncompressing kernel image ... ok

the total log here.

can enlight me in regard ?

many in advance!!

my aim have handoff fast possible. think using printk can boot faster handoff early?

your question , method of calculating "fast" or "delayed" based on flawed data.

what think 0.5 sec "delay" u-boot outputting "starting kernel ..." in real time, while kernel buffers , postpones outputting "booting linux" until scheme , console initialized. that's comparing apples oranges. @ to the lowest degree have kernel output in realtime (just u-boot) enabling early printk. timestamps improve indicate actual elapsed time.

an excerpt chapter 18 of linux kernel map(emphasis added me):

a chink in armor of printk()'s robustness exist. it unusable before point in kernel boot process, prior console initialization. indeed, if console not initialized, output supposed go?

this not issue, unless debugging issues in boot process (for example, in setup_arch(), performs architecture-specific initialization). such debugging challenge begin with, , absence of sort of print method compounds problem.

there hope, not lot. hardcore architecture hackers utilize hardware work (say, serial port) communicate outside world. trust me not fun people. supported architectures implement sane solution, , others (i386 included) have patches available save day.

the solution printk() variant can output console in boot process: early_printk(). behavior same printk(), name , capability work before changed. not portable solution, however, because not supported architectures have such method implemented. might become best friend, though, if does.

see this answer identical question (by twin?) details on enabling early printk.

so no, using early printk not improve "handoff" or overall boot time. should help prevent looking phantom blockages.

c linux linux-kernel