Message ID | 20240522161338.1278400-1-brandon.maier@collins.com |
---|---|
State | Deferred, archived |
Headers | show |
Series | configs/versal_vck190_defconfig: add hashes | expand |
Hi Brandon, > Enable BR2_DOWNLOAD_FORCE_CHECK_HASHES > Signed-off-by: Brandon Maier <brandon.maier@collins.com> Thank you for this patch. It looks like we need to do this for all of the configs/zynq* and configs/zynqmp* defconfigs as well. My only concern is that this patch conflicts with the following patch set which is still waiting for additional review. The patch set below changes the versal-firmware package from one that downloads pre-built binaries to a version which builds the binaries from source. If the patch set below gets applied first, then the hash for the versal-firmware-xilinx_v2023.2.tar.gz file will be wrong. https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 Could we apply this patch set first, and then go through and add all the correct hashes for the zynq, zynqmp and versal defconfigs? Best regards, Neal Frager AMD
Hello Neal, > My only concern is that this patch conflicts with the following patch set which is still waiting for additional review. The patch set below changes the versal-firmware package from one that downloads pre-built binaries to a version which builds the binaries from source. If the patch set below gets applied first, then the hash for the versal-firmware-xilinx_v2023.2.tar.gz file will be wrong. > > https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 > > Could we apply this patch set first, and then go through and add all the correct hashes for the zynq, zynqmp and versal defconfigs? I'm for that approach, I will decline this patch. Please CC me when the zynqmp-firmware series is applied, and I will spin hashes for the Xilinx boards. Thanks, Brandon
Hello Brandon, > My only concern is that this patch conflicts with the following patch set which is still waiting for additional review. The patch set below changes the versal-firmware package from one that downloads pre-built binaries to a version which builds the binaries from source. If the patch set below gets applied first, then the hash for the versal-firmware-xilinx_v2023.2.tar.gz file will be wrong. > > https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 > > Could we apply this patch set first, and then go through and add all the correct hashes for the zynq, zynqmp and versal defconfigs? > I'm for that approach, I will decline this patch. Please CC me when the zynqmp-firmware series is applied, and I will spin hashes for the Xilinx boards. If you would like, you could already submit patches adding the hashes for the 4 zynq7000 defconfigs. None of these boards have pending firmware patches. zynq_microzed_defconfig zynq_zc702_defconfig zynq_zc706_defconfig zynq_zed_defconfig Thank you for your support! Best regards, Neal Frager AMD
Hello Brandon, > My only concern is that this patch conflicts with the following patch set which is still waiting for additional review. The patch set below changes the versal-firmware package from one that downloads pre-built binaries to a version which builds the binaries from source. If the patch set below gets applied first, then the hash for the versal-firmware-xilinx_v2023.2.tar.gz file will be wrong. > > https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 > > Could we apply this patch set first, and then go through and add all the correct hashes for the zynq, zynqmp and versal defconfigs? > I'm for that approach, I will decline this patch. Please CC me when the zynqmp-firmware series is applied, and I will spin hashes for the Xilinx boards. I was hoping that the zynqmp-firmware and versal-firmware patches would be accepted before the Xilinx 2024.1 release, but that does not appear to be the case. I will be submitting patches to bump the zynqmp and versal defconfigs to the Xilinx 2024.1 release this week. If you want, you can add the hashes right after. I will then update the zynqmp-firmware and versal-firmware patch set to be applied on top of the 2024.1 defconfigs with the hash check. Ok for you? Best regards, Neal Frager AMD
Hello Brandon, Peter, > My only concern is that this patch conflicts with the following patch set which is still waiting for additional review. The patch set below changes the versal-firmware package from one that downloads pre-built binaries to a version which builds the binaries from source. If the patch set below gets applied first, then the hash for the versal-firmware-xilinx_v2023.2.tar.gz file will be wrong. > > https://patchwork.ozlabs.org/project/buildroot/list/?series=397588 > > Could we apply this patch set first, and then go through and add all the correct hashes for the zynq, zynqmp and versal defconfigs? > I'm for that approach, I will decline this patch. Please CC me when the zynqmp-firmware series is applied, and I will spin hashes for the Xilinx boards. > I was hoping that the zynqmp-firmware and versal-firmware patches would be > accepted before the Xilinx 2024.1 release, but that does not appear to be the > case. > I will be submitting patches to bump the zynqmp and versal defconfigs to the > Xilinx 2024.1 release this week. If you want, you can add the hashes right > after. > I will then update the zynqmp-firmware and versal-firmware patch set to be > applied on top of the 2024.1 defconfigs with the hash check. > Ok for you? I have another thought on the subject of the hashes. All of the Xilinx hashes will be the same regardless of whether it is a zynq, zynqmp or versal board. However, sometimes, we may have actual patches that only apply to a single family, like the ATF v2.8 patches currently in the tree. In order to avoid duplicating the same .hash files 3 times, what do you think about creating a board/xilinx/patches directory for the hash files? This way all the hashes can be common for zynq, zynqmp and versal and they can each still have their own board/<family>/patches directory for family specific patches. Assuming you are ok with this, would you like to already submit a patch to migrate the zynq board hashes to the board/xilinx/patches directory? Best regards, Neal Frager AMD
Hi Neal > I have another thought on the subject of the hashes. All of the Xilinx hashes > will be the same regardless of whether it is a zynq, zynqmp or versal board. > > However, sometimes, we may have actual patches that only apply to a single > family, like the ATF v2.8 patches currently in the tree. > > In order to avoid duplicating the same .hash files 3 times, what do you think > about creating a board/xilinx/patches directory for the hash files? This way > all the hashes can be common for zynq, zynqmp and versal and they can each > still have their own board/<family>/patches directory for family specific > patches. I was using the ./utils/add-custom-hashes script to generate the hash files. That script truncates and writes each hash to the last patch directory in BR2_GLOBAL_PATCH_DIR. So, this would work if the board/Xilinx/patches directory is last in the list, and all the boards share the same versions. > > Assuming you are ok with this, would you like to already submit a patch to > migrate the zynq board hashes to the board/xilinx/patches directory? Looks like you did :) > > Best regards, > Neal Frager > AMD Thanks, Brandon Maier
Hi Brandon, > I have another thought on the subject of the hashes. All of the Xilinx hashes > will be the same regardless of whether it is a zynq, zynqmp or versal board. > > However, sometimes, we may have actual patches that only apply to a single > family, like the ATF v2.8 patches currently in the tree. > > In order to avoid duplicating the same .hash files 3 times, what do you think > about creating a board/xilinx/patches directory for the hash files? This way > all the hashes can be common for zynq, zynqmp and versal and they can each > still have their own board/<family>/patches directory for family specific > patches. > I was using the ./utils/add-custom-hashes script to generate the hash files. That > script truncates and writes each hash to the last patch directory in > BR2_GLOBAL_PATCH_DIR. So, this would work if the board/Xilinx/patches > directory is last in the list, and all the boards share the same versions. I do not believe the ./board/xilinx/patches directory ever existed before, so the ./utils/add-custom-hashes script would not find that directory. Are you ok with my idea of creating this directory and putting the hashes for all the Xilinx boards in the same place? Best regards, Neal Frager AMD
> -----Original Message----- > From: Frager, Neal <neal.frager@amd.com> > Sent: Monday, June 3, 2024 8:01 AM > To: Maier, Brandon L Collins <Brandon.Maier@collins.com>; > buildroot@buildroot.org; 'Peter Korsgaard' <peter@korsgaard.com> > Cc: luca.ceresoli@bootlin.com > Subject: [External] RE: [PATCH] configs/versal_vck190_defconfig: add hashes > > Hi Brandon, > > > I have another thought on the subject of the hashes. All of the Xilinx hashes > > will be the same regardless of whether it is a zynq, zynqmp or versal board. > > > > However, sometimes, we may have actual patches that only apply to a single > > family, like the ATF v2.8 patches currently in the tree. > > > > In order to avoid duplicating the same .hash files 3 times, what do you think > > about creating a board/xilinx/patches directory for the hash files? This way > > all the hashes can be common for zynq, zynqmp and versal and they can > each > > still have their own board/<family>/patches directory for family specific > > patches. > > > I was using the ./utils/add-custom-hashes script to generate the hash files. > That > > script truncates and writes each hash to the last patch directory in > > BR2_GLOBAL_PATCH_DIR. So, this would work if the board/Xilinx/patches > > directory is last in the list, and all the boards share the same versions. > > I do not believe the ./board/xilinx/patches directory ever existed before, so > the ./utils/add-custom-hashes script would not find that directory. That is correct. I'm just stating if we add a board/xilinx/patches, it should go last in the BR2_GLOBAL_PATCH_DIR. That does not matter for the Zynq boards, as they are dropping board/zynq/patches/. But will for zynqmp which will have board/zynqmp/patches and board/Xilinx/patches. > > Are you ok with my idea of creating this directory and putting the hashes for > all the Xilinx boards in the same place? I like this idea. However, I'm not a maintainer so the final decision is not up to me ;) > > Best regards, > Neal Frager > AMD
diff --git a/.checkpackageignore b/.checkpackageignore index 0ddf9effda..24314ee2aa 100644 --- a/.checkpackageignore +++ b/.checkpackageignore @@ -380,7 +380,6 @@ configs/ts4900_defconfig lib_defconfig.ForceCheckHash configs/ts5500_defconfig lib_defconfig.ForceCheckHash configs/ts7680_defconfig lib_defconfig.ForceCheckHash configs/uevm5432_defconfig lib_defconfig.ForceCheckHash -configs/versal_vck190_defconfig lib_defconfig.ForceCheckHash configs/visionfive_defconfig lib_defconfig.ForceCheckHash configs/wandboard_defconfig lib_defconfig.ForceCheckHash configs/warp7_defconfig lib_defconfig.ForceCheckHash diff --git a/board/versal/patches/arm-trusted-firmware/arm-trusted-firmware.hash b/board/versal/patches/arm-trusted-firmware/arm-trusted-firmware.hash new file mode 100644 index 0000000000..fc0245e519 --- /dev/null +++ b/board/versal/patches/arm-trusted-firmware/arm-trusted-firmware.hash @@ -0,0 +1,2 @@ +# Locally computed: +sha256 fb15878cf8d656c8e048369ac6eab8e0771633a4a935964cde234979805248fa xlnx_rebase_v2.8_2023.2.tar.gz diff --git a/board/versal/patches/linux-headers/linux-headers.hash b/board/versal/patches/linux-headers/linux-headers.hash new file mode 100644 index 0000000000..19e1df5ee1 --- /dev/null +++ b/board/versal/patches/linux-headers/linux-headers.hash @@ -0,0 +1,2 @@ +# Locally calculated +sha256 ab7c238394032c1c300bd6cbe0081bcf95af6020b276f29bd7eb1b6458be1e55 xlnx_rebase_v6.1_LTS_2023.2.tar.gz diff --git a/board/versal/patches/linux/linux.hash b/board/versal/patches/linux/linux.hash new file mode 100644 index 0000000000..19e1df5ee1 --- /dev/null +++ b/board/versal/patches/linux/linux.hash @@ -0,0 +1,2 @@ +# Locally calculated +sha256 ab7c238394032c1c300bd6cbe0081bcf95af6020b276f29bd7eb1b6458be1e55 xlnx_rebase_v6.1_LTS_2023.2.tar.gz diff --git a/board/versal/patches/uboot/uboot.hash b/board/versal/patches/uboot/uboot.hash new file mode 100644 index 0000000000..4a6437b33c --- /dev/null +++ b/board/versal/patches/uboot/uboot.hash @@ -0,0 +1,2 @@ +# Locally computed +sha256 32a997a748697ff27e5e6db8edaff5ba893077214bc18b5267daff0b708dab53 xlnx_rebase_v2023.01_2023.2.tar.gz diff --git a/board/versal/patches/versal-firmware/versal-firmware.hash b/board/versal/patches/versal-firmware/versal-firmware.hash new file mode 100644 index 0000000000..5c63d345fd --- /dev/null +++ b/board/versal/patches/versal-firmware/versal-firmware.hash @@ -0,0 +1,2 @@ +# Locally calculated +sha256 76d5b07417de5a26acd028d6e39ae5effbbcf4f5e1b8a89ba0dda8ef02b7a3f1 versal-firmware-xilinx_v2023.2.tar.gz diff --git a/configs/versal_vck190_defconfig b/configs/versal_vck190_defconfig index 8561b6641a..80a26f2675 100644 --- a/configs/versal_vck190_defconfig +++ b/configs/versal_vck190_defconfig @@ -1,6 +1,7 @@ BR2_aarch64=y BR2_cortex_a72=y BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_1=y +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y BR2_ROOTFS_POST_BUILD_SCRIPT="board/versal/post-build.sh" BR2_ROOTFS_POST_IMAGE_SCRIPT="board/versal/post-image.sh" BR2_ROOTFS_POST_SCRIPT_ARGS="ttyAMA0,115200 mmcblk0p2"
Enable BR2_DOWNLOAD_FORCE_CHECK_HASHES Signed-off-by: Brandon Maier <brandon.maier@collins.com> --- .checkpackageignore | 1 - .../patches/arm-trusted-firmware/arm-trusted-firmware.hash | 2 ++ board/versal/patches/linux-headers/linux-headers.hash | 2 ++ board/versal/patches/linux/linux.hash | 2 ++ board/versal/patches/uboot/uboot.hash | 2 ++ board/versal/patches/versal-firmware/versal-firmware.hash | 2 ++ configs/versal_vck190_defconfig | 1 + 7 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 board/versal/patches/arm-trusted-firmware/arm-trusted-firmware.hash create mode 100644 board/versal/patches/linux-headers/linux-headers.hash create mode 100644 board/versal/patches/linux/linux.hash create mode 100644 board/versal/patches/uboot/uboot.hash create mode 100644 board/versal/patches/versal-firmware/versal-firmware.hash