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