diff mbox series

[v3,1/2] arm64: dts: mt7986: add dtbs with applied overlays for bpi-r3

Message ID 20240608080530.9436-2-linux@fw-web.de (mailing list archive)
State New, archived
Headers show
Series rework bpi-r3 dts overlays and add SATA dtso | expand

Commit Message

Frank Wunderlich June 8, 2024, 8:05 a.m. UTC
From: Frank Wunderlich <frank-w@public-files.de>

Build devicetree binaries for testing overlays and providing users
full dtb without using overlays.

Suggested-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
https://lore.kernel.org/all/CAL_JsqK_3xxD0DFwipXO85P=q=EYjUdjE1_8g1MKtvw3vVzx5A@mail.gmail.com/
https://lore.kernel.org/all/CAL_JsqJSi=kJSix=f3787ULZnaCy_Y26Phdhy5y9fat_vkDuUw@mail.gmail.com/

v2:
make full dtbs multiline for better readability
---
 arch/arm64/boot/dts/mediatek/Makefile | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Comments

Frank Wunderlich June 26, 2024, 8:45 p.m. UTC | #1
any suggestions? hoping it does no laying around so long as v2

regards Frank


> Gesendet: Samstag, 08. Juni 2024 um 10:05 Uhr
> Von: "Frank Wunderlich" <linux@fw-web.de>
> An: "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Rob Herring" <robh@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Conor Dooley" <conor+dt@kernel.org>
> Cc: "Frank Wunderlich" <frank-w@public-files.de>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, "Daniel Golle" <daniel@makrotopia.org>, "Rob Herring" <robh+dt@kernel.org>
> Betreff: [PATCH v3 1/2] arm64: dts: mt7986: add dtbs with applied overlays for bpi-r3
>
> From: Frank Wunderlich <frank-w@public-files.de>
>
> Build devicetree binaries for testing overlays and providing users
> full dtb without using overlays.
>
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> https://lore.kernel.org/all/CAL_JsqK_3xxD0DFwipXO85P=q=EYjUdjE1_8g1MKtvw3vVzx5A@mail.gmail.com/
> https://lore.kernel.org/all/CAL_JsqJSi=kJSix=f3787ULZnaCy_Y26Phdhy5y9fat_vkDuUw@mail.gmail.com/
>
> v2:
> make full dtbs multiline for better readability
> ---
>  arch/arm64/boot/dts/mediatek/Makefile | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index 37b4ca3a87c9..0ec5b904d35d 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -15,6 +15,27 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nor.dtbo
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd.dtbo
> +mt7986a-bananapi-bpi-r3-emmc-nand-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
> +	mt7986a-bananapi-bpi-r3-nand.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nand.dtb
> +mt7986a-bananapi-bpi-r3-emmc-nor-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
> +	mt7986a-bananapi-bpi-r3-nor.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nor.dtb
> +mt7986a-bananapi-bpi-r3-sd-nand-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
> +	mt7986a-bananapi-bpi-r3-nand.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nand.dtb
> +mt7986a-bananapi-bpi-r3-sd-nor-dtbs := \
> +	mt7986a-bananapi-bpi-r3.dtb \
> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
> +	mt7986a-bananapi-bpi-r3-nor.dtbo
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nor.dtb
> +
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-rfb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986b-rfb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4.dtb
> --
> 2.34.1
>
>
AngeloGioacchino Del Regno June 27, 2024, 10:10 a.m. UTC | #2
Il 26/06/24 22:45, Frank Wunderlich ha scritto:
> any suggestions? hoping it does no laying around so long as v2
> 

So you're trying to just test that the overlay is valid and can actually be
overlaid to the base dts?

I'm not sure that this is the right/best way... and I honestly have no time
to check that *exactly right now*, even though that should be.

I have to be convinced of what I'm doing before applying patches, and I know
that this was sent a bit of time ago, but I really didn't have any time to
dig into that... let's see if for some miracle I can do that for this cycle
otherwise it's going to be the next one.

I mean no disrespect to Rob who suggested this change, but I still want to
check that on my own before picking it.

Sorry about the delays

Cheers,
Angelo


> regards Frank
> 
> 
>> Gesendet: Samstag, 08. Juni 2024 um 10:05 Uhr
>> Von: "Frank Wunderlich" <linux@fw-web.de>
>> An: "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Rob Herring" <robh@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Conor Dooley" <conor+dt@kernel.org>
>> Cc: "Frank Wunderlich" <frank-w@public-files.de>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, "Daniel Golle" <daniel@makrotopia.org>, "Rob Herring" <robh+dt@kernel.org>
>> Betreff: [PATCH v3 1/2] arm64: dts: mt7986: add dtbs with applied overlays for bpi-r3
>>
>> From: Frank Wunderlich <frank-w@public-files.de>
>>
>> Build devicetree binaries for testing overlays and providing users
>> full dtb without using overlays.
>>
>> Suggested-by: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
>> ---
>> https://lore.kernel.org/all/CAL_JsqK_3xxD0DFwipXO85P=q=EYjUdjE1_8g1MKtvw3vVzx5A@mail.gmail.com/
>> https://lore.kernel.org/all/CAL_JsqJSi=kJSix=f3787ULZnaCy_Y26Phdhy5y9fat_vkDuUw@mail.gmail.com/
>>
>> v2:
>> make full dtbs multiline for better readability
>> ---
>>   arch/arm64/boot/dts/mediatek/Makefile | 21 +++++++++++++++++++++
>>   1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
>> index 37b4ca3a87c9..0ec5b904d35d 100644
>> --- a/arch/arm64/boot/dts/mediatek/Makefile
>> +++ b/arch/arm64/boot/dts/mediatek/Makefile
>> @@ -15,6 +15,27 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nor.dtbo
>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd.dtbo
>> +mt7986a-bananapi-bpi-r3-emmc-nand-dtbs := \
>> +	mt7986a-bananapi-bpi-r3.dtb \
>> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
>> +	mt7986a-bananapi-bpi-r3-nand.dtbo
>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nand.dtb
>> +mt7986a-bananapi-bpi-r3-emmc-nor-dtbs := \
>> +	mt7986a-bananapi-bpi-r3.dtb \
>> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
>> +	mt7986a-bananapi-bpi-r3-nor.dtbo
>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nor.dtb
>> +mt7986a-bananapi-bpi-r3-sd-nand-dtbs := \
>> +	mt7986a-bananapi-bpi-r3.dtb \
>> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
>> +	mt7986a-bananapi-bpi-r3-nand.dtbo
>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nand.dtb
>> +mt7986a-bananapi-bpi-r3-sd-nor-dtbs := \
>> +	mt7986a-bananapi-bpi-r3.dtb \
>> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
>> +	mt7986a-bananapi-bpi-r3-nor.dtbo
>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nor.dtb
>> +
>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-rfb.dtb
>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986b-rfb.dtb
>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4.dtb
>> --
>> 2.34.1
>>
>>
Frank Wunderlich June 27, 2024, 10:28 a.m. UTC | #3
Am 27. Juni 2024 12:10:17 MESZ schrieb AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:
>Il 26/06/24 22:45, Frank Wunderlich ha scritto:
>> any suggestions? hoping it does no laying around so long as v2
>> 
>
>So you're trying to just test that the overlay is valid and can actually be
>overlaid to the base dts?
>
>I'm not sure that this is the right/best way... and I honestly have no time
>to check that *exactly right now*, even though that should be.
>
>I have to be convinced of what I'm doing before applying patches, and I know
>that this was sent a bit of time ago, but I really didn't have any time to
>dig into that... let's see if for some miracle I can do that for this cycle
>otherwise it's going to be the next one.
>
>I mean no disrespect to Rob who suggested this change, but I still want to
>check that on my own before picking it.
>

>> 
>> 
>>> Gesendet: Samstag, 08. Juni 2024 um 10:05 Uhr
>>> Von: "Frank Wunderlich" <linux@fw-web.de>

>>> Betreff: [PATCH v3 1/2] arm64: dts: mt7986: add dtbs with applied overlays for bpi-r3
>>> 
>>> From: Frank Wunderlich <frank-w@public-files.de>
>>> 
>>> Build devicetree binaries for testing overlays and providing users
>>> full dtb without using overlays.
>>> 
>>> Suggested-by: Rob Herring <robh+dt@kernel.org>
 https://lore.kernel.org/all/CAL_JsqK_3xxD0DFwipXO85P=q=EYjUdjE1_8g1MKtvw3vVzx5A@mail.gmail.com/
>>> https://lore.kernel.org/all/CAL_JsqJSi=kJSix=f3787ULZnaCy_Y26Phdhy5y9fat_vkDuUw@mail.gmail.com/
>>> 
>>> v2:
>>> make full dtbs multiline for better readability
>>> ---
>>>   arch/arm64/boot/dts/mediatek/Makefile | 21 +++++++++++++++++++++
>>>   1 file changed, 21 insertions(+)
>>> 
>>> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
>>> index 37b4ca3a87c9..0ec5b904d35d 100644
>>> --- a/arch/arm64/boot/dts/mediatek/Makefile
>>> +++ b/arch/arm64/boot/dts/mediatek/Makefile
>>> @@ -15,6 +15,27 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
>>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
>>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nor.dtbo
>>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd.dtbo
>>> +mt7986a-bananapi-bpi-r3-emmc-nand-dtbs := \
>>> +	mt7986a-bananapi-bpi-r3.dtb \
>>> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
>>> +	mt7986a-bananapi-bpi-r3-nand.dtbo
>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nand.dtb
>>> +mt7986a-bananapi-bpi-r3-emmc-nor-dtbs := \
>>> +	mt7986a-bananapi-bpi-r3.dtb \
>>> +	mt7986a-bananapi-bpi-r3-emmc.dtbo \
>>> +	mt7986a-bananapi-bpi-r3-nor.dtbo
>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nor.dtb
>>> +mt7986a-bananapi-bpi-r3-sd-nand-dtbs := \
>>> +	mt7986a-bananapi-bpi-r3.dtb \
>>> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
>>> +	mt7986a-bananapi-bpi-r3-nand.dtbo
>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nand.dtb
>>> +mt7986a-bananapi-bpi-r3-sd-nor-dtbs := \
>>> +	mt7986a-bananapi-bpi-r3.dtb \
>>> +	mt7986a-bananapi-bpi-r3-sd.dtbo \
>>> +	mt7986a-bananapi-bpi-r3-nor.dtbo
>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nor.dtb
>>> +
>>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-rfb.dtb
>>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986b-rfb.dtb
>>>   dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4.dtb
>>> --
>>> 2.34.1
>>> 
>>> 
>

Yes, 1st reason is to check if overlay can be applied to base dts (the part rob was requested). The second thing that was solved is that some users wanting a "full" dtb without the need to handle overlays in bootloader. Due to hardware design of the board there are 4 "full" dtb's.

So i adressed both in one Patch. I myself (and openwrt) still use the overlays and apply them after probing hardware in uboot...so for me it is not needed but requested from others. Current state was defined as broken by rob and for future additions (like mt7988/bpi-r4) we want to have a blueprint.

I hope you find time to look into it to have it solved soon and avoid discussions like the 2 links from commit message in future...then we have a reference for similar situations.


regards Frank
Leith Bade July 3, 2024, 11:34 p.m. UTC | #4
> Yes, 1st reason is to check if overlay can be applied to base dts (the part rob was requested). The second thing that was solved is that some users wanting a "full" dtb without the need to handle overlays in bootloader. Due to hardware design of the board there are 4 "full" dtb's.

I have been looking at using the "u-boot-update" package in Debian to
generate an extlinux.conf file so I can use the U-boot standard/distro
boot. This script seems to currently assume that you pick a single
.dtb file for the board, and then the user can put additional .dtbo
files in /boot/dtbo/ for any additional hardware the user has plugged
in.

So having a series of "merged" base files would be useful for this use case.

Thanks,
Leith Bade
Frank Wunderlich Nov. 6, 2024, 6:49 p.m. UTC | #5
Hi

any new state on this??

https://patchwork.kernel.org/project/linux-mediatek/patch/20240608080530.9436-2-linux@fw-web.de/

regards Frank
AngeloGioacchino Del Regno Nov. 27, 2024, 1:23 p.m. UTC | #6
Il 06/11/24 19:49, frank-w@public-files.de ha scritto:
> Hi
> 
> any new state on this??
> 
> https://patchwork.kernel.org/project/linux-mediatek/patch/20240608080530.9436-2-linux@fw-web.de/
> 
> regards Frank

I had a look at this one - and this is the situation:

  1. Your bootloader supports loading DTBO, so you can indeed use DTBOs
  2. Validation of the DTSO can still be done during kernel build without adding
     all of those possible X+Y+Z pre-joined DTBs
  3. What if your hardware had more than 20 possible configurations?
     Would you write 20 different Makefile entries? "sd+nand+nor",
     "sd+nand-withoutnor", "emmc+nand+nor", "emmc+nand-withoutnor",
     "emmc+sd+nor", "emmc+sd-withoutnor", "ufs+emmc", "ufs+emmc+sd",
     "ufs+sd+nor", "ufs+emmc-withoutnor", "ufs+sd-withoutnor", ......

Looks messy and unfeasible.

However, this is not a *global* no: I'm happy that your bootloader does support
loading DTBOs and, as far as I remember, even uses straps to vary the DTB(o) to
actually load - which is something proper and great... so it's a *no* for you,
but more than just a no, this is "why are you treating your proper bootflow
like it was a broken one?!?!" :-)

If anyone finds themselves in a situation in which there's no way to update a
bootloader (and that unfortunately happens more often than anyone would like
to see...) and in which the only way to apply DTBOs is to pre-overlay them
during the kernel build, then that's fine and I would (if nice and clean)
accept that.

But again, you're not in this kind of situation - and you're lucky that you're
dealing with a fully open device with a proper bootloader and bootflow: don't
ruin it like that!
Instead, if necessary, update the userspace tools that you're using to deal with
multiple DTBOs during system upgrades: that's the right thing to do at this point.

Cheers,
Angelo
Frank Wunderlich Nov. 27, 2024, 3:04 p.m. UTC | #7
Hi,

&gt; Gesendet: Mittwoch, 27. November 2024 um 14:23
&gt; Von: "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>
&gt; An: frank-w@public-files.de, robh+dt@kernel.org, matthias.bgg@gmail.com
&gt; CC: krzk+dt@kernel.org, conor+dt@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, daniel@makrotopia.org, linux@fw-web.de, leith@bade.nz
&gt; Betreff: Re: Aw: Re: Aw: [PATCH v3 1/2] arm64: dts: mt7986: add dtbs with applied overlays for bpi-r3
&gt;
&gt; Il 06/11/24 19:49, frank-w@public-files.de ha scritto:
&gt; &gt; Hi
&gt; &gt;
&gt; &gt; any new state on this??
&gt; &gt;
&gt; &gt; https://patchwork.kernel.org/project/linux-mediatek/patch/20240608080530.9436-2-linux@fw-web.de/
&gt; &gt;
&gt; &gt; regards Frank
&gt;
&gt; I had a look at this one - and this is the situation:
&gt;
&gt;   1. Your bootloader supports loading DTBO, so you can indeed use DTBOs
&gt;   2. Validation of the DTSO can still be done during kernel build without adding
&gt;      all of those possible X+Y+Z pre-joined DTBs
&gt;   3. What if your hardware had more than 20 possible configurations?
&gt;      Would you write 20 different Makefile entries? "sd+nand+nor",
&gt;      "sd+nand-withoutnor", "emmc+nand+nor", "emmc+nand-withoutnor",
&gt;      "emmc+sd+nor", "emmc+sd-withoutnor", "ufs+emmc", "ufs+emmc+sd",
&gt;      "ufs+sd+nor", "ufs+emmc-withoutnor", "ufs+sd-withoutnor", ......
&gt;
&gt; Looks messy and unfeasible.

right, if we add all possible combinations...that was my point on first round of this patch after robs suggestion. So you have same opinion :)

imho rob is afraid that dtso are not checked during build-time and this is noticed at runtime where it can be checked earlier.

maybe we can find a way in the middle (i tried it in this patch doing the full dtb only for the core functionality, not adding e.g. sata).

&gt; However, this is not a *global* no: I'm happy that your bootloader does support
&gt; loading DTBOs and, as far as I remember, even uses straps to vary the DTB(o) to
&gt; actually load - which is something proper and great... so it's a *no* for you,
&gt; but more than just a no, this is "why are you treating your proper bootflow
&gt; like it was a broken one?!?!" :-)

i still use the dtbos in a fit i created and build off-tree where i add the possible combinations like here as config options and add additional configs for e.g. sata to be combined by bootloader.

currently we use a "full dtb" in uboot where we can probe for emmc vs. sdcard (mmc partprobe) and the spi-device (nand/nor via "sf probe"). We can read the bootstrap pins defining the device from which board was booted, but this is only the half way for hw-detection.

&gt; If anyone finds themselves in a situation in which there's no way to update a
&gt; bootloader (and that unfortunately happens more often than anyone would like
&gt; to see...) and in which the only way to apply DTBOs is to pre-overlay them
&gt; during the kernel build, then that's fine and I would (if nice and clean)
&gt; accept that.
&gt;
&gt; But again, you're not in this kind of situation - and you're lucky that you're
&gt; dealing with a fully open device with a proper bootloader and bootflow: don't
&gt; ruin it like that!

the patch does not break ability to use the dtbos, it only adds second way to create fuill dtbs from them, that of course should not be done extensively....4 full dtbs are enough in my PoV and should not be exceeded.

&gt; Instead, if necessary, update the userspace tools that you're using to deal with
&gt; multiple DTBOs during system upgrades: that's the right thing to do at this point.

i simply replace/add the fit image which contains base dtb and all dtbo with config options ;)

&gt; Cheers,
&gt; Angelo

so i would resend the sata-patch alone when rc1 is out, right?

regards Frank</angelogioacchino.delregno@collabora.com>
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 37b4ca3a87c9..0ec5b904d35d 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -15,6 +15,27 @@  dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nand.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-nor.dtbo
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd.dtbo
+mt7986a-bananapi-bpi-r3-emmc-nand-dtbs := \
+	mt7986a-bananapi-bpi-r3.dtb \
+	mt7986a-bananapi-bpi-r3-emmc.dtbo \
+	mt7986a-bananapi-bpi-r3-nand.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nand.dtb
+mt7986a-bananapi-bpi-r3-emmc-nor-dtbs := \
+	mt7986a-bananapi-bpi-r3.dtb \
+	mt7986a-bananapi-bpi-r3-emmc.dtbo \
+	mt7986a-bananapi-bpi-r3-nor.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-emmc-nor.dtb
+mt7986a-bananapi-bpi-r3-sd-nand-dtbs := \
+	mt7986a-bananapi-bpi-r3.dtb \
+	mt7986a-bananapi-bpi-r3-sd.dtbo \
+	mt7986a-bananapi-bpi-r3-nand.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nand.dtb
+mt7986a-bananapi-bpi-r3-sd-nor-dtbs := \
+	mt7986a-bananapi-bpi-r3.dtb \
+	mt7986a-bananapi-bpi-r3-sd.dtbo \
+	mt7986a-bananapi-bpi-r3-nor.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-bananapi-bpi-r3-sd-nor.dtb
+
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986a-rfb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7986b-rfb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4.dtb