Kernel加载程序调试实作
kernel加载程序目的将kernel主程序进行解压缩并加载正确位置，此程序与kernel主程序是两个不同程序，但会一起包在zImage中只是kernel加载程序会attached在zImage的前面。调试时需 file不同的 ELF file才能进行正确的调试工作，kernel加载程序的位置在arch/nds32/boot/compressed/vmlinux，指令如下所示。
#ddd --debugger nds32le-linux-gdb arch/nds32/boot/compressed/vmlinux
kernel主程序的ELF file “vmlinux”在kernel source code的根目录下指令如下所示。
#ddd --debugger nds32le-linux-gdb vmlinux
 Linux kernel 调试实作
kernel加载程序执行完毕后会跳到kernel主程序执行。进入点是arch/nds32/kernel/head.S的assembly code执行完后会进入 kernel 的主要函数 “start_kernel”。
 RAM offset patch
晶心版Linux原始码搭配XC5平台，RAM的起始位置(指的是PA)是0x0，使用者FPGA开发板的RAM起始位置如果不是0x0，必须要修改FPGA板子中RAM的起始位置，做法是在晶心版的Linux原始码中进行RAM address patch，将原始码中RAM位置调整到FPGA开发板中RAM的真实位置。
 PA/VA remap table
当FPGA板子IO的PA设定正确后，使用者需要设定PA/VA remap table，作法可参考arch/nds32/include/asm/spec-ag101.h，依照apec-ag101.h中PA/VA对应的关系去增减使用者自己IO device的 PA/VA remap table。
Kernel 解压缩与software breakpoint在进行kernel 调试时，如果在低地址处，例如:head.S中进行调试，当设定 software breakpoint时，会有breakpoint无法停下来与AICE 断线的情况发生。原因是当使用者设定software breakpoint时，breakpoint处的instruction会修改并加入break instruction。但kernel解压缩时会将调试的程序代码覆盖造成与GDB调试不一致性而产生错误。解决的方法就是原设定software breakpoint改为hardware breakpoint，这样就可以避免因kernel解压缩所造成调试的错误，降低调试时的困难度。
PA/VA 观念说明与调试要领
在原始码arch/nds32/kernel/head.S中
la    $lp, __mmap_switched
mtsr    $lp, $IPC
iret执行完iret后，系统就会从PA转成VA，MMU translation status从translation off转为translation on在此分界处调试规则如下所述，如果观念不清楚及容易产生调试时的错误，请务必牢记。
 MMU translation off 时期调试在这个时期调试，VA是不存在的。所有的IO address与memory都是PA没有VA，如果调试地址设成VA，容易hit illegal address 而造成exception。
 MMU translation on 时期调试
在这个时期调试，PA是不存在的。所有的IO address与memory都是VA没有PA，如果调试地址设成PA，容易hit illegal address 而造成exception.
 移植Linux的基础组件
MMU translation on后，很快就会进入start_kernel 函数，接下来移植的重点就是移植Linux基础组件，那就是interrupt，timer and UART。当这3个device移植成功后，Linux的架构就建立起来了，printk也可以用了，Linux已经可以正常的运作。如果没有意外，可以执行完kernel甚至将filesystem带起来。接下来用户可以将自己的周边组件一个一个的device driver移植入系统。当周边组件移植完成后，Linux系统移植到晶心平台就完成了。
(本文由Cogo商城-IC元器件在线采购平台搜集整理，
浏览 了解更多详细信息)