嵌入式Linux之Kernel（裁减移植）启动调试、打印技术 printascii(补充)、内核调试

本文来自: http://blog.csdn.net/fqheda/archive/2009/06/01/4230999.aspx


嵌入式系统搭建过程中，对于系统平台搭建工程师在完成Bootloader
的调试之后就进入Kernel
裁减移植的阶段，其中最重要的一步是Kernel

启动的调试，在调试Kernel
过程中通常遇到最常见的问题是启动异常:

Uncompressing Linux............................................................

...........................
done, booting the kernel.(

挂死在此处)




注意：这里是arch/arm/boot/compressed/head.S的解压过程，调用了decompress_kernel()(同目录下的misc.c)->include/asm-arm/arch-xxx/uncompress.h的putc()实现。这是在uboot中初始化的，用的是物理地址，因为此时内核还没有起来。

而printascii则是调用了汇编。printascii()位于arch/arm/kernel/debug.S，他需要调用虚拟地址，此虚拟地址通过machine_start提供，而相关的宏在include/asm/arch-xxx/debug-macro.S实现，这下明白了。

10-05-14添加：debug.s里面需要判断一下当前是否打开了mmu，然后指定uart的基址。在解压阶段的head.s，mmu是1:1映射，目的是加快速度。到了内核的head.s，就是真正的mmu了，此时就是虚拟地址了。

导致驱动异常（启动挂死）的原因有很多，如基于EVM
板的
硬件做了修改（如更改了FLASH
空间大小、地址和型号，更改了SDRAM
、DDR SDRAM
空间大小、地址和型号，更改了晶振频率等），板卡ID号不支持等。那么如何进行调试那，其实有两种调试技术比较有效。

Kernel
启动调试技术-

使用printascii()
函数跟踪start_kernel()
有没运行
，在booting the kernel
之后Kernel
最先执行的是start_kernel()
函数，确认start_kernel()
有否执行就是在其开始代码段添加printascii("start_kernel
…")
，如果串口没有打印出start_kernel
…，说明start_kernel()
没有运行，那么可能的原因有Bootloader
配置的启动参数错误、
Kernel
加载到(DDR) SDRAM

的地址不正确，
Kernel
编译时指定的(DDR) SDRAM

运行地址不正确等。这样就需要一项一项排查错误，当错误被排查完毕，通常打印出
start_kernel
…是种必然，如果打印出这仪信息说明
Kernel已
进入到start_kernel()
执行，如果此时有串口启动打印就比较成功了，如果仍然没有打印启动信息，就需要另外一种调试技术。

附代码修改：init/main.c

<<-

…

extern void printascii(const char*);
//
Modify

asmlinkage void __init
start_kernel(void)

{


char *
command_line;


extern struct
kernel_param __start___param[], __stop___param[];


printascii("start_kernel
…");
//
Modify


smp_setup_processor_id();

…

->>

Kernel
启动调试技术-
使用printascii()
函数打印printk()
缓存信息
，如果Kernel已进入到start_kernel()
执行，仍然没有启动信息打印出来，说明串口波特率出问题的可能性比较大，启动信息是暂时缓存到临时buffer--printk_buf
中的，进入start_kernel()
中会对串口波特率重新初始化，当初始化完成后，缓存的系统启动信息便打印出来，不能打印说明用于串口波特率初始化的系统时钟源没有初始化正确，通常是系统时钟源和实际的晶振频率不一致导致的，通常排查和解决这个问题后，系统启动信息是能正确打印的。为了帮助解决问题，可以使用
printascii()
打印printk_buf
内容。这样就能把printascii
（）打印的系统信息和预想的系统信息进行比较，从而加快解决问题的进度。

附代码修改：kernel/printk.c


<<-

…

extern void printascii(const char*);
//
Modify

static char printk_buf[1024];
//
Modify

asmlinkage int printk(const char *fmt, ...)

{


va_list
args;


int
r;


va_start(args,
fmt);


r
= vprintk(fmt, args);



va_end(args);



printascii(printk_buf);
// Modify


return r;

}

…

static int recursion_bug;

static int new_text_line = 1;

//static char printk_buf[1024];
//
Modify

…

->>

如上是Kernel
裁减移植过程中最重要的两个启动调试技术，灵活使用将带来工作效率的提升，不管硬件平台是那种ARM
或者其它类型的CPU
，也不管是哪个
Kernel
版本（如Linux-2.6.24
、Linux-2.6.30
等
都可以采用这两个启动调试技术解决实际问题。为了支持
printascii()
函数，需要在
Kernel
裁减中（make menuconfig
）添加Kernel hacking

->[*]Kernel low

-
level


debugging
functions
的支持。



我的补充:

1/ 可以在/kernel/head.s里添加打印看是否跑到mmu开启前:

__turn_mmu_on:

//打印一个字符a

mov r9,r0

mov r0,'a'

bl printascii //该函数位于arch/arm/kernel/debug.s，调用了

include/mach/debug-macro.S

mov r0,r9

//现在开启mmu

mov r0, r0

mcr p15, 0, r0, c1, c0, 0 @ write control reg

mrc p15, 0, r3, c0, c0, 0 @ read id reg

mov r3, r3

mov r3, r3

mov pc, r13 /*实际调用了__switch_data,在head-common.s*/

2/ 一般按楼上方法,在startkernel就可以打印出来,如果:在第一步可以打印,而开启mmu后不能打印,那绝对是虚拟地址映射问题,这个问题我搞了2天了....

3/ 如果还没有反应，就要检查串口打印那段

debug-macro.S
是否有问题了。



总结一下:

/compressed/head.s和/kernel/head.s基本上不用改,看文件头,2001年写的,就知道了.呵呵.