dtb编译
㈠ 一加3 LineageOS 18.1内核编译记录
最近看到一篇关于安卓手机运行docker的文章, 正好家里有个吃灰的一加3, 就想着来试试, 于是有了如下内容
第一次编译安卓的内核, 所以做了下记录, 免得下次又得从头找资料
以下内容基于ubuntu 22.04 amd64架构服务器
打开手机 /proc/version 文件, 其中包含了相关编译信息, 能在这里面找到clang版本和对应的分支信息
我手机内核是使用的clang 11编译的, 所以我这里检出的是11的分支
我编译的是安卓9的内核, 所以GCC我选择的9.0的分支
记得修改config配置, 将其替换成你内核的配置文件名
r383902b可以在 /proc/version 里面找到对应的
我这儿编译的是一加3的LineageOS 18.1的内核
编译完成之后即可在out目录下找到编译好的文件, 要刷入手机的话, 还需要将其打包成boot.img, 这个在不同的安卓版本上操作也有一定的差异, 就不做详细记录了, 自己Google吧
一加3的编译文件目录为: out/arch/arm64/boot/Image.gz-dtb
㈡ linux触摸屏驱动中什么时候会调用suspend这个函数
android系统摁下电源键后会让系统进入休眠以达到节电的目的。内核驱动中和休眠相关的就是suspend和resume函数。
suspend函数用于休眠，resume函数用于唤醒。下面分析驱动中的这两个函数是如何被调用到的。
驱动部分：
首先需要分析驱动的注册过程，较新的内核都是采用DTS方式来取代在内核中直接定义platform_device数据结构的注册方式，本文是基于DTS机制的内核来分析。
proct对应的dts文件在编译时被编译为dtb文件，uboot在启动时候会将其地址传给内核，内核在启动过程中会去解析，具体解析是在start_kernel()->setup_arch() --> unflatten_device_tree()中具体分析可以参考网上，解析的最终结果会存放在allnodes地址处，这个allnodes随后在machine的init函数
中被使用，init函数中会根据allnodes中的节点数据组合成platform_device数据结构，然后将其注册到platform总线上，下面简要分析一下并重点关注这些初始化过程中和
pm相关的初始化。
我参与的项目中machine的init函数就是via_init_machine函数，在这个函数中就是调用了of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL)这个函数来解析allnodes的。of_platform_populate是系统提供的接口。下面分析这个接口的实现：
[html] view plain
int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent)
{
struct device_node *child;
int rc = 0;
root = root ? of_node_get(root) : of_find_node_by_path("/");
if (!root)
return -EINVAL;
for_each_child_of_node(root, child) {
rc = of_platform_bus_create(child, matches, lookup, parent, true);
if (rc)
break;
}
of_node_put(root);
return rc;
}
root最后就是取到的根节点，然后其作为参数传递给of_platform_bus_create，of_platform_device_create_pdata的实现如下：
[html] view plain
static int of_platform_bus_create(struct device_node *bus,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent, bool strict)
{
const struct of_dev_auxdata *auxdata;
struct device_node *child;
struct platform_device *dev;
const char *bus_id = NULL;
void *platform_data = NULL;
int rc = 0;
/* Make sure it has a compatible property */
if (strict && (!of_get_property(bus, "compatible", NULL))) {
pr_debug("%s() - skipping %s, no compatible prop\n",
__func__, bus->full_name);
return 0;
}
auxdata = of_dev_lookup(lookup, bus);
if (auxdata) {
bus_id = auxdata->name;
platform_data = auxdata->platform_data;
}
if (of_device_is_compatible(bus, "arm,primecell")) {
of_amba_device_create(bus, bus_id, platform_data, parent);
return 0;
}
dev = of_platform_device_create_pdata(bus, bus_id, platform_data, parent);
if (!dev || !of_match_node(matches, bus))
return 0;
for_each_child_of_node(bus, child) {
pr_debug(" create child: %s\n", child->full_name);
rc = of_platform_bus_create(child, matches, lookup, &dev->dev, strict);
if (rc) {
of_node_put(child);
break;
}
}
return rc;
}
根据传入参数，我们这里直接分析of_platform_device_create_padate函数，如下:
[html] view plain
struct platform_device *of_platform_device_create_pdata(
struct device_node *np,
const char *bus_id,
void *platform_data,
struct device *parent)
{
struct platform_device *dev;
if (!of_device_is_available(np))
return NULL;
dev = of_device_alloc(np, bus_id, parent);
if (!dev)
return NULL;
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
#endif
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
*/
if (of_device_add(dev) != 0) {
platform_device_put(dev);
return NULL;
}
return dev;
}
of_platform_device_create_padate->of_device_alloc->platform_device_alloc
便在platform_device_alloc函数中进行进行alloc和初始化了，实现如下：
[html] view plain
struct platform_device *platform_device_alloc(const char *name, int id)
{
struct platform_object *pa;
pa = kzalloc(sizeof(struct platform_object) + strlen(name), GFP_KERNEL);
if (pa) {
strcpy(pa->name, name);
pa->pdev.name = pa->name;
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(&pa->pdev);
}
return pa ? &pa->pdev : NULL;
}
可以看到有个device_initialize，这里面对pdev.dev做一些列的初始化，其中有一个函数就是device_pm_init，这个函数就是我们一直关心的device相关的pm函数，具体实现如下：
[html] view plain
void device_pm_init(struct device *dev)
{
dev->power.is_prepared = false;
dev->power.is_suspended = false;
init_completion(&dev->power.completion);
complete_all(&dev->power.completion);
dev->power.wakeup = NULL;
spin_lock_init(&dev->power.lock);
pm_runtime_init(dev);
INIT_LIST_HEAD(&dev->power.entry);
dev->power.power_state = PMSG_INVALID;
}
可以看见它对device和功耗相关的数据做了一些初始化，我们这里先重点关注下dev->power.entry，初始化一个链表头，所以他/它很有可能会在后面加到某个链表里面去，而那个链表应该是用来保存所有的device用的。系统中所有的platform_device都是通过这种方式注册到系统中的，那么应该所有的platform_device都会初始化一个dev->power.entry，如果到时候把所有的dev->power.entry都添加到某个链表上去，那么系统到时候查询的时候只要找到这个list head就可以找到所有的platform_device了。嗯，不过这是我们的猜测。我们接下去分析来验证下。
platform_device通过alloc之后已经初始化好了，那么接下去就可以添加到系统中了，所以我们再回头看of_platform_device_create_pdata的实现。
函数在of_device_alloc之后把dev->dev.bus赋值给了platform_bus_type，接着就调用了of_device_add函数，在of_device_add函数中最后通过device_add添加到了bus上，但是device_add中有个函数需要我们关系，就是device_pm_add(dev)，实现如下：
[html] view plain
void device_pm_add(struct device *dev)
{
pr_debug("PM: Adding info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
mutex_lock(&dpm_list_mtx);
if (dev->parent && dev->parent->power.is_prepared)
dev_warn(dev, "parent %s should not be sleeping\n",
dev_name(dev->parent));
list_add_tail(&dev->power.entry, &dpm_list);
dev_pm_qos_constraints_init(dev);
mutex_unlock(&dpm_list_mtx);
}
可以看到这里list_add_tail(&dev->power.entry, &dpm_list);这就验证了我们之前的猜测。所有注册到系统中的设备，最终都是会添加到dpm_list这条链表上。
那么系统在休眠的时候是如何通过dmp_list这表链表来suspend设备的呢？接下去就是我们要分析的电源管理部分内容。
系统电源部分：
电源管理相关文件在kernel/power目录下，前面已经分析到。系统中注册的设备都是会添加到dmp_list这条链表上的。那么睡眠的时候系统应该是会查找dmp_list这条链表，
然后通过这条链表依次去查到对应的driver，然后调用driver中的suspend方法。下面我们来验证。
2.在suspend会轮询bus下的driver，然后一次调用到driver->pm->suspend方法，然后进入休眠。
3.state_store->pm_suspend->enter_state->suspend_devices_and_enter->dpm_suspend_start->dpm_suspend->device_suspend->__device_suspend->pm_op->(ops->suspend)
㈢ 单独编译内核和设备树
source /opt/fsl-imx-xwayland/4.19-warrior/environment-setup-aarch64-poky-linux
export ARCH=arm64
make -j 16
生成的Image 和dtb在下面的路径
~/imx-yocto-bsp/build-imx8mmevk/tmp/work/imx8mmevk-poky-linux/linux-imx/4.19.35-r0/git/arch/arm64/boot
㈣ dtb是什么文件怎么打开
dtb是可以减少linux内核版本的数量的文件。同一份linux 内核代码可以在多个板卡上运行，每个板卡可以使用自己的dtb文件。
1，在linux内核启动过程中会解析dtb文件，根据dtb文件中设备列表进行加注各个外设的驱动模块。
2，PC机在启动时会自动扫描外设，而在嵌入式中，linux内核启动过程中只是解析dtb文件，从而加载对应的模块。
3，编译linux内核时必须选择某外设模块，并且dtb中包括该外设的信息。在linux内核启动过程中才能自动加载该模块。
㈤ linux编译u-boot时显示[arch/arm/dts/zynq-zc702.dtb]错误
在编译uboot的时候，会出现出错，因此我们要首先做 make disclean. 将原来的一些中间文件清理干净。
因此在编译Uboot依次执行 1.make disclean
2.make smdk2440_config
3. make
就可以编译通过了
㈥ 所有dtb对应什么芯片
设备树的源文件为.dts和.dtsi文件，经过设备树专用的编译器编译后生成一个二进制的DTB(Device tree Blob)文件。在系统启动时，DTB文件由bootloader加载进内存，此时，内存中的DTB成为FDT(Flat Device Tree)。Bootloader启动kernel时，将FDT的地址传给Kernel，在Kernel启动的汇编阶段，将FDT地址保存在“x5”寄存器中，并定义8字节变量“__fdt_pointer”，用来表示该地址，以供Kernel的C代码使用
㈦ 编译linux内核设备树文件使用什么命令
Linux源码的arch/powerpc/boot/dts/目录下存放了很多dts文件，可以作为参考文件。另外dtc编译器在内核源码2.6.25版本之后已经被包含进去。在2.6.26版本之后，生成blob的简单规则已经加入makefile，如下命令：
$ make ARCH=powerpc canyonlands.dtb
也可以根据自己的硬件修改好dts文件后，用下面类似命令生成dtb文件。
$ dtc -f -I dts -O dtb -R 8 -S 0x3000 test.dts > mpc836x_mds.dtb
$ mkimage -A ppc -O Linux -T flat_dt -C none -a 0x300000 -e 0 -d mpc836x_mds.dtb mpc836x_mds.dtu
㈧ 如何将dtb反编译成dts
由于device tree会将一个node的信息分布在各个文件里，查看起来很不方便，比如如下例子，ldb在三个文件中都有配置：
imx6qdl-sabresd.dtsi:
&ldb {
status = "okay";
.......
};
imx6qdl.dtsi:
ldb: ldb@020e0008 {
#address-cells = <1>;
#size-cells = <0>;
......
};
imx6q.dtsi:
&ldb {
compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
.......
}
其实device tree编译之后最终是会被全部放在一个.dtb结尾的文件，
比如这里是imx6q-sabresd-ldo.dtb，用如下命令就可以看到整个ldb node的内容，而且也可以作为编译之后的检查。
[kris@ecovacs:~/kernel_imx/scripts/dtc]$
./dtc -I dtb -O dts ../../arch/arm/boot/dts/imx6q-sabresd-ldo.dtb > ~/f.dts
㈨ 请教linux启动过程中dtb的作用
dtb文件作用的描述是，使用dtb可以减少linux内核版本的数量。同一份linux 内核代码可以在多个板卡上运行，每个板卡可以使用自己的dtb文件。
1，在linux内核启动过程中会解析dtb文件，根据dtb文件中设备列表进行加注各个外设的驱动模块。
2，PC机在启动时会自动扫描外设，而在嵌入式中，linux内核启动过程中只是解析dtb文件，从而加载对应的模块。
3，编译linux内核时必须选择某外设模块，并且dtb中包括该外设的信息。在linux内核启动过程中才能自动加载该模块。
要使用dtb，需要uboot启动内核时，在bootm命令中指定dtb的位置，格式为：
bootm uImage_addr ramdisk_addr dtb_addr
如果没有ramdisk，就需要写成bootm uImage_addr - dtb_addr，用“-”表示没有ramdisk