最近一段时间主要是搞内核，当然，也要和其它部门扯皮。
这还是我第一次在实际工作是移植内核，以前那些，只能算是学习、积累。这里记一下移植过程的一些经验。

一、管脚复用
之前我只移植过S4C2440平台的内核，该芯片datasheet不多，一个文档搞定，不像我现在用的芯片，有N个文档要看，而且有N个核。像GPIO的配置，也比2440复杂得多。在管脚复用上，我掉进过2个坑里。
我们统一在u-boot里做管脚复用，在仔细对着硬件平台的原理图的GPIO后，确认没搞错。不过还是出问题。
一个是RS485，都知道它是半双工的，在收、发之前要做方向的配置，这个配置就是一个GPIO的电平的配置。不过测试时发现，只能发，不能收，拿示波器来看，发现那个GPIO无论设置为0还是1(已确认能设置0或1)，一直是高电平，——感觉上，这个GPIO无法操作。幸亏学习了sysfs，将寄存器的读写操作做成/sys/下的一个文件(前面写有sysfs的驱动内核的文章)，使用echo来查看该GPIO管脚复用寄存器，发现值不是我们期望设置的，它改变了，复用成其它的功能了，不管三七二十一，先强制设置成是GPIO功能，结果可以接收数据，能肯定是复用的问题。u-boot没错，就是内核有问题，于是便去查，发现内核在某个地方也做了管脚复用的配置，对着手册看，配置的值果然是我们看的值。继续探索，发现是内核配置选项中开了管脚复用的宏，去掉该配置就可以了。
另一个坑隐藏得比较深，因为涉及到另外的一个核上的代码。当我测试与linux有关的外设时，一切都正常，比如，led能点亮。但我运行其它核的程序时，led灭了。使用上述方法查找，发现是管脚复寄存器值改变了。这个问题在项目例会上提出，然后时时被领导问进展(也不是那么频繁，比如一天问两次这样吧)。在不到48小时内(周三10时开会，周四晚上19点多解决)，终于找到出现问题的函数并解决，这还是一个同事帮忙找到的。花费时间最多的是定位在哪个地方将寄存器值改变了。一来，涉及了三个核的程序运行，二来，代码太庞大，我又不熟悉(熟悉代码的人在做其它紧急的事)。
开始怀疑的时候，我在整个代码树搜索寄存值的地址，包括基地址。使用管脚复用基地址找不到是因为那个函数的管脚复用基地址是用另一个基地址做偏移算出来的，所以，不能直接找出来。我没有考虑到搜索改变后的寄存器的那个数值，因为给寄存器赋值不会直接把所有的位都写成一个数，这是我的经验，——但那个函数是这样做，它赋的值就是我看到的值。我也没考虑搜索各个寄存器地址的偏移量，这是我的疏忽之处。之所以说那么多，是为自己找借口：不是我没有从这个方向查找，是查找方法不当。
再说回那个函数的用途，它是EVM板的一种用法，在人家的EVM板上，那些管脚就是这么配置的，没问题，问题是我们参考人家时，把那些管脚做别的用途。从这个角度看，有时候，直接拿人家的东西未必是好的。不过现在的开发，一般不会自己从头设计，比如我之前的ARM开发板，就是那个公司从三星的参考设计上开发的。如果有个强大的技术支持，应该会好很多。在与同事聊天时，聊到某家很牛的公司买某平台芯片提供商很多芯片，芯片提供商直接派人到该公司做支持。

二、rtc晶振
某天无意中发现设备上的时间会慢慢变慢。一天有半个小时的误差。于是上网找资料，找到内核的HZ配置，时钟中断，rtc同步等等很多资料，但好像没什么联系。只好求助硬件部门帮查找。首先硬件电路设计与我们参考的那个板子相同，芯片也相同，内核也相同，按理应该是没有问题的。在人家板子上也未发现问题，时间很准。最后硬件部门出动了频率计数器，发现rtc的晶振不是外部的32.768KHz，而是32KHz左右，查看芯片手册，里面说可以配置使用内部的振荡器，也可以配置使用外部的，我们是使用外部的晶振，但为何不生效？继续看手册，发现有一个寄存器的位是做这个配置的：

Internal 32-kHz clock source control bit (EEPROM bit):
when 0, the internal 32-kHz clock source is the crystal oscillator or an
external 32-kHz clock in case the crystal oscillator is used in bypass
mode
when 1, the internal 32-kHz clock source is the RC oscillator.

在u-boot读取这个位的值，结果是1，确实是使用了内部的振荡器，将它改成0，时间果然准确了。既然找到问题，就好办了。每次u-boot启动时都是读这个位的值，如果是1，就将它改成0。但是，有一个疑问，为何人家参考设计的板子没设置这个值，也没问题？
cu上也有篇类似的文章，我也是从里面找到一些线索的。

注1：用人家的东西，坑太多了。
注2：公司对于在用品bug处理比较严格，要求xx天给出临时解决方案，yy天给出永久的解决方案。于是在文中也顺便提了一下我解决小bug所花的小时间。

如果本文对阁下有帮助，可赞助笔者以输出更多好文章。
支付宝[email protected] 或 微信fly_camel_fly 均可。感谢！
                                

本文固定链接: /embedded-linux/some-problem-of-porting-linux-kernel.html