kernel启动控制台还不可用时发生cr…

kernel启动控制台还不可用时发生crash的调试方法

在调试linuxkernel时，如果crash发生在控制台还不可用时，那将没有任何信息能够被打印，那分析原因就变成了一摸黑。有以下方法有助于帮助分析：

1,early printk

在kernel配置选项中启用CONFIG_EARLY_PRINTK=y,那将可借助early_printk()函数打印信息，用early_printk在kernel启动的代码中加入一些打印点，可以帮助定位kernelboot到哪一位置。

early_printk的配置选项位于Kernel hacking,还必须开启了CONFIG_DEBUG_LL=y，才能启用early printk.

Kernel hacking ---->    [*] Kernel low-level debugging functions    [*]     Early printk

这一功能，需要你的arch实现底层的uart发送函数， 即include/mach/debug-macro.S中的addruart,senduart, waituart, busyuart等函数。

2,dump log_buf内存

printk函数打印的信息首先都是存在log_buf这块内存的，即使console还没enable，printk函数也一样可以被调用，因此当kernelcrash时，可以通过仿真器查看log_buf这段内存，它里面存的就是通过printk打印的信息，如果没有仿真器，也可以重启bootloader，在bootloader里通过dumpmem来查看。

log_buf这段内存的地址如何确定？通过System.map文件搜索log_buf，你就会找到log_buf的地址,如：

c0535bd8 b printk_bufc0535fd8 b printk_timec0535fdc b __log_bufc0539fdc b cpu_online_bitsc0539fe0 b cpu_active_bitsc0539fe4 b cpu_present_bitsc0539fe8 b cpu_possible_bitsc0539fec B sys_tzc053a000 b softirq_vec

这里我们看到log_buf的内存地址在c0535fdc，这是个虚拟地址，根据kernel地址映射规律，从MEM_PHY_START到MEM_PHY_END，都会一一映射到0xc0000000:(0xc0000000 +MEM_PHY_SIZE)，因此假设我们内存的物理地址起始是0x0，那么这里log_buf的实际物理地址为0x00535fdc。

在确认完log_buf的内存地址之后，就可以用仿真器也好，bootloader也好，去查看printk打印的内容了。