| Message ID | 20240603115212.184529-1-neal.frager@amd.com |
|---|---|
| State | Accepted |
| Delegated to: | Yann E. MORIN |
| Headers | show |
| Series | [v1,1/3] configs/zynqmp_zcu102_defconfig: bump to xilinx-v2024.1 | expand |
Hello Neal, On Mon, 3 Jun 2024 12:52:10 +0100 Neal Frager <neal.frager@amd.com> wrote: > This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes > the following updates: > > - Linux v6.6.10 > - U-Boot v2024.01 > - ATF v2.10 > - PMUFW xilinx-v2024.1 > > Signed-off-by: Neal Frager <neal.frager@amd.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> > -BR2_GLOBAL_PATCH_DIR="board/zynqmp/patches" Along with the Kria KV260 + KR260 series you sent in the same day today, this patch dir will become used only by KD260. Do you have such an upgrade for KD260 in your pipeline? If you do, then it's fine, we can keep this directory until then. Luca
Hello Luca, > This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes > the following updates: > > - Linux v6.6.10 > - U-Boot v2024.01 > - ATF v2.10 > - PMUFW xilinx-v2024.1 > > Signed-off-by: Neal Frager <neal.frager@amd.com> > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Thank you for the review! > -BR2_GLOBAL_PATCH_DIR="board/zynqmp/patches" > Along with the Kria KV260 + KR260 series you sent in the same day > today, this patch dir will become used only by KD260. Do you have such > an upgrade for KD260 in your pipeline? > If you do, then it's fine, we can keep this directory until then. Yes, I am bumping the kd240 as well. Once this happens, we can remove the ./board/zynqmp/patches directory along with the two ATF v2.8 patches. We will also be able to remove the ./board/zynqmp/kria/uboot.fragment file. I delayed bumping the kd240 because there is a board specific patch required that I need to re-work for version 2024.1. I should be able to release the kd240 bump to xilinx_v2024.1 tomorrow. After all boards have been bumped to xilinx_v2024.1, I would like to add the rest of the hashes to ./board/xilinx/patches and get all xilinx board configs compliant. Best regards, Neal Frager AMD
Hi Yann, > This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes > the following updates: > > - Linux v6.6.10 > - U-Boot v2024.01 > - ATF v2.10 > - PMUFW xilinx-v2024.1 > > Signed-off-by: Neal Frager <neal.frager@amd.com> > Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> > -BR2_GLOBAL_PATCH_DIR="board/zynqmp/patches" Since you are processing so many patches today, would you mind applying this set to the next branch as well? Best regards, Neal Frager AMD
Neal, Al, On 2024-06-03 12:52 +0100, Neal Frager via buildroot spake thusly: > This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes > the following updates: > > - Linux v6.6.10 > - U-Boot v2024.01 > - ATF v2.10 > - PMUFW xilinx-v2024.1 > > Signed-off-by: Neal Frager <neal.frager@amd.com> I've now applied this series of three patches to next, thanks. However, while applying, I noticed that those boards do not have BR2_DOWNLOAD_FORCE_CHECK_HASHES=y (so my post-apply hooks triggered). I wanted to add that and point to the newly introduced board/xilinx/patches, but that will not be possible. Indeed, those defconfig use BR2_TARGET_UBOOT_ZYNQMP_PMUFW, and that is added to the extra downloads, and we would need a hash for that file. But the filename is unversioned, which means that we can't differentiate between pmufw.elf from yesterday, the one from today, and the one from tomorrow. So, when arbitrary downloads of unversioned files are done in a defconfig (or in a package enabled by tht defconfig), we will not be able to force checking the hashes... Of course, this is not an issue directly introduced by this series, which is why I applied it. Still, for this case, I wonder if that would not be better to intriduce a new package (e.g. boot/xilinx-soc-prebuilt-firmware/ ) which would be properly versioned, and on which uboot would depend when BR2_TARGET_UBOOT_ZYNQMP=y. Luca, do you remember the details why a package was not introduced bacj when you added the ZYNQMP PMU support? Regards, Yann E. MORIN.
Hi Yann, > This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes > the following updates: > > - Linux v6.6.10 > - U-Boot v2024.01 > - ATF v2.10 > - PMUFW xilinx-v2024.1 > > Signed-off-by: Neal Frager <neal.frager@amd.com> > I've now applied this series of three patches to next, thanks. > However, while applying, I noticed that those boards do not have > BR2_DOWNLOAD_FORCE_CHECK_HASHES=y (so my post-apply hooks triggered). > I wanted to add that and point to the newly introduced > board/xilinx/patches, but that will not be possible. > Indeed, those defconfig use BR2_TARGET_UBOOT_ZYNQMP_PMUFW, and that is > added to the extra downloads, and we would need a hash for that file. > But the filename is unversioned, which means that we can't differentiate > between pmufw.elf from yesterday, the one from today, and the one from > tomorrow. > So, when arbitrary downloads of unversioned files are done in a > defconfig (or in a package enabled by tht defconfig), we will not be > able to force checking the hashes... > Of course, this is not an issue directly introduced by this series, > which is why I applied it. > Still, for this case, I wonder if that would not be better to intriduce > a new package (e.g. boot/xilinx-soc-prebuilt-firmware/ ) which would be > properly versioned, and on which uboot would depend when > BR2_TARGET_UBOOT_ZYNQMP=y. > Luca, do you remember the details why a package was not introduced bacj > when you added the ZYNQMP PMU support? Another solution could be to apply patches 1-3 of the following patch set which create a zynqmp-firmware package that will build the pmufw from source that has a hash associated since it is using the Xilinx/embeddedsw repo. https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 I have to re-do this patch set now that we have bumped to 2024.1, but I think applying this zynqmp-firmware solution would be my preferred method of solving this issue. What do you think? Best regards, Neal Frager AMD
Hi Yann, > This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes > the following updates: > > - Linux v6.6.10 > - U-Boot v2024.01 > - ATF v2.10 > - PMUFW xilinx-v2024.1 > > Signed-off-by: Neal Frager <neal.frager@amd.com> > I've now applied this series of three patches to next, thanks. > However, while applying, I noticed that those boards do not have > BR2_DOWNLOAD_FORCE_CHECK_HASHES=y (so my post-apply hooks triggered). > I wanted to add that and point to the newly introduced > board/xilinx/patches, but that will not be possible. > Indeed, those defconfig use BR2_TARGET_UBOOT_ZYNQMP_PMUFW, and that is > added to the extra downloads, and we would need a hash for that file. > But the filename is unversioned, which means that we can't differentiate > between pmufw.elf from yesterday, the one from today, and the one from > tomorrow. > So, when arbitrary downloads of unversioned files are done in a > defconfig (or in a package enabled by tht defconfig), we will not be > able to force checking the hashes... > Of course, this is not an issue directly introduced by this series, > which is why I applied it. > Still, for this case, I wonder if that would not be better to intriduce > a new package (e.g. boot/xilinx-soc-prebuilt-firmware/ ) which would be > properly versioned, and on which uboot would depend when > BR2_TARGET_UBOOT_ZYNQMP=y. > Luca, do you remember the details why a package was not introduced bacj > when you added the ZYNQMP PMU support? > Another solution could be to apply patches 1-3 of the following patch set which > create a zynqmp-firmware package that will build the pmufw from source that has > a hash associated since it is using the Xilinx/embeddedsw repo. > https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 > I have to re-do this patch set now that we have bumped to 2024.1, but I think > applying this zynqmp-firmware solution would be my preferred method of solving > this issue. > What do you think? By the way, is this still allowed? Perhaps we could use it to skip the hash check when the u-boot.mk downloads a pre-built pmufw.elf/bin? BR_NO_CHECK_HASH_FOR += $(UBOOT_ZYNQMP_PMUFW) Best regards, Neal Frager AMD
Neal, All, On 2024-06-06 16:02 +0000, Frager, Neal spake thusly: > > But the filename is unversioned, which means that we can't differentiate > > between pmufw.elf from yesterday, the one from today, and the one from > > tomorrow. [--SNIP--] > By the way, is this still allowed? Perhaps we could use it to skip the hash > check when the u-boot.mk downloads a pre-built pmufw.elf/bin? > > BR_NO_CHECK_HASH_FOR += $(UBOOT_ZYNQMP_PMUFW) When FORCE_CHECK_HASHES=y, BR_NO_CHECK_HASH_FOR is not actioned, see package/pkg-download@115. Regards, Yann E. MORIN.
On 06/06/2024 17:25, Yann E. MORIN wrote: > However, while applying, I noticed that those boards do not have > BR2_DOWNLOAD_FORCE_CHECK_HASHES=y (so my post-apply hooks triggered). > > I wanted to add that and point to the newly introduced > board/xilinx/patches, but that will not be possible. > > Indeed, those defconfig use BR2_TARGET_UBOOT_ZYNQMP_PMUFW, and that is > added to the extra downloads, and we would need a hash for that file. > > But the filename is unversioned, which means that we can't differentiate > between pmufw.elf from yesterday, the one from today, and the one from > tomorrow. > > So, when arbitrary downloads of unversioned files are done in a > defconfig (or in a package enabled by tht defconfig), we will not be > able to force checking the hashes... We could re-introduce the "none" hash method... But that is perhaps going in circles... Regards, Arnout
> -----Original Message----- > From: Arnout Vandecappelle <arnout@mind.be> > Sent: Thursday, June 6, 2024 1:09 PM > To: Yann E. MORIN <yann.morin.1998@free.fr>; Neal Frager > <neal.frager@amd.com> > Cc: ibai.erkiaga-elorza@amd.com; luca.ceresoli@bootlin.com; Maier, Brandon L > Collins <Brandon.Maier@collins.com>; thomas.petazzoni@bootlin.com; > buildroot@buildroot.org; michal.simek@amd.com > Subject: [External] Re: [Buildroot] [PATCH v1 1/3] > configs/zynqmp_zcu102_defconfig: bump to xilinx-v2024.1 > > > > On 06/06/2024 17:25, Yann E. MORIN wrote: > > However, while applying, I noticed that those boards do not have > > BR2_DOWNLOAD_FORCE_CHECK_HASHES=y (so my post-apply hooks > triggered). > > > > I wanted to add that and point to the newly introduced > > board/xilinx/patches, but that will not be possible. > > > > Indeed, those defconfig use BR2_TARGET_UBOOT_ZYNQMP_PMUFW, and that > is > > added to the extra downloads, and we would need a hash for that file. > > > > But the filename is unversioned, which means that we can't differentiate > > between pmufw.elf from yesterday, the one from today, and the one from > > tomorrow. > > > > So, when arbitrary downloads of unversioned files are done in a > > defconfig (or in a package enabled by tht defconfig), we will not be > > able to force checking the hashes... > > We could re-introduce the "none" hash method... But that is perhaps going in > circles... What about the Yocto approach of appending the hash to the URI? E.g. BR2_TARGET_UBOOT_ZYNQMP_PMUFW=" https://github.com/Xilinx/soc-prebuilt-firmware/raw/xilinx_v2023.2/zcu102-zynqmp/pmufw.elf;sha256=1234..." Then pulling the hash off during download. That could also allow for checking other custom download types like applying the Linux RT_PREEMPT patches with LINUX_PATCHES. > > Regards, > Arnout
Hi Brandon, > -----Original Message----- > From: Arnout Vandecappelle <arnout@mind.be> > Sent: Thursday, June 6, 2024 1:09 PM > To: Yann E. MORIN <yann.morin.1998@free.fr>; Neal Frager > <neal.frager@amd.com> > Cc: ibai.erkiaga-elorza@amd.com; luca.ceresoli@bootlin.com; Maier, Brandon L > Collins <Brandon.Maier@collins.com>; thomas.petazzoni@bootlin.com; > buildroot@buildroot.org; michal.simek@amd.com > Subject: [External] Re: [Buildroot] [PATCH v1 1/3] > configs/zynqmp_zcu102_defconfig: bump to xilinx-v2024.1 > > > > On 06/06/2024 17:25, Yann E. MORIN wrote: > > However, while applying, I noticed that those boards do not have > > BR2_DOWNLOAD_FORCE_CHECK_HASHES=y (so my post-apply hooks > triggered). > > > > I wanted to add that and point to the newly introduced > > board/xilinx/patches, but that will not be possible. > > > > Indeed, those defconfig use BR2_TARGET_UBOOT_ZYNQMP_PMUFW, and that > is > > added to the extra downloads, and we would need a hash for that file. > > > > But the filename is unversioned, which means that we can't differentiate > > between pmufw.elf from yesterday, the one from today, and the one from > > tomorrow. > > > > So, when arbitrary downloads of unversioned files are done in a > > defconfig (or in a package enabled by tht defconfig), we will not be > > able to force checking the hashes... > > We could re-introduce the "none" hash method... But that is perhaps going in > circles... > What about the Yocto approach of appending the hash to the URI? E.g. > BR2_TARGET_UBOOT_ZYNQMP_PMUFW=" https://github.com/Xilinx/soc-prebuilt-firmware/raw/xilinx_v2023.2/zcu102-zynqmp/pmufw.elf;sha256=1234..." > Then pulling the hash off during download. That could also allow for checking other custom download types like applying the Linux RT_PREEMPT patches with LINUX_PATCHES. I like this idea as it solves the issue with the new versal-firmware as well. https://patchwork.ozlabs.org/project/buildroot/patch/20240304074140.1537910-4-neal.frager@amd.com/ BR2_TARGET_VERSAL_FIRMWARE_PDI="https://github.com/Xilinx/soc-prebuilt-firmware/raw/xilinx_v2023.2/vck190-versal/vpl_gen_fixed.pdi;sha256=1234..." Perhaps we can add this to the EXTRA_DOWNLOADS package variable? Best regards, Neal Frager AMD
Hi Yann, On Thu, 6 Jun 2024 17:25:11 +0200 "Yann E. MORIN" <yann.morin.1998@free.fr> wrote: > Still, for this case, I wonder if that would not be better to intriduce > a new package (e.g. boot/xilinx-soc-prebuilt-firmware/ ) which would be > properly versioned, and on which uboot would depend when > BR2_TARGET_UBOOT_ZYNQMP=y. > > Luca, do you remember the details why a package was not introduced bacj > when you added the ZYNQMP PMU support? Apologies for the delay. I think the answer is just "it didn't look like necessary at that time"... :-/ But if you ask me now, I think introducing a package would be a good idea. Building the pmufw within Buildroot using Neal's patches is a very good option, but I suspect build would have a relevant increase, so keeping the option to download a prebuilt binary would be good. Luca
Hi Yann, Luca, Brandon, > Still, for this case, I wonder if that would not be better to intriduce > a new package (e.g. boot/xilinx-soc-prebuilt-firmware/ ) which would be > properly versioned, and on which uboot would depend when > BR2_TARGET_UBOOT_ZYNQMP=y. > > Luca, do you remember the details why a package was not introduced bacj > when you added the ZYNQMP PMU support? > Apologies for the delay. > I think the answer is just "it didn't look like necessary at that > time"... :-/ > But if you ask me now, I think introducing a package would be a good > idea. > Building the pmufw within Buildroot using Neal's patches is a very good > option, but I suspect build would have a relevant increase, so keeping > the option to download a prebuilt binary would be good. I have an idea for solving the hashing issue for both zynqmp and versal. I will put together a new patch set for submission in the next day or two. In the meantime, it would help me a lot to get the following patch reviewed and committed, so all the defconfigs are on 2024.1. The patch for the kd240 has been committed to u-boot now, so it only needs to remain for 2024.1 and it will be gone for 2024.2. https://patchwork.ozlabs.org/project/buildroot/patch/20240604085325.2073913-1-neal.frager@amd.com/ Committed to u-boot: https://patchwork.ozlabs.org/project/uboot/patch/20240604083854.2033917-1-neal.frager@amd.com/ Best regards, Neal Frager AMD
diff --git a/configs/zynqmp_zcu102_defconfig b/configs/zynqmp_zcu102_defconfig index c920093d8d..f40002f6d9 100644 --- a/configs/zynqmp_zcu102_defconfig +++ b/configs/zynqmp_zcu102_defconfig @@ -1,11 +1,11 @@ BR2_aarch64=y -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_1=y +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_6=y BR2_ROOTFS_POST_BUILD_SCRIPT="board/zynqmp/post-build.sh" 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_v6.1_LTS_2023.2)/xlnx_rebase_v6.1_LTS_2023.2.tar.gz" +BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,linux-xlnx,xlnx_rebase_v6.6_LTS_2024.1)/xlnx_rebase_v6.6_LTS_2024.1.tar.gz" BR2_LINUX_KERNEL_DEFCONFIG="xilinx" 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.8_2023.2)/xlnx_rebase_v2.8_2023.2.tar.gz" +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,arm-trusted-firmware,xlnx_rebase_v2.10_2024.1)/xlnx_rebase_v2.10_2024.1.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_v2023.01_2023.2)/xlnx_rebase_v2023.01_2023.2.tar.gz" +BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,u-boot-xlnx,xlnx_rebase_v2024.01_2024.1)/xlnx_rebase_v2024.01_2024.1.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 @@ -30,11 +30,10 @@ BR2_TARGET_UBOOT_NEEDS_GNUTLS=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/soc-prebuilt-firmware/raw/xilinx_v2023.2/zcu102-zynqmp/pmufw.elf" +BR2_TARGET_UBOOT_ZYNQMP_PMUFW="https://github.com/Xilinx/soc-prebuilt-firmware/raw/xilinx_v2024.1/zcu102-zynqmp/pmufw.elf" BR2_TARGET_UBOOT_ZYNQMP_PM_CFG="board/zynqmp/zcu102/pm_cfg_obj.c" BR2_TARGET_UBOOT_FORMAT_ITB=y BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y BR2_PACKAGE_HOST_DOSFSTOOLS=y BR2_PACKAGE_HOST_GENIMAGE=y BR2_PACKAGE_HOST_MTOOLS=y -BR2_GLOBAL_PATCH_DIR="board/zynqmp/patches"
This patch bumps the zynqmp_zcu102_defconfig to xilinx-v2024.1 which includes the following updates: - Linux v6.6.10 - U-Boot v2024.01 - ATF v2.10 - PMUFW xilinx-v2024.1 Signed-off-by: Neal Frager <neal.frager@amd.com> --- configs/zynqmp_zcu102_defconfig | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)