[Task]: Convert recent (2024.01+) u-boot null-patches into `dt/` and `defconfig/` bare patches

[rpardini]

Task description

The Armbian patching utility supports adding files directly instead of requiring null-patches (patches that add complete files). Null-patches are unwieldy, forcing developers to generate patches for no reason.

We have such setup for many kernels, but also for the vendor rk35xx u-boot, as can be seen in patch/u-boot/legacy/u-boot-radxa-rk35xx/0000.patching_config.yaml (and patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig and patch/u-boot/legacy/u-boot-radxa-rk35xx/dt folders).

Let's replicate this setup (1 .yaml configuration file and 2 folders, one for DTS and one for defconfig) so we can get rid of null patches for the mainline u-boot as well.

Let's begin with the most recent u-boot (v2025.01) and work our way back; that way when new contributions begin they've a good example to follow.

[github-actions[bot]]

Jira ticket: AR-2599

[The-going]

Let's begin with the most recent u-boot (v2025.01) and work our way back

This version already uses a mechanism for synchronizing DTB files with the kernel repository.

u-boot> cat dts/upstream/README 
This tree contains device tree definitions extracted from the Linux
kernel source tree. It is synced regularly with mainline Linux.

Type "make help" for a list of build targets.

u-boot> ls dts/upstream/src/
arc  arm  arm64  loongarch  mips  nios2  openrisc  powerpc  riscv  sh  x86  xtensa

u-boot> ls dts/upstream/src/arm64/allwinner/sun50i-h618-*
dts/upstream/src/arm64/allwinner/sun50i-h618-bananapi-m4-berry.dts
.....

I just put my target DTB from the core here. No changes to the Makefile are required.

The configuration file for the board can also be simply copied.

I get the impression that developers want to switch to this mechanism in the future. I approve of your initiative. Thank you.

[rpardini]

This version already uses a mechanism for synchronizing DTB files with the kernel repository

That's different, u-boot moved some boards to using OF_UPSTREAM -- they pull device trees from https://web.git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git via git subtree -- that is a repo that is auto-generated from the main kernel repo but only contains DT files. Still, u-boot developers needs to pull the subtree explicitly (see this commit for example). This avoids the classic copy/paste from kernel to u-boot that used to happen, but mostly affects upstream u-boot development, not us.

Here, I am proposing to avoid null-patches (of which there are dozens in the 2024.x folders) and use the directories like is done for that one vendor u-boot -- that affects Armbian development directly, and should lower the barrier to entry for new folks who have a working DT+defconfig but need to create a null-patch so that Armbian accepts it.

[The-going]

Here, I am proposing to avoid null-patches (of which there are dozens in the 2024.x folders) and use the directories like is done for that one vendor u-boot -- that affects Armbian development directly, and should lower the barrier to entry for new folks who have a working DT+defconfig but need to create a null-patch so that Armbian accepts it.

This is ambiguous to me. Properly written documentation can help a new user. He may be a very experienced user, but he has no idea that files are simply being copied.

I perfectly understand what you want to do. https://github.com/armbian/build/issues/7912#issuecomment-2759960738

I just have a question about where the files will eventually be added. Or what mechanism is new or old to be used for them when compiling?

---

That's different, u-boot moved some boards to using OF_UPSTREAM

A little bit wrong. This is a new mechanism for compiling a device tree. In order for the compilation to take place, we need to add (copy two files). The configuration file and the device tree file. The configuration file should contain:

+CONFIG_DEFAULT_DEVICE_TREE="allwinner/sun50i-h618-bananapi-m4-berry"
+CONFIG_OF_UPSTREAM=y

The old mechanism assumes:

CONFIG_DEFAULT_DEVICE_TREE="sun50i-h618-bananapi-m4-berry"

Without vendor's name.

[The-going]

doc/develop/devicetree/control.rst#configuration

Good. I agree that this mechanism is for developers. But I liked him.

[rpardini]

I just have a question about where the files will eventually be added. Or what mechanism is new or old to be used for them when compiling?

• Same mechanism currently being used for patch/u-boot/legacy/u-boot-radxa-rk35xx
• patch/u-boot/legacy/u-boot-radxa-rk35xx/0000.patching_config.yaml configures the patching, what comes from where and where they are put
• everything else from regular patching (eg, board_xxx folders with regular patches, etc) still applies

See in action: ./compile.sh uboot BOARD=nanopi-m6 BRANCH=vendor ARTIFACT_IGNORE_CACHE=yes https://paste.armbian.com/ziberasoce

[rpardini]

So for example for bananapim4berry in v2025.01 what would happen:

• board_bananapim4berry/0002-dts-upstream-sun50i-h616-add-emac1-node-pinctrl-pins.patch: kept, no changes.

• board_bananapim4berry/0004-u-boot-v2025-DEBUG-sunxi-mmc-fix-logik.patch: kept, no changes.

• board_bananapim4berry/0005-h616-THS-workaround.patch: kept, no changes.

• board_bananapim4berry/0006-h616-GPU-enable.-Magic-register.patch: kept, no changes.

• board_bananapim4berry/0001-u-boot-configs-Add-sun50i-h618-bananapi-m4berry-defc.patch: disappears. contents go directly to defconfig/bananapi_m4_berry_defconfig (bare, not a patch)

• board_bananapim4berry/0003-dts-upstream-arm64-Add-sun50i-h618-bananapi-m4-berry.patch: disappears. contents go to dt/allwinner/sun50i-h618-bananapi-m4-berry.dts (bare, not a patch)

[The-going]

So for example for bananapim4berry in v2025.01 what would happen:

Well. We copy this file to one place. board_bananapim4berry/defconfig/bananapi_m4_berry_defconfig -> u-boot/v2025.01/configs/

We can copy the dt/allwinner/sun50i-h618-bananapi-m4-berry.dts file to two different locations.

If the configuration file contains

CONFIG_DEFAULT_DEVICE_TREE="allwinner/sun50i-h618-bananapi-m4-berry"
CONFIG_OF_UPSTREAM=y

the location of the DTS file should be u-boot/v2025.01/dts/upstream/src/arm64/allwinner/sun50i-h618-bananapi-m4-berry.dts

otherwise, his location is here u-boot/v2025.01/arch/arm/dts/sun50i-h618-bananapi-m4-berry.dts and we have to make changes to the Makefile. u-boot/v2025.01/arch/arm/dts/Makefile

In fact, the translation may be inaccurate and we may understand what is written in the documentation differently. On first reading, I realized that the maintainers of the repository recommended that developers add new devices using the OF_UPSTREAM mechanism. I added a new board using this method and tested it. I liked it.

[rpardini]

I don't have any intention of supporting both OF_UPSTREAM and the old way. If we need to support the old way then just keep using patches for that specific board, such is life.

[The-going]

Information for reflection. This is what will be included in v2025.04 https://github.com/u-boot/u-boot/commit/73cbb3baa6ae26dc8693feb449f48a535292e7e5 https://github.com/u-boot/u-boot/commit/08d65024e0e833d705d0d7ecfb9216206ed81b41 https://github.com/u-boot/u-boot/commit/dc2dd2de0f782860de886dcb9d545e73668c9007

[rpardini]

I don't have any intention of supporting both OF_UPSTREAM and the old way. If we need to support the old way then just keep using patches for that specific board

scratch that. I think I found a decent way, see 0000.patching_config.yaml in https://github.com/armbian/build/pull/8739:

• u-boot: v2025.10: prepare 0000.patching_config.yaml for null-patch-free u-boot
• this maps copying files from dirs in the patch directory directly to the u-boot tree, without any .patch required:
  • defconfig -> configs (useful for all)
  • dt_uboot -> arch/arm/dts (useful for most; use for xx-u-boot.dtsi or stuff without CONFIG_OF_UPSTREAM)
  • dt_upstream_rockchip -> dts/upstream/src/arm64/rockchip (useful for Rockchip boards)

This way, we can do both OF_UPSTREAM and the old way, just by using different folders ( dt_upstream_rockchip for Rockchip boards, dt_uboot for .dtsi's and non-OF_UPSTREAM stuff).