configs/versal_vck190_defconfig: add hashes

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

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