[Buildroot] [PATCH v1 1/3] configs/zynqmp_zcu102_defconfig: bump to Xilinx 2022.2

[Frager, Neal]

Hi Luca,

> This patch bumps the zynqmp_zcu102_defconfig to Xilinx release 2022.2.
> 
> Xilinx 2022.2 includes:
> - U-Boot 2022.01 bug fixes
> - Linux bump to Linux 5.15.36 with bug fixes
> - TF-A 2.6 bug fixes
> - PMUFW bug fixes
> 
> Signed-off-by: Neal Frager <neal.frager at amd.com>
> ---
>  configs/zynqmp_zcu102_defconfig | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/configs/zynqmp_zcu102_defconfig 
> b/configs/zynqmp_zcu102_defconfig index e27dfdb6c9..6047d4299c 100644
> --- a/configs/zynqmp_zcu102_defconfig
> +++ b/configs/zynqmp_zcu102_defconfig
> @@ -5,7 +5,7 @@ BR2_ROOTFS_POST_IMAGE_SCRIPT="board/zynqmp/post-image.sh"
>  BR2_ROOTFS_POST_SCRIPT_ARGS="ttyPS0,115200 mmcblk0p2"
>  BR2_LINUX_KERNEL=y
>  BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
> -BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,linux-xlnx,xlnx_rebase_v5.15_LTS_2022.1)/xlnx_rebase_v5.15_LTS_2022.1.tar.gz"
> +BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,linux-xlnx,xlnx_rebase_v5.15_LTS_2022.2)/xlnx_rebase_v5.15_LTS_2022.2.tar.gz"
>  BR2_LINUX_KERNEL_DEFCONFIG="xilinx_zynqmp"
>  BR2_LINUX_KERNEL_DTS_SUPPORT=y
>  BR2_LINUX_KERNEL_INTREE_DTS_NAME="xilinx/zynqmp-zcu102-rev1.0"
> @@ -15,13 +15,13 @@ BR2_TARGET_ROOTFS_EXT2_4=y  # 
> BR2_TARGET_ROOTFS_TAR is not set  BR2_TARGET_ARM_TRUSTED_FIRMWARE=y  
> BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_TARBALL=y
> -BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,arm-trusted-firmware,xlnx_rebase_v2.6_2022.1)/xlnx_rebase_v2.6_2022.1.tar.gz"
> +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,arm-trusted-firmware,xlnx_rebase_v2.6_2022.2)/xlnx_rebase_v2.6_2022.2.tar.gz"
>  BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="zynqmp"
>  BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31_UBOOT=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_v2022.01_2022.1)/xlnx_rebase_v2022.01_2022.1.tar.gz"
> +BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,u-boot-xlnx,xlnx_rebase_v2022.01_2022.2)/xlnx_rebase_v2022.01_2022.2.tar.gz"
>  BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynqmp_virt"
>  BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynqmp-zcu102-rev1.0"
>  BR2_TARGET_UBOOT_NEEDS_DTC=y
> @@ -29,7 +29,7 @@ BR2_TARGET_UBOOT_NEEDS_OPENSSL=y  
> BR2_TARGET_UBOOT_SPL=y  BR2_TARGET_UBOOT_SPL_NAME="spl/boot.bin"
>  BR2_TARGET_UBOOT_ZYNQMP=y
> -BR2_TARGET_UBOOT_ZYNQMP_PMUFW="https://github.com/Xilinx/ubuntu-firmware/raw/v2022.1_22.04_1/xlnx-firmware/zcu102/zcu102_pmufw.elf"
> +BR2_TARGET_UBOOT_ZYNQMP_PMUFW="https://github.com/nealfrager/buildroot-firmware/raw/v2022.2/zcu102/zcu102_pmufw.elf"

> It would be nice to stay on Xilinx official firmwares, but there seem
> to be no 2022.2 firmwares now on the Xilinx repo after Vivado 2022.2
> has been released more than 1 month ago.

I completely agree.  I am in an ongoing discussion within AMD regarding these firmware binaries, and my hope is that an official location will be maintained starting with 2023.1.
The firmware repo will cover both zynqmp and versal families.

Once the official location is available, I will be moving the buildroot zynqmp and versal support over to the Xilinx github and deprecating my github.

> One option would be to keep on using a 2022.1 pmufw and upgrade the
> other components. Do you think that would work? I think nowadays the
> interface provided by the PMUFW is quite stable, isn't it?

Yes, we can do this as a temporary solution for the zcu102 and zcu106.  The 2022.1 pmufw does work with the other 2022.2 images.

Unfortunately, the kv260 is already using my github since it is not available anywhere on the Xilinx github yet.

> Should there be good motivations to upgrade to PMUFW 2022.2, let's do
> it with your repo of course.

The only motivation is to have a defconfig where all the components are the same release version.
Functionally, it is not required.

Best regards,
Neal Frager
AMD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 15722 bytes
Desc: not available
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20221129/27d67234/attachment-0001.bin>