美文网首页
1.1-kernel探索of读取过程1

1.1-kernel探索of读取过程1

作者: 冰糖小新 | 来源:发表于2018-02-13 21:44 被阅读0次

    探索kernel3.18设备树读取过程以及driver的match过程 1


    正文


    首先拿到机器的平台是MTK6750
    先从platform开始分析,
    先从LCM驱动入手,发现MTK已经封装了很多层上去了,最终追溯到mtkfb这样一个platform_driver上

    然后无果
    由于kernel才入门,所以对register等接口调用结构也是一点不了解,所以无果。

    从of.h 分析,到platform.c的platform_match函数

    通过dump_stack();打印堆栈里面的函数调用关系

    幸好有code search这样的工具(OpenGrok search),能快速定位代码,虽然使用体验不好,将就用吧。


    1. kernel3.18设备树的读取过程以及driver的match过程
      通过个人的阅读,match的过程分为6部分,
      (1)是设备树的内容,
      (2)是driver的内容,
      (3)是何时读取设备树内容的,
      (4)是何时调用driver内容的,
      (5)是何时进行匹配的,
      (6)是如何进行匹配的

    (1).设备树的内容:
    设备树的内容比较多,已经被很多书单独拿出来讲解了
    所以参考链接:

    (2).driver的内容:
    我们暂时将mtkfb里面的内容为driver的内容,因为里面有真正去注册一个platform_driver,这个driver似乎和其他的driver不同(比如sensor的driver似乎不是platform_driver)
    这里面有各种熟悉的probe,suspend,resume这种关键字,但和本主题最相关的应该是如何init,通过查看代码以及打印log证明register函数才是直接相关的

    从log可以看出来
    do_one_initcall是调用mtkfb_init的上一级,先mark一下,这一段至少可以看出是如何调用module_init的
    但是本主题的关键不是这个,

    (3).何时读取设备树的内容:
    通过log可以发现至少是在platform_match()函数之前,在platform_match()函数里面发现了of_driver_match_device()函数,通过字面上的意思是设备树驱动匹配device,所以需要深入看一看。
    通过对log的查看

    trace_of_log_2.png

    可以发现其中的“mediatek,MTKFB”match的时候是没有区分大小写的,所以追查下去是用了strcasecmp函数


    trace_of_2.png

    这是打印log的位置
    发现node->properties->value和matches->compatible都写好了值,根据log在遍历node->properties->value可以看出来node->properties->value是读取的of,所以现在否定了of数值在platform_match()中读入,而应该是在操作node->properties->value为线索继续找。

    现在验证一下是否是在platform_match()之前都将of信息读入了,所以在of_driver_match_device(dev, drv)函数的调用路径,虽然都是能调到base.c里面的of_device_id *__of_match_node(const struct of_device_id *matches, const struct device_node *node)
    但重点是node->pro...->value的数值是多久写入的,所以要看一下代码调用流程,万一在函数里面读取的呢?所以可以直接打印一下value(经过尝试,发现value打印不出来,似乎遇到一点情况,还未知,正在看)~~

    在base.c的__of_match_node函数里面,打印一下node->properties->value的数值,因为在platform_match()函数里面能打印出来drv->...->的name信息,但是打印不出来dev->...->value信息,所以需要查明到底是哪个时候给value赋值的,然后才能找出来是哪个时候读取of的

    由于在dd.c中不能直接打印出来value,暂时就准备自己写打印函数来看能不能打印

    实践证明是可以自己写调试函数的,所以以后会自己写调试函数,这样不至于到处打重复log而且还难搜索

    由于一直遇到null pointer 导致重启,通过log发现只有少数固定value是null的,所以每次打印log的时候筛选了一下,避免访问null,当然对为什么node函数里面能过滤null指针感兴趣,但是这次目标不再这里,可以mark一下
    从log可以看出来,of数值早就加载到dev里面了,所以还需要继续追溯


    之前是追溯到bus_for_each_dev,但我们能发现有一个函数和此函数特别像bus_for_each_drv,这里面的其他操作比如klist等


    由于时间关系,这次暂时分析道这里,由于是粗略记录,没有详细的分析,所以后面会重新编辑这篇文章。

    相关文章

      网友评论

          本文标题:1.1-kernel探索of读取过程1

          本文链接:https://www.haomeiwen.com/subject/nvojtftx.html