内容简介：描述调试过程中所遇问题及其解决办法和过程，可作为新手的FAQ使用。
1. Issue: 不能从SD卡启动。
Fixed: 自己疏忽造成，手册已经提到要先用"HP Disk Storage Format Tool"格式化SD卡。
2. Issue: 烧写的Xload不能启动。
Fixed: ECC格式不对造成，xload需要使用HW Ecc, 其他全部使用SW ECC。列表如下：
x-loader 'nand ecc hw'
u-boot 'nand ecc sw'
okernel 'nand ecc sw'
rootfs 'nand ecc sw'
spash 'not required', default sw without oob
3. Issue: 启动过程中打印错误信息"Ignoring unrecognised tag 0x54410008".
Fixed: 屏蔽掉U-Boot中的函数'setup_videolfb_tag', 因为它传递了错误的参数给Kernel.
4. Issue: 启动过程中打印错误信息"dpll3_m2_clk rate change failed: -22".
Fixed: 这个错误发生在初始化SDRAM的PLL时钟的时候。
修改文件"arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h", 修改数组'mt46h32m32lf6_sdrc_params'的第3个指，把133333333改成133000000.
SDRAM的默认时钟为266MHZ(LPDDR: Low Power Double Data Rate, so it running 133MHZ instead), 计算结果应该为 133000000, 而非预定义的133333333，所以报了错。
5. Issue: 启动过程中打印错误信息"omap-dss DISPC error: Requested pixel clock not possible with the current OMAP2_DSS_MIN_FCK_PER_PCK setting. Turning the constraint off."
Fixed: 修改文件'.config', 把变量 'CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK'的值从 4 改成 2.
或者：'make menuconfig' -> System Type -> TI OMAP Implementations -> Minimum FCK/PCK ratio (for scaling)
6. Issue: 启动过程中，在打印"Freeing init memory: 164K"之后，打印"Kernel panic - not syncing: Attempted to kill init!"，然后系统崩溃.偶然出现，频率不低。
Fixed: 使用2.6.29的kernel一直没解决，移植到2.6.38后解决。怀疑Kernel处理UBIFS出了问题。
7. Issue: 使用网口芯片"smsc 9221"，替换原来的"dm9000".
Fixed: u-boot 1.3.3 的软件改动：
修改源文件 "include/configs/sbc8100.h":
* Disable the 'dm9000' relatives.
* Add new line: '#define CONFIG_DRIVER_SMC911X 1' & '#define CONFIG_DRIVER_SMC911X_BASE 0x2c000000'.
修改源文件 "board/sbc8100/mem.c":
* Disable the '#ifdef CONFIG_DRIVER_DM9000' at the line 263th, for enable the GPMC configurations as that of 'dm9000'.
修改源文件 "drivers/net/smc911x.c":
* Add new line '#define CHIP_9221 0x9221'. Append new member '{CHIP_9221, "LAN9221"}' to the array 'chip_ids'.
注意这里为什么选择地址0x2c000000. 这是因为我的硬件把网口挂在了CS6上，关于CS6的配置位于源文件"board/sbc8100/mem.c"函数"gpmc_init()"的末尾。
这个虚拟地址，是在这一段配置中固定了的，具体请看TI手册关于CS_CONFIG(0-7)的描述。
Linux-2.6.29的软件改动：
* make menuconfig: disable dm9000, enable 'CONFIG_SMSC911X'.
* 修改源文件 "arch/arm/mach-omap2/board-omap3sbc8100.c"(这个目录是我的硬件平台源文件)：
* Disable 'dmp9000' relatives.
* Modify the structure 'smsc911x_config', change the member flags' value from 32BIT to 16 BIT.
* 修改源文件"arch/arm/plat-omap/include/mach/board-omap3evm.h"
* Change 'OMAP3EVM_ETHR_GPIO_IRQ' from 176 to 25(这是我的硬件配置)
* Change 'OMAP3EVM_SMC911X_CS' from 5 to 6. (这个选项没用)
就这样，比较简单，没有新的开发内容。
8. Issue: USB PHY 'isp1504'不能工作。
Fixed: 两个问题：
第一，isp1504有个片选引脚，操作过程中需要拉底。
第二，关于isp1504的clk引脚，如果是HostController的PHY，clk由Controller提供，1504只输入；如果是DeviceController的PHY，clk由isp1504提供，controller输入，此时isp1504的clk来源于XTAL1输入的分频。在我们的硬件中，是把isp1504作为HostController的PHY来使用。用示波器打此clk引脚，发现在通讯的时候有两个时钟信号，所以确定需要关掉ISP1504的CLK输出。根据isp1504的手册，发现需要把isp1504的XTAL1&XTAL2两根引脚置成VCC/GND或者GND/GND，告知硬件人员问题随即被解决。
以上硬件描述来源于ISP1504的手册。
9. Issue: ST16C554 QuardUart芯片驱动调试。
Fixed:
四合一串口扩展芯片，在目标硬件上位于片选3上，驱动可沿用driver/8250.c，只是在以下地方有修改：
* u-boot-1.3.3/board/sbc8100/mem.c, 在网口CS6地址的配置下面，添加了CS3的配置(CONFIG1-7: 用于配置当前片选的访问时序)。
* platform_device，加入了ST16C554的四个串口描述，修改了8250的部分代码。注意我这边的uartclk取值3686400。
10. Issue: SJA1000T CAN芯片驱动调试。
Fixed:
最重要的部分，是在调试CAN芯片的读写时许。参见SJA1000T手册 'AC timing diagrams'这章节的图，一次CAN寄存器的读写包括5个信号： AD(偏移地址),ALE,RD或者WR,CS。
这4组信号在我的目标硬件上都有PIN复用，最终我是采取了一次写操作(AD+ALE)，然后紧跟一次读或者写操作(RD/WR+CS)来完成一次寄存器的读或者写动作，两次操作连续且受信号量保护。
具体应用到读者的硬件平台上，跟硬件平台的对应PIN脚设计相关。
除了上面的时序外，还要做：
* CPU端对应CS的访问时序配置，跟st16c554一样.
* 移植Lincan或者SocketCan驱动。(linux-2.6.29 不带can驱动, linux-2.6.38自带socketcan)。
11. Issue: PIN脚复用配置。
Fixed:
在前面的驱动中，很多地方都涉及PIN脚复用配置。
涉及源代码： 'u-boot-1.3.3/board/sbc8100/sbc8100.c'中的宏定义'MUX_DEFAULT_ES2'，文档支撑"7.6.3.2 PADCONFS Register Description"
每个芯片的驱动开发之前，都应该先来此确定一下CPU对应的PIN脚设置是否正确。特别是在遇到以下情况后，首先应来此校验一下：
* PIN脚默认电平不对；
* PIN脚不能输出或不能接收输入；
* PIN脚不能唤醒睡眠状态；
12. Issue: 低功耗调试
Detail:
客户要求最低功耗20MA(5V),使用linux-2.6.29最低功耗只能达到90MA，相差甚远。
原来的硬件+linux-2.6.29最低功耗太高的原因：
* 硬件设计没有考虑功耗问题，有些芯片即使断掉VDD输入仍在通过地址线数据线漏电。
* linux-2.6.29软件不完善，最小系统不能进入休眠模式，最小系统IDLE只能减小20MA功耗。
解决办法及过程：
* 硬件：拿掉客户所不需要的芯片；
* 软件：尝试升级kernel。
Linux GIT有一分支叫linux-omap, 这个分支主要由TI自己的人负责omap系列芯片的模块驱动开发、BUG解决、kernel版本更新、迭代，由大量的OMAP芯片使用厂商开发对应硬件平台支撑代码(kernel/arch/arm/mach-omap2/board-XXX.c/h)。
如果读者感兴趣，可google这些关键词: linux-omap, beagleboard, linux-pm。
现在，以下链接可以使用：
"" : 这个分支的介绍
"" : GIT分支下载地址
第一个网页页面中，有个8mw的概念，我就是奔着这个8mw的目标才去移植新版本的kernel。
以下日志均产生于移植过程中。
21. Issue: 启动过程停止在 'Starting kernel ...' ，kernel不能被uncompress
Fixed:
* 默认选择的平台是omap3evm，我更改为omap3_beagle，问题即被解决。
* 原因见源代码"arch/arm/plat-omap/include/plat/uncompress.h", evm默认debug port是UART1，而我的硬件是UART3.
* 而且我们的硬件很接近beagleboard.
22. Issue: 启动过程停止在以下打印以后：
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Fixed:
最后原因确定是： 编译器版本造成。把编译器版本从 'arm-2007q3' 更新到 'arm-2009q1' 问题即被解决。
寻找问题的过程很复杂。
* 首先核对u-boot和kernel的magic_number发现是对的。
* 其次让硬件飞了一个调试用的led（因为调试串口可能还没初始化），发现它是卡在'init/main.c: calibrate_delay()'，非常底层，怀疑是timer没跑起来导致jiffes没有更新。
* 遍历我们的硬件与beagleboard的所有区别，尝试合并timer相关代码（timer-gp.c/dmtimer.c/ex...）从2.6.29到2.6.38，尝试多个版本u-boot和kernel，结果一样，几近绝望！
* 回过来往网上一搜，发现elinux/beagleboard的limitation一节有明显的说明，要求升级toolchain！
升级toolchain以后，u-boot原来的编译选项 'armv7a' 要改成 'armv7-a', 源代码在这个位置'omap3/config.mk'。
23. Issue: 清理arch/arm/mach-omap2/board-omap3beagle.c源代码。
Fixed:
这是跟硬件平台beagleboard底层相关的源代码，因硬件有区别，所以需要改动，不然会出一些莫名错误。
最好的办法是不要改之，而复制一个board-omap3XXX.c代码，到复制的源文件中改，再修改Kconfig和Makefile，为自己的硬件平台生成一个对应的配置选项。
Beagleboard这一条线相关的其他代码都需要更改，改的最多的就是IO口。
24. Issue: linux-omap-2.6.37不能加载UBIFS，打印以下错误信息：
(2.6.38也可能有同样的问题)
cmdlinepart partition parsing not available
Creating 5 MTD partitions on "omap2-nand.0":
0x000000000000-0x000000080000 : "X-Loader"
0x000000080000-0x000000260000 : "U-Boot"
0x000000260000-0x000000280000 : "U-Boot Env"
0x000000280000-0x000000680000 : "Kernel"
0x000000680000-0x000010000000 : "File System"
agan>> Try attach 4, with VID_HDR_OFFS: 0
UBI: attaching mtd4 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
uncorrectable error :
UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read 512 bytes
uncorrectable error :
UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 4:512, read 512 bytes
uncorrectable error :
UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 5:512, read 512 bytes
uncorrectable error :
UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 6:512, read 512 bytes
Fixed:
最后的解决办法：
1. board-omap3beagle.c(或者board-omap3XXX.c: 使用你的平台源文件) -> omap3beagle_nand_data: 添加一个新选项 '.devsize=1'.
发现原因：
board-omap3beagle.c -> omap3beagle_nand_data.options=NAND_BUSWIDTH_16,的确配置了使用16位Flash，但是纵观后续代码这个options根本没有得到使用,上层一直在使用8Bits位宽配置。
发现过程颇为复杂：
* 在同一个GIT Server上，发现2.6.32的kernel可以加载UBIFS。
* 调试两个版本的源代码：nand_ecc.c->calculate_ecc()，发现计算之前，从同一地址读出的数据就不一样，因此基本确定是Flash读写或者初始化参数有问题造成的。
* 比较32/38两个版本的Flash配置，再核对38版本Flash的初始化过程，最后发现了问题。
2. 16位配置生效以后，仍有报ECC错误或者偶然panic现象，这样解决：
* 移植代码 'nand_base.c'，从 '2.6.32' 到 '2.6.37', 然后在UBI + NAND + swecc的配置下工作一切正常。
* 在源代码函数'omap2.c:omap_nand_probe()'中新添一行'info->nand.badblockbits = 8;'。感觉这里有BUG。
然后感觉一切正常，没有任何错误打印信息。
25. Issue: kernel-2.6.37的Suspend不能挂起最小系统。
Fixed:
参照网页'OMAP_Power_Management.htm'里面列出的测试脚本，我自己写了一个pm.sh，运行后，通过'cat /debug/pm_debug/count'发现CORE从来没有进入过Sleep/Ret状态。
最后解决办法：
修改'arch/arm/mach-omap2/usb-musb.c', 加入以下函数：
////////////////
static void omap3_musb_reset(void)
{
#define OTG_SYSCONFIG 0x404
#define OTG_SYSC_SOFTRESET BIT(1)
void __iomem *otg_base;
if (!cpu_is_omap34xx())
return;
otg_base = ioremap(OMAP34XX_HSUSB_OTG_BASE, SZ_4K);
if (WARN_ON(!otg_base))
return;
/* Reset OTG controller. After reset, it will be in
* force-idle, force-standby mode. */
__raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
iounmap(otg_base);
}
void __init usb_musb_init(struct omap_musb_board_data *board_data)
{
return omap3_musb_reset();
}
////////////////
这源于linux-omap邮件列表里面的一个补丁，原因是"USB-OTG"被Bootloader置成Awake状态，且在Kernel中这个状态没有被更改过，而CORE对OTG有依赖关系。
问题的解决也颇为复杂，在应用这个补丁之前我还尝试升级过u-boot到'beagleboard-validation-u-boot-beagle-XXX'的多个版本，均无作用。
应用补丁后，目标硬件在Suspend to Sleep/Off状态时，可以达到50MA的功耗，如果硬件改改应该可以进入20MA的区间。
以上文章是作者原创，如有错误请指出。
