c - 如何优化 U-boot 到内核的切换代码？

Question

平台:Xilinx Zynq SoC 上的 ARM Cortex A9 上的 Linux。

我问了一个问题:Why is kernel boot starting too late

基本上，我试图理解并尽量减少这两个事件之间的延迟:

[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

第一行告诉我们现在控制权交给了内核，而第二行告诉我们控制权现在和内核在一起并由CPU执行。

这种从 u-boot 到内核的切换对我们的应用程序来说花费了太多时间。

为了理解这两个事件之间发生了什么，我在以下位置插入了 printf 语句:

1- bootm.c

我将以下行放在函数 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

我将这样的语句放在 start_kernel 函数中:

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

然后我编译了 u-boot 和内核，新的日志消息有以下几行:

[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] I am the first statement in start_kernel in main.c 
[Sat Apr 12 19:33:51.298 2014] Booting Linux on physical CPU 0x0

(事实上，我在很多地方放置了 printf 语句，但所有这些语句要么在“正在启动内核...”之上，要么在“在物理 CPU 0x0 上引导 Linux”之下，所以我在本次讨论中忽略了它。我还使用了ftrace 查看热点，但它不报告 u-boot 功能)。

我观察到“below kernel_entry in boot_jump_linux in bootm.c”从未在日志消息的任何地方打印。这说明在function kernel_entry(0, machid, r2);之后控制不会返回；被调用是因为 linux 现在拥有控制权并且正在执行。

所以我的目标是知道在这两个事件期间正在执行哪个函数。

现在要了解发生了什么(即使在插入我的 printf/printk 消息后还不清楚)我问了以下问题:

1- In u-boot, kernel_entry points to which function?

2- Trying to understand the usage of function pointer

根据那里的答案，我怀疑我的热点(即花费大量时间的代码)位于以下文件之一中:

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

我的问题:

1- 我的理解是否正确，我应该关注上述文件？

2- 调用kernel_entry(0, machid, r2); 后，控制转到上面的哪一行代码？

我怀疑文件 https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm/boot/compressed/head.S 对我没有用，因为这是解压所必需的，但我的内核已经解压了，因为在 u-boot 日志中很早就可以看到以下行:

[Sat Apr 12 19:33:50.596 2014]    Uncompressing Kernel Image ... OK

完整的日志是here .

有人可以在这方面启发我吗？

非常感谢!!

Answer 1

My aim is to have the handoff as fast as possible.
Do you think using early printk I can boot faster as the handoff will be early?

您的问题和计算“快速”或“延迟”的方法基于有缺陷的数据。

您认为的 0.5 秒“延迟”实际上是 U-Boot “正在启动内核...” 实时 ，而内核缓冲区和推迟输出它的“Booting Linux”直到系统和控制台被初始化。这是将苹果与橙子进行比较。
至少，您必须通过启用early printk 让内核在实时(就像 U-Boot)中输出。然后您的时间戳将更好地指示实际耗时。

摘自 chapter 18 of the Linux Kernel Map (重点是我加的):

A chink in the armor of printk()'s robustness does exist. It is unusable before a certain point in the kernel boot process, prior to console initialization. Indeed, if the console is not initialized, where is the output supposed to go?

This is normally not an issue, unless you are debugging issues very early in the boot process (for example, in setup_arch(), which performs architecture-specific initialization). Such debugging is a challenge to begin with, and the absence of any sort of print method only compounds the problem.

There is some hope, but not a lot. Hardcore architecture hackers use the hardware that does work (say, a serial port) to communicate with the outside world. Trust me this is not fun for most people. Some supported architectures do implement a sane solution, however and others (i386 included) have patches available that also save the day.

The solution is a printk() variant that can output to the console very early in the boot process: early_printk(). The behavior is the same as printk(), only the name and its capability to work earlier are changed. This is not a portable solution, however, because not all supported architectures have such a method implemented. It might become your best friend, though, if it does.

参见 this answer到相同的问题(你的双胞胎？)以获取有关启用 early printk 的详细信息。

所以不，使用早期 printk 不会改善“切换”或整体启动时间。
但它应该有助于防止您寻找幻影阻塞。