Message ID | 20231018111357.2898095-1-neal.frager@amd.com |
---|---|
State | Accepted |
Headers | show |
Series | [v2,1/1] configs/zynq_zc702_defconfig: new defconfig | expand |
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.
diff --git a/DEVELOPERS b/DEVELOPERS index 57015e245e..e4729010fe 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -2193,6 +2193,7 @@ F: board/versal/ F: board/zynq/ F: board/zynqmp/ F: configs/versal_vck190_defconfig +F: configs/zynq_zc702_defconfig F: configs/zynq_zc706_defconfig F: configs/zynqmp_kria_kv260_defconfig F: configs/zynqmp_zcu102_defconfig diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig new file mode 100644 index 0000000000..e85285a832 --- /dev/null +++ b/configs/zynq_zc702_defconfig @@ -0,0 +1,33 @@ +BR2_arm=y +BR2_cortex_a9=y +BR2_ARM_ENABLE_NEON=y +BR2_ARM_ENABLE_VFP=y +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_1=y +BR2_ROOTFS_POST_BUILD_SCRIPT="board/zynq/post-build.sh" +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/zynq/post-image.sh" +BR2_LINUX_KERNEL=y +BR2_LINUX_KERNEL_CUSTOM_TARBALL=y +BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,linux-xlnx,xlnx_rebase_v6.1_LTS_2023.2)/xlnx_rebase_v6.1_LTS_2023.2.tar.gz" +BR2_LINUX_KERNEL_DEFCONFIG="xilinx_zynq" +BR2_LINUX_KERNEL_UIMAGE=y +BR2_LINUX_KERNEL_UIMAGE_LOADADDR="0x8000" +BR2_LINUX_KERNEL_DTS_SUPPORT=y +BR2_LINUX_KERNEL_INTREE_DTS_NAME="zynq-zc702" +BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y +BR2_TARGET_ROOTFS_EXT2=y +BR2_TARGET_ROOTFS_EXT2_4=y +BR2_TARGET_UBOOT=y +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y +BR2_TARGET_UBOOT_CUSTOM_TARBALL=y +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" +BR2_TARGET_UBOOT_NEEDS_DTC=y +BR2_TARGET_UBOOT_NEEDS_OPENSSL=y +BR2_TARGET_UBOOT_NEEDS_GNUTLS=y +BR2_TARGET_UBOOT_FORMAT_IMG=y +BR2_TARGET_UBOOT_SPL=y +BR2_TARGET_UBOOT_SPL_NAME="spl/boot.bin" +BR2_PACKAGE_HOST_DOSFSTOOLS=y +BR2_PACKAGE_HOST_GENIMAGE=y +BR2_PACKAGE_HOST_MTOOLS=y
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