Device tree overlay compiling: the general workflow, and hints

[tpou]

I am currently attempting to compile a device tree overlay, in connection with an OPi Zero 2. 

 

But my questions here are of rather general nature (with regards to DT compiling), so I posted it here.

 

-------

 

Goal: Creating a DT overlay to enable certain hardware currently not working on the board: 
wifi and HDMI output. Alternatively, compiling a "full" .dtb file for the board, replacing 
the one currently used during boot.

 

For completeness: In the below I experimented starting from the Armbian_22.08.7_Orangepizero2_bullseye_edge_5.19.16.img.xz
image, 406585908 bytes. uname -a: "Linux orangepizero2 5.19.16-sunxi64 #22.08.6 SMP Tue Oct 18 06:56:22 UTC 2022 aarch64 GNU/Linux"
Boot-up (at times shaky), UART and USB (via type A socket) is working with this image.

 

-------

 

I have tried to assemble a dts file, to be made into an overlay, from snippets 
seen at https://github.com/jernejsk/linux-1/commit/e7222b1f0dfde22a3b60de7f3add6599fd942e84

 

But this runs into errors, as references are missing, in this case for example "reg_aldo2". I can look at the complete file, 
https://github.com/jernejsk/linux-1/blob/e7222b1f0dfde22a3b60de7f3add6599fd942e84/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
and see that it includes #include "sun50i-h616.dtsi", which I can copy from the tree. Further I can make additional code additions that all missing
references are resolvable.

 

Nevertheless, even then errors (or to be exact: warnings) remain that look as if the resulting .dtbo will not be functional. 

 

Thus: What is the typical workflow in compiling overlays? 

 

1. How much of existing code needs to be included? (I also tried, as alternative to above, to decompile 
  the existing dtb and use it as included file in my compilation - is this a reasonable avenue?)
  
2. What are negligible warnings? 

 

3. If I compiled something resulting in an erroreous .dtbo, could it be harmful to the hardware? (Or asked differently: tinkering with what parts of the device tree is potentially damaging to the board?)

 

-------

Example warnings:

sun50i-h616.dtsi:109.6-1009.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
  also defined at orangepi-zero2_wifi_and_hdmi.dts:61.13-81.11
sun50i-h616.dtsi:375.21-395.5: Warning (avoid_unnecessary_addr_size): /soc/mmc@4021000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
  also defined at orangepi-zero2_wifi_and_hdmi.dts:63.25-79.15

 

Thanks to the knowledgable.

 

Edited December 29, 2022 by tpou
title was wrong

[going]

10 минут назад, tpou сказал:

Or asked differently: tinkering with what parts of the device tree is potentially damaging to the board?

The chip operates at a voltage of 1.1V, and you have applied a voltage of 1.8V or vice versa, you have not applied enough voltage of 0.9V.
You are trying to change the mode of operation of the chip and write a value to the register, but the register is mixed up and something else will change.

 

You need to learn how to properly read the user documentation, the schematic diagram of the device. And learn how to compare the documentation and the device tree file.

 

Sorry, the question is general - the answer is general.

[atone]

Quote

Goal: Creating a DT overlay to enable certain hardware currently not working on the board: 

If I understood correctly, this is the purpose of user-overlays. But user-overlays are only a temp fix and should only be used if the normal way (armbian-config/armbianEnv.txt/overlays) doesn't work.

 

Quote

Alternatively, compiling a "full" .dtb file

Why would you do that? Doing so the community wouldn't benefit from your fixes/optimizations and vice versa.