[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]

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.
#7912 (comment)

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
u-boot/u-boot@73cbb3b
u-boot/u-boot@08d6502
u-boot/u-boot@dc2dd2d