[v2,1/1] configs/zynq_zc702_defconfig: new defconfig

This patch adds support for Xilinx Zynq ZC702 starter kit.

ZC702 features can be found here:
https://www.xilinx.com/products/boards-and-kits/ek-z7-zc702-g.html

Signed-off-by: Neal Frager <neal.frager@amd.com>
---
V1->V2:
 - corrected commit message to zynq_zc702_defconfig
---
 DEVELOPERS                   |  1 +
 configs/zynq_zc702_defconfig | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+)
 create mode 100644 configs/zynq_zc702_defconfig

Hi Neal,

On Wed, 18 Oct 2023 12:13:57 +0100
Neal Frager <neal.frager@amd.com> wrote:

> This patch adds support for Xilinx Zynq ZC702 starter kit.
> 
> ZC702 features can be found here:
> https://www.xilinx.com/products/boards-and-kits/ek-z7-zc702-g.html
> 
> Signed-off-by: Neal Frager <neal.frager@amd.com>

This patch looks very clean, however I have a question. The zc702
config you are adding is identical to the existing one for the zc706
except for the device tree:

-BR2_LINUX_KERNEL_INTREE_DTS_NAME="zynq-zc706"
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="zynq-zc702"
-BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc706"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc702"

However, exactly because it is so similar, I am not sure about the
usefulness of having a large number of (from the build system
perspective) very similar configurations, where a user can simply 'sed
s/zc706/zc702/' to work on a different board.

I'm wondering whether we could have a unique defconfig that builds
artifacts able to boot on both boards. This probably build down to
whether the hardware components involved in the boot process are
similar enough to allow U-Boot to boot with the same embedded device
tree for both boards. At a quick glance the two dts files appear very
similar.

Luca

Hi Luca,

> This patch adds support for Xilinx Zynq ZC702 starter kit.
> 
> ZC702 features can be found here:
> https://www.xilinx.com/products/boards-and-kits/ek-z7-zc702-g.html
> 
> Signed-off-by: Neal Frager <neal.frager@amd.com>

> This patch looks very clean, however I have a question. The zc702 config you are adding is identical to the existing one for the zc706 except for the device tree:

> -BR2_LINUX_KERNEL_INTREE_DTS_NAME="zynq-zc706"
> +BR2_LINUX_KERNEL_INTREE_DTS_NAME="zynq-zc702"
> -BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc706"
> +BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc702"

> However, exactly because it is so similar, I am not sure about the usefulness of having a large number of (from the build system
> perspective) very similar configurations, where a user can simply 'sed s/zc706/zc702/' to work on a different board.

> I'm wondering whether we could have a unique defconfig that builds artifacts able to boot on both boards. This probably build down to whether the hardware components involved in the boot process are similar enough to allow U-Boot to boot with the same embedded device tree for both boards. At a quick glance the two dts files appear very similar.

I do understand your point.  From this perspective, we can say the same thing about the zynq_zed_defconfig and the zynq_microzed_defconfig as well.  For all 4 of these zynq boards, the DTS definition is all that changes from one defconfig to another.  And in all 4 cases, the only differences in the dts files are things like gpio LEDs, switches and whether or not there is a CAN peripheral on board.  So you could potentially boot the same images across these boards.  You would just lose a peripheral or two that is included in one dts file but not another.

My reasoning for creating the zynq_zc702_defconfig is the same as with the zynqmp_kr260_defconfig.  I would like for buildroot to be a clear alternative to yocto.  This is my primary motivation as an AMD employee.  At the moment, if a new user wants to run a yocto or petalinux build for any AMD Xilinx evaluation board, they simply need to use that board's configuration as all of them are included with the meta-xilinx releases.

I get that knowledgeable buildroot users can simply 'sed s/zc706/zc702/' to work on a different board.  But what about the new user who does not know that changing the dts is all that needs to be done?  It may be hard to believe, but I have received questions about certain boards like the zc702 or the zcu104 which do not have an explicit buildroot defconfig, and some users interpret that to mean the board is not supported.  But in reality, you and I both know that it takes very little to support another zynq or zynqmp evaluation board now that all the board support is already included in buildroot.  The new user does not know this.

Even internally at AMD, some people think buildroot does not have support for our products.  @Peter can vouch for this as he has personally been involved in getting AMD technical support, and received the feedback that we need to duplicate the problem using the "petalinux flow" even though buildroot and petalinux use the exact same u-boot and Linux release tags.

If we compare buildroot with yocto/petalinux, we can see how many boards are supported "out of the box" by yocto/petalinux without having a buildroot defconfig.  Below is a nice github containing all of the yocto/petalinux pre-built binaries.

https://github.com/Xilinx/soc-prebuilt-firmware/tree/xlnx_rel_v2023.2

You can see that buildroot only includes the following defconfigs:
zynq: 1 out 2 defconfigs
zynqmp: 2 out of 5 defconfigs
kria: 1 out of 3 defconfigs
versal: 1 out of 5 defconfigs

In many cases, I think this can be a blocker for many new users when deciding to go the buildroot or yocto path.

If having too many defconfigs is an issue for buildroot, I would propose we drop support of some boards like the zynq_qmtech board, and include more of the boards that are still actively supported.

Would the community be ok with the following list of AMD defconfigs being included in buildroot?  I believe the following list includes the most popular boards on our side.  I know 10 defconfigs is a lot, but I have no problem with maintaining them, and it would definitely give buildroot the appearance of being an officially supported platform for new users.  Half of these defconfigs are already included in buildroot.

zynq_zc702
zynq_zc706
zynqmp_zcu102
zynqmp_zcu104
zynqmp_zcu106
kria_kd240
kria_kr260
kria_kv260
versal_vck190
versal_vmk180

What do you think?

Best regards,
Neal Frager
AMD

Hello Neal,

On Tue, 31 Oct 2023 12:12:47 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:

> I do understand your point.  From this perspective, we can say the
> same thing about the zynq_zed_defconfig and the
> zynq_microzed_defconfig as well.  For all 4 of these zynq boards, the
> DTS definition is all that changes from one defconfig to another.
> And in all 4 cases, the only differences in the dts files are things
> like gpio LEDs, switches and whether or not there is a CAN peripheral
> on board.  So you could potentially boot the same images across these
> boards.  You would just lose a peripheral or two that is included in
> one dts file but not another.

I think the discussion is not being specific enough here, so let me
provide some more background.

If the only differences between the zc706 and zc702 defconfigs is the
Linux kernel Device Tree (and I insist on Linux kernel Device Tree, not
Device Tree for the bootloaders/firmware), then you can have a single
configuration that builds multiple Device Trees, and the bootloader
selects the right one depending on which board we're booting on. This
is exactly what happens in beaglebone_defconfig:

BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-evm am335x-bone am335x-boneblack am335x-bonegreen am335x-evmsk am335x-boneblue am335x-boneblack-wireless am335x-bonegreen-wireless"

We build multiple Linux kernel Device Trees, and the U-Boot bootloader
detects which board we boot on, and selects the right Device Tree.

If you are in this situation, then yes we want a single defconfig.

However, if the bootloader needs to be different on ZCU702 vs ZCU706,
and this difference is not detected at boot-time/run-time, but is
handled as a different build-time configuration, then you have no other
choice but to have 2 separate defconfigs.

Now I see this:

+BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,u-boot-xlnx,xlnx_rebase_v2023.01_2023.2)/xlnx_rebase_v2023.01_2023.2.tar.gz"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynq_virt"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc702"

in the ZCU702 defconfig, vs.

BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,u-boot-xlnx,xlnx_rebase_v2023.01_2023.2)/xlnx_rebase_v2023.01_2023.2.tar.gz"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynq_virt"
BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynq-zc706"

Which means you need to have a different build-time configuration of
U-Boot, and therefore it's not possible to support both platforms in
the same Buildroot defconfig.

Best regards,

Thomas

Hi Thomas, Luca,

> Hello Neal,
> 
> On Tue, 31 Oct 2023 12:12:47 +0000
> "Frager, Neal" <neal.frager@amd.com> wrote:
> 
>> I do understand your point.  From this perspective, we can say the 
>> same thing about the zynq_zed_defconfig and the 
>> zynq_microzed_defconfig as well.  For all 4 of these zynq boards, the 
>> DTS definition is all that changes from one defconfig to another.
>> And in all 4 cases, the only differences in the dts files are things 
>> like gpio LEDs, switches and whether or not there is a CAN peripheral 
>> on board.  So you could potentially boot the same images across these 
>> boards.  You would just lose a peripheral or two that is included in 
>> one dts file but not another.
> 
> I think the discussion is not being specific enough here, so let me 
> provide some more background.
> 
> If the only differences between the zc706 and zc702 defconfigs is the 
> Linux kernel Device Tree (and I insist on Linux kernel Device Tree, 
> not Device Tree for the bootloaders/firmware), then you can have a 
> single configuration that builds multiple Device Trees, and the 
> bootloader selects the right one depending on which board we're 
> booting on. This is exactly what happens in beaglebone_defconfig:
> 
> BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-evm am335x-bone am335x-boneblack am335x-bonegreen am335x-evmsk am335x-boneblue am335x-boneblack-wireless am335x-bonegreen-wireless"
> 
> We build multiple Linux kernel Device Trees, and the U-Boot bootloader 
> detects which board we boot on, and selects the right Device Tree.
> 
> If you are in this situation, then yes we want a single defconfig.
> 
> However, if the bootloader needs to be different on ZCU702 vs ZCU706, 
> and this difference is not detected at boot-time/run-time, but is 
> handled as a different build-time configuration, then you have no 
> other choice but to have 2 separate defconfigs.

> I have never really get DTB U-Boot resection to work on these "old" boards.
> It can be done and would work fine but the issue is that information about board is saved in eeprom which is user accessible without any RO protection.
> I have seen a lot of these boards with empty eeproms that having detection mechanism based on it is not a good idea.
> Another option would be use information about silicon version to differentiate between them but at the end of day it is not worth to spend time on it.

> Thanks,
> Michal

In addition to not being able to detect which board we are running on, the zynq and zynqmp dts
definitions are used to select the ps7_init or psu_init included by the spl for the target board as well.
Some boards do not share the same ddr memory, such as the zcu106 revA and the zcu102 rev 1.0.
So even if we were to build all of the device trees, we still need to know which board we are building
for in order to have an spl which will be able to boot the target.

Unfortunately, I do not see how to support the different boards outside of having an individual
defconfig for each board.

The remaining question is just a matter of how many zynq, zynqmp and versal defconfigs is the
right amount for buildroot?  I would like to be able to support the following 11 boards, if it would be
ok for the buildroot community.  5 of these 11 are already included in buildroot.

zynq_zc702
zynq_zc706
zynqmp_zcu102
zynqmp_zcu104
zynqmp_zcu106
zynqmp_kria_kd240
zynqmp_kria_kr260
zynqmp_kria_kv260
versal_vck190
versal_vek280 (coming next year)
versal_vmk180

In exchange, I would be ok with dropping the zynq_qmtech board and possibly one of the zynq_zed
boards.

Best regards,
Neal Frager
AMD

>>>>> "Frager," == Frager, Neal <neal.frager@amd.com> writes:

Hi,

 > The remaining question is just a matter of how many zynq, zynqmp and
 > versal defconfigs is the right amount for buildroot?  I would like to
 > be able to support the following 11 boards, if it would be ok for the
 > buildroot community.  5 of these 11 are already included in
 > buildroot.

 > zynq_zc702
 > zynq_zc706
 > zynqmp_zcu102
 > zynqmp_zcu104
 > zynqmp_zcu106
 > zynqmp_kria_kd240
 > zynqmp_kria_kr260
 > zynqmp_kria_kv260
 > versal_vck190
 > versal_vek280 (coming next year)
 > versal_vmk180

 > In exchange, I would be ok with dropping the zynq_qmtech board and
 > possibly one of the zynq_zed
 > boards.

I think the main issue with a lot of defconfigs is maintaining them (but
you already do that) and the CI overhead from building all of them.

I guess we could come up with some logic to skip some of the zynq*
defconfigs from the Gitlab CI setup. Romain, any good ideas?

Hi,

On Tue, 31 Oct 2023 17:39:36 +0100
Peter Korsgaard <peter@korsgaard.com> wrote:

> >>>>> "Frager," == Frager, Neal <neal.frager@amd.com> writes:  
> 
> Hi,
> 
>  > The remaining question is just a matter of how many zynq, zynqmp and
>  > versal defconfigs is the right amount for buildroot?  I would like to
>  > be able to support the following 11 boards, if it would be ok for the
>  > buildroot community.  5 of these 11 are already included in
>  > buildroot.  
> 
>  > zynq_zc702
>  > zynq_zc706
>  > zynqmp_zcu102
>  > zynqmp_zcu104
>  > zynqmp_zcu106
>  > zynqmp_kria_kd240
>  > zynqmp_kria_kr260
>  > zynqmp_kria_kv260
>  > versal_vck190
>  > versal_vek280 (coming next year)
>  > versal_vmk180  
> 
>  > In exchange, I would be ok with dropping the zynq_qmtech board and
>  > possibly one of the zynq_zed
>  > boards.  
> 
> I think the main issue with a lot of defconfigs is maintaining them (but
> you already do that) and the CI overhead from building all of them.
> 
> I guess we could come up with some logic to skip some of the zynq*
> defconfigs from the Gitlab CI setup. Romain, any good ideas?

After the discussion it seems quite clear that the patch is useful, and
the CI aspects can perhaps be sorted out, so:

Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

>>>>> "Luca" == Luca Ceresoli <luca.ceresoli@bootlin.com> writes:

 > Hi,
 > On Tue, 31 Oct 2023 17:39:36 +0100
 > Peter Korsgaard <peter@korsgaard.com> wrote:

 >> >>>>> "Frager," == Frager, Neal <neal.frager@amd.com> writes:  
 >> 
 >> Hi,
 >> 
 >> > The remaining question is just a matter of how many zynq, zynqmp and
 >> > versal defconfigs is the right amount for buildroot?  I would like to
 >> > be able to support the following 11 boards, if it would be ok for the
 >> > buildroot community.  5 of these 11 are already included in
 >> > buildroot.  
 >> 
 >> > zynq_zc702
 >> > zynq_zc706
 >> > zynqmp_zcu102
 >> > zynqmp_zcu104
 >> > zynqmp_zcu106
 >> > zynqmp_kria_kd240
 >> > zynqmp_kria_kr260
 >> > zynqmp_kria_kv260
 >> > versal_vck190
 >> > versal_vek280 (coming next year)
 >> > versal_vmk180  
 >> 
 >> > In exchange, I would be ok with dropping the zynq_qmtech board and
 >> > possibly one of the zynq_zed
 >> > boards.  
 >> 
 >> I think the main issue with a lot of defconfigs is maintaining them (but
 >> you already do that) and the CI overhead from building all of them.
 >> 
 >> I guess we could come up with some logic to skip some of the zynq*
 >> defconfigs from the Gitlab CI setup. Romain, any good ideas?

 > After the discussion it seems quite clear that the patch is useful, and
 > the CI aspects can perhaps be sorted out, so:

 > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Committed, thanks.