(zz)嵌入式linux调试(bootloader && kernel)

移植linux2.6过程中遇到的机器码问题
    http://topic.csdn.net/u/20100818/09/7b1d6b24-c71a-46ea-8c9a-e44e184dd967.html
内核启动停在"Uncompressing Linux...done, booting the kernel."
    http://topic.csdn.net/u/20100817/15/889715e8-004e-4446-8c39-848b14604c62.html

//--以下为引用------------------------------------

嵌入式Linux之Bootloader调试技术
    http://blog.csdn.net/fqheda/archive/2009/05/25/4213859.aspx
嵌入式系统搭建过程中，对于系统平台搭建工程师最初的一步通常是移植Bootloader ，当然移植有几个级别，通常最常见的是参考的EVM 的硬件有了修改（如更改了FLASH ，更改了SDRAM 、DDR SDRAM 等），并且是初次调试硬件，更大的困难是公司为节省成本不打算买上万的EVM 开发板，或者EVM 开发板需要license 才能购买，这时移植Bootloader 是比较难做的，不过也不是没有方法，最有效的有两个--点灯和串口打印 。（作者通过这种方法调试成功过IXP2400(Xscale) 的Redboot 、EP9307(ARM9) 的U-boot 等Bootloader ）

Bootloader 调试技术- 点灯 ，当烧写好Bootloader ，启动Bootloader ，肯定是从一个固定的地址开始执行程序，最初的程序是从FLASH 中读取执行的，有些处理器是直接使用FLASH 地址，有些会影射到FLASH 地址，此时SDRAM 可以认为没用到，如何确认程序有没有直接执行，通常用点灯来验证，在Bootloader 入口代码段尽量靠前初添加点灯代码（使用GPIO 控制），跟踪代码的执行，如果确认点灯代码没问题，程序没执行，那可能是启动地址没有指向FLASH 地址，硬件晶振没起振，硬件IC 电源供电问题，硬件IC 引脚接地问题，CPU 配置字问题（如启动模式），CPLD 时序调节问题等等，这需要硬件和软件工程师联合调试（这需要团队精神）。当然如果移植Bootloader 的工程师做过硬件那是再好不过的。所有的问题排查和解决之后，点灯成功是种必然。

Bootloader 调试技术- 串口打印 ，点灯成功之后就可以对重要的配置参数跟踪调试，比较重要的是程序跳转到SDRAM 执行( 重点是SDRAM 时序参数和clk 配置正确) ，而后就需要打通串口，打通串口需要对UART 参数进行正确配置，测试用输出字符函数（这里可没printf() 函数可用），通常点灯成功之后打通串口相对容易，这里重点是使用串口调试程序，在printf() 函数可用之前使用低级别的串口输出函数实现程序的跟踪调试（通常是调试汇编代码），在printf() 函数可用之后使用printf() 调试代码。

如上是Bootloader 调试过程中最重要的两个调试技术，灵活使用将带来工作效率的提升，不管是U-boot 、Redboot 还是厂商专有的Bootloader( 如rrload 、vivi 等) ，两个调试技术都有效。

       ( 作者 冯青华 信庭嵌入式工作室 (www.xteda.com)- CEO )       

嵌入式Linux之Kernel（裁减移植）启动调试技术
    http://blog.csdn.net/fqheda/archive/2009/06/01/4230999.aspx

嵌入式系统搭建过程中，对于系统平台搭建工程师在完成Bootloader 的调试之后就进入Kernel 裁减移植的阶段，其中最重要的一步是Kernel 启动的调试，在调试Kernel 过程中通常遇到最常见的问题是启动异常:

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

........................... done, booting the kernel.( 挂死在此处)

导致驱动异常（启动挂死）的原因有很多，如基于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;

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