我们何时应该在多个设备树 blob 上使用设备树叠加层?

huangapple go评论55阅读模式
英文:

When should we use device tree overlay over multiple device tree blob?

问题

你是否应该创建多个dtsi文件以适应每种配置,然后编译多个dtb文件并将其安装在/boot/中,还是应该使用设备树叠加?

  • 如果你想继续使用现有的方法,为每种硬件配置创建多个独立的dts文件,然后编译并安装对应的dtb文件,这是一种有效的方式。这样,每种配置都有一个单独的dtb文件,可以在启动时选择正确的dtb。

  • 另一方面,使用设备树叠加也是一种可行的方法。你可以保持一个基本的dts文件,然后为每种配置创建叠加(overlay)文件,每个叠加文件仅包含与特定配置相关的更改。在运行时,可以加载适当的叠加文件以覆盖基本的设备树信息,从而适应不同的硬件配置。

选择哪种方法取决于你的需求和偏好。使用叠加文件可以使设备树更加模块化,但也需要在运行时加载叠加,而不是在编译时生成不同的dtb文件。根据你的具体情况和偏好,选择合适的方法。

英文:

I have a custom board based on iMX8MP processors. This board can have 3 different hardware configuration. Basically the number of adc and shift registers are different between them. I want to be able to select correct dtb at boot time based on a truth table. I have done a u-boot script to select correct dtb which should be located in /boot/.

For a time being, I have generated all dtbs with dtc command. Then I generated dts again from those dtbs to get rid of all dtsi and to have one compact dts file for each hardware configuration.

My yocto recipe look like this:

SUMMARY = "U-boot script: auto select dtb for devboard"
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""
COMPATIBLE_MACHINE = "devboard"

DEPENDS = "u-boot-mkimage-native dtc-native"

SRC_URI = "file://autoselect-dtb.txt \
            file://devboard-cirrus8.dts \
            file://devboard-cirrus16.dts \
            file://devboard-cirrus32.dts"

do_compile() {
    mkimage -A arm64 -O linux -T script -C none -d "${WORKDIR}/autoselect-dtb.txt" boot.scr
    dtc -I dts -O dtb -o devboard-cirrus8.dtb ${WORKDIR}/devboard-cirrus8.dts
    dtc -I dts -O dtb -o devboard-cirrus16.dtb ${WORKDIR}/devboard-cirrus16.dts
    dtc -I dts -O dtb -o devboard-cirrus32.dtb ${WORKDIR}/devboard-cirrus32.dts
}

do_install() {
    install -d ${D}/boot/
    install -m 0644 boot.scr ${D}/boot/
    install -m 0644 devboard-cirrus8.dtb ${D}/boot/
    install -m 0644 devboard-cirrus16.dtb ${D}/boot/
    install -m 0644 devboard-cirrus32.dtb ${D}/boot/
}

FILES:${PN} = "/boot/*"

I am aware that this is not good practice. Now I am confused, should I create multiple dtsi to suit each configuration then compile multiple dtb then install it in /boot/ or should I use device tree overlay ?

答案1

得分: 3

这取决于使用情况。DTSI用于开发人员,而DTO用于最终用户。

因此,如果您正在为某些客户开发一个“平台”,比如树莓派(RPi),或者在某些情况下,某人需要非常频繁地更改功能(集成商、服务人员),您应该优先选择DTO,让最终用户决定他们需要哪些节点。

对于您作为开发者,或者在您的DTB已经是最终版本的情况下(例如,一些设备已经从工厂发布,不再打算重新配置),我建议使用DTSI,带有定义。

如果您想在启动时选择要加载的DTB,我认为这完全取决于您 - 是使用基本DTB的DTO,还是不使用DTO的不同DTB。

注意:

为了避免编译和反编译循环,您可以使用cpp(C预处理器)来摆脱所有类似于DTSI的内容:

CPP_FLAGS := -nostdinc -I $(INCLUDE) -undef -x assembler-with-cpp
$(TARGET_PP): $(TARGET_DTS)
    cpp $(CPP_FLAGS) $(TARGET_DTS) $(TARGET_PP)

然后,您将获得$(TARGET_PP)文件,其中包含您的整个DTS及所有包含的内容(但仍然不包括未分组的节点)。

英文:

It depends on use case. DTSI's are for developers while DTO's are for end-users.

So if you are working on a "platform" for some customers, like RPi or cases when someone needs to change functionality (integrators, service staff) very frequently - you should prefer DTO's to let end-users decide what nodes they need.

For you as for developer, or in case your DTB is final (for example - some device which is released form factory and not intended to be reconfigured anymore) I would suggest use DTSI's, with defines.

If you want to select DTB to load at boot time, I think it's all up to you - to use DTO's with base DTB or to use different DTB's w/o DTO's.

NB

To omit compiling-decompiling cycle you can use cpp (C Preprocessor) to get rid of all DTSI's like that:

CPP_FLAGS	:= -nostdinc -I $(INCLUDE) -undef -x assembler-with-cpp     
$(TARGET_PP): $(TARGET_DTS)
    	cpp $(CPP_FLAGS) $(TARGET_DTS) $(TARGET_PP)

and you'll get $(TARGET_PP) file which will contain your whole DTS with all includes (but still with not grouped nodes).

huangapple
  • 本文由 发表于 2023年6月12日 19:17:10
  • 转载请务必保留本文链接:https://go.coder-hub.com/76456130.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定