| Message ID | de1b8dbabd5ab7f20d7aac217ec4f5074d39f1da.1728462767.git.michal.simek@amd.com |
|---|---|
| State | RFC |
| Delegated to: | Simon Glass |
| Headers | show |
| Series | [RFC] zynqmp: Add binman description for SOM | expand |
Hi Michal, On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek@amd.com> wrote: > > There is necessary to do some steps to compose boot images. These steps > were in scripts in layers for a while. That's why introduce description via > binman to simplify wiring and remove all scripting around. > This should make sure that everybody is up2date with the latest versions. > > The first step is to create fit image with DTBs with descriptions in > configuration node which is written as regular expression to match all SOM > versions. > Description is there for k24 and k26 in spite of low level psu_init > configuration is different. The reason is that it goes to u-boot.itb image > which is the same for k24 and k26. > u-boot.itb is another image which is generated. It is normally generated > via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to > be deprecated. > FIT image by purpose is using 64bit addresses to have default option to > move images to high DDR (above 4GB). TF-A and TEE are optional components > but in the most cases TF-A is present all the time and TEE(OP-TEE) is used > by some configurations too. > > 3rd generated image is boot.bin with updated user field which contains > version number. This image can be used with updated Image Selector > which supports A/B update mechanisms with rollback protection. > > 4th image is image.bin which binary file which contains boot.bin and > u-boot.itb together and can be programmed via origin Image Selector. > This image can be also used for creating one capsule which contains both > boot images (in SPL boot flow). > > Signed-off-by: Michal Simek <michal.simek@amd.com> > --- > > Currently I have this for testing purpose only to find missing bits and > pieces in binman for cases I want to support. > > This patch depends on > https://lore.kernel.org/r/fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com > > --- > arch/arm/dts/Makefile | 1 + > arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ > arch/arm/mach-zynqmp/Kconfig | 17 ++ > configs/xilinx_zynqmp_kria_defconfig | 2 + > 4 files changed, 244 insertions(+) > create mode 100644 arch/arm/dts/zynqmp-som-binman.dts I'm pleased to see this. My only suggestion is to use '/bits/ 64' instead of the macros, for 64-bit values. [..] Regards, Simon
On 10/31/24 19:03, Simon Glass wrote: > Hi Michal, > > On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek@amd.com> wrote: >> >> There is necessary to do some steps to compose boot images. These steps >> were in scripts in layers for a while. That's why introduce description via >> binman to simplify wiring and remove all scripting around. >> This should make sure that everybody is up2date with the latest versions. >> >> The first step is to create fit image with DTBs with descriptions in >> configuration node which is written as regular expression to match all SOM >> versions. >> Description is there for k24 and k26 in spite of low level psu_init >> configuration is different. The reason is that it goes to u-boot.itb image >> which is the same for k24 and k26. >> u-boot.itb is another image which is generated. It is normally generated >> via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to >> be deprecated. >> FIT image by purpose is using 64bit addresses to have default option to >> move images to high DDR (above 4GB). TF-A and TEE are optional components >> but in the most cases TF-A is present all the time and TEE(OP-TEE) is used >> by some configurations too. >> >> 3rd generated image is boot.bin with updated user field which contains >> version number. This image can be used with updated Image Selector >> which supports A/B update mechanisms with rollback protection. >> >> 4th image is image.bin which binary file which contains boot.bin and >> u-boot.itb together and can be programmed via origin Image Selector. >> This image can be also used for creating one capsule which contains both >> boot images (in SPL boot flow). >> >> Signed-off-by: Michal Simek <michal.simek@amd.com> >> --- >> >> Currently I have this for testing purpose only to find missing bits and >> pieces in binman for cases I want to support. >> >> This patch depends on >> https://lore.kernel.org/r/fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com >> >> --- >> arch/arm/dts/Makefile | 1 + >> arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ >> arch/arm/mach-zynqmp/Kconfig | 17 ++ >> configs/xilinx_zynqmp_kria_defconfig | 2 + >> 4 files changed, 244 insertions(+) >> create mode 100644 arch/arm/dts/zynqmp-som-binman.dts > > I'm pleased to see this. My only suggestion is to use '/bits/ 64' > instead of the macros, for 64-bit values. When I was playing with it some time ago it didn't work but it works now that's why no issue with it. Thanks, Michal
Hi Simon, On 11/1/24 09:27, Michal Simek wrote: > > > On 10/31/24 19:03, Simon Glass wrote: >> Hi Michal, >> >> On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek@amd.com> wrote: >>> >>> There is necessary to do some steps to compose boot images. These steps >>> were in scripts in layers for a while. That's why introduce description via >>> binman to simplify wiring and remove all scripting around. >>> This should make sure that everybody is up2date with the latest versions. >>> >>> The first step is to create fit image with DTBs with descriptions in >>> configuration node which is written as regular expression to match all SOM >>> versions. >>> Description is there for k24 and k26 in spite of low level psu_init >>> configuration is different. The reason is that it goes to u-boot.itb image >>> which is the same for k24 and k26. >>> u-boot.itb is another image which is generated. It is normally generated >>> via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to >>> be deprecated. >>> FIT image by purpose is using 64bit addresses to have default option to >>> move images to high DDR (above 4GB). TF-A and TEE are optional components >>> but in the most cases TF-A is present all the time and TEE(OP-TEE) is used >>> by some configurations too. >>> >>> 3rd generated image is boot.bin with updated user field which contains >>> version number. This image can be used with updated Image Selector >>> which supports A/B update mechanisms with rollback protection. >>> >>> 4th image is image.bin which binary file which contains boot.bin and >>> u-boot.itb together and can be programmed via origin Image Selector. >>> This image can be also used for creating one capsule which contains both >>> boot images (in SPL boot flow). >>> >>> Signed-off-by: Michal Simek <michal.simek@amd.com> >>> --- >>> >>> Currently I have this for testing purpose only to find missing bits and >>> pieces in binman for cases I want to support. >>> >>> This patch depends on >>> https://lore.kernel.org/r/ >>> fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com >>> >>> --- >>> arch/arm/dts/Makefile | 1 + >>> arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ >>> arch/arm/mach-zynqmp/Kconfig | 17 ++ >>> configs/xilinx_zynqmp_kria_defconfig | 2 + >>> 4 files changed, 244 insertions(+) >>> create mode 100644 arch/arm/dts/zynqmp-som-binman.dts >> >> I'm pleased to see this. My only suggestion is to use '/bits/ 64' >> instead of the macros, for 64-bit values. > > When I was playing with it some time ago it didn't work but it works now that's > why no issue with it. One more thing on this one. I pretty much dislike that images are generated to u-boot root folder. Isn't there a way that they will be written to separate folder (deploy for example)? Thanks, Michal
On Fri, Nov 01, 2024 at 02:09:38PM +0100, Michal Simek wrote: > Hi Simon, > > On 11/1/24 09:27, Michal Simek wrote: > > > > > > On 10/31/24 19:03, Simon Glass wrote: > > > Hi Michal, > > > > > > On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek@amd.com> wrote: > > > > > > > > There is necessary to do some steps to compose boot images. These steps > > > > were in scripts in layers for a while. That's why introduce description via > > > > binman to simplify wiring and remove all scripting around. > > > > This should make sure that everybody is up2date with the latest versions. > > > > > > > > The first step is to create fit image with DTBs with descriptions in > > > > configuration node which is written as regular expression to match all SOM > > > > versions. > > > > Description is there for k24 and k26 in spite of low level psu_init > > > > configuration is different. The reason is that it goes to u-boot.itb image > > > > which is the same for k24 and k26. > > > > u-boot.itb is another image which is generated. It is normally generated > > > > via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to > > > > be deprecated. > > > > FIT image by purpose is using 64bit addresses to have default option to > > > > move images to high DDR (above 4GB). TF-A and TEE are optional components > > > > but in the most cases TF-A is present all the time and TEE(OP-TEE) is used > > > > by some configurations too. > > > > > > > > 3rd generated image is boot.bin with updated user field which contains > > > > version number. This image can be used with updated Image Selector > > > > which supports A/B update mechanisms with rollback protection. > > > > > > > > 4th image is image.bin which binary file which contains boot.bin and > > > > u-boot.itb together and can be programmed via origin Image Selector. > > > > This image can be also used for creating one capsule which contains both > > > > boot images (in SPL boot flow). > > > > > > > > Signed-off-by: Michal Simek <michal.simek@amd.com> > > > > --- > > > > > > > > Currently I have this for testing purpose only to find missing bits and > > > > pieces in binman for cases I want to support. > > > > > > > > This patch depends on > > > > https://lore.kernel.org/r/ fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com > > > > > > > > --- > > > > arch/arm/dts/Makefile | 1 + > > > > arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ > > > > arch/arm/mach-zynqmp/Kconfig | 17 ++ > > > > configs/xilinx_zynqmp_kria_defconfig | 2 + > > > > 4 files changed, 244 insertions(+) > > > > create mode 100644 arch/arm/dts/zynqmp-som-binman.dts > > > > > > I'm pleased to see this. My only suggestion is to use '/bits/ 64' > > > instead of the macros, for 64-bit values. > > > > When I was playing with it some time ago it didn't work but it works now > > that's why no issue with it. > > One more thing on this one. I pretty much dislike that images are generated > to u-boot root folder. Isn't there a way that they will be written to > separate folder (deploy for example)? Or perhaps $(obj) ?
Hi Michal, On Fri, 1 Nov 2024 at 14:52, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Nov 01, 2024 at 02:09:38PM +0100, Michal Simek wrote: > > Hi Simon, > > > > On 11/1/24 09:27, Michal Simek wrote: > > > > > > > > > On 10/31/24 19:03, Simon Glass wrote: > > > > Hi Michal, > > > > > > > > On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek@amd.com> wrote: > > > > > > > > > > There is necessary to do some steps to compose boot images. These steps > > > > > were in scripts in layers for a while. That's why introduce description via > > > > > binman to simplify wiring and remove all scripting around. > > > > > This should make sure that everybody is up2date with the latest versions. > > > > > > > > > > The first step is to create fit image with DTBs with descriptions in > > > > > configuration node which is written as regular expression to match all SOM > > > > > versions. > > > > > Description is there for k24 and k26 in spite of low level psu_init > > > > > configuration is different. The reason is that it goes to u-boot.itb image > > > > > which is the same for k24 and k26. > > > > > u-boot.itb is another image which is generated. It is normally generated > > > > > via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to > > > > > be deprecated. > > > > > FIT image by purpose is using 64bit addresses to have default option to > > > > > move images to high DDR (above 4GB). TF-A and TEE are optional components > > > > > but in the most cases TF-A is present all the time and TEE(OP-TEE) is used > > > > > by some configurations too. > > > > > > > > > > 3rd generated image is boot.bin with updated user field which contains > > > > > version number. This image can be used with updated Image Selector > > > > > which supports A/B update mechanisms with rollback protection. > > > > > > > > > > 4th image is image.bin which binary file which contains boot.bin and > > > > > u-boot.itb together and can be programmed via origin Image Selector. > > > > > This image can be also used for creating one capsule which contains both > > > > > boot images (in SPL boot flow). > > > > > > > > > > Signed-off-by: Michal Simek <michal.simek@amd.com> > > > > > --- > > > > > > > > > > Currently I have this for testing purpose only to find missing bits and > > > > > pieces in binman for cases I want to support. > > > > > > > > > > This patch depends on > > > > > https://lore.kernel.org/r/ fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com > > > > > > > > > > --- > > > > > arch/arm/dts/Makefile | 1 + > > > > > arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ > > > > > arch/arm/mach-zynqmp/Kconfig | 17 ++ > > > > > configs/xilinx_zynqmp_kria_defconfig | 2 + > > > > > 4 files changed, 244 insertions(+) > > > > > create mode 100644 arch/arm/dts/zynqmp-som-binman.dts > > > > > > > > I'm pleased to see this. My only suggestion is to use '/bits/ 64' > > > > instead of the macros, for 64-bit values. > > > > > > When I was playing with it some time ago it didn't work but it works now > > > that's why no issue with it. > > > > One more thing on this one. I pretty much dislike that images are generated > > to u-boot root folder. Isn't there a way that they will be written to > > separate folder (deploy for example)? > > Or perhaps $(obj) ? Yes $(obj) is where they end up today. I consider output files from binman to be on the same level as other files created by the build. Then again, it does end up a bit of a mess, when mixed with the output files. I am not keen on 'deploy' as it nothing is being deployed - also it sounds like a satellite or military attack. One long-standing issue is that intermediate files are created in the same directory. Perhaps we could put those in a binman-tmp directory? They are necessary when things go wrong, but don't need to be used all the time. Regards, Simon
Hi Simon, On 11/2/24 17:28, Simon Glass wrote: > Hi Michal, > > On Fri, 1 Nov 2024 at 14:52, Tom Rini <trini@konsulko.com> wrote: >> >> On Fri, Nov 01, 2024 at 02:09:38PM +0100, Michal Simek wrote: >>> Hi Simon, >>> >>> On 11/1/24 09:27, Michal Simek wrote: >>>> >>>> >>>> On 10/31/24 19:03, Simon Glass wrote: >>>>> Hi Michal, >>>>> >>>>> On Wed, 9 Oct 2024 at 10:33, Michal Simek <michal.simek@amd.com> wrote: >>>>>> >>>>>> There is necessary to do some steps to compose boot images. These steps >>>>>> were in scripts in layers for a while. That's why introduce description via >>>>>> binman to simplify wiring and remove all scripting around. >>>>>> This should make sure that everybody is up2date with the latest versions. >>>>>> >>>>>> The first step is to create fit image with DTBs with descriptions in >>>>>> configuration node which is written as regular expression to match all SOM >>>>>> versions. >>>>>> Description is there for k24 and k26 in spite of low level psu_init >>>>>> configuration is different. The reason is that it goes to u-boot.itb image >>>>>> which is the same for k24 and k26. >>>>>> u-boot.itb is another image which is generated. It is normally generated >>>>>> via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to >>>>>> be deprecated. >>>>>> FIT image by purpose is using 64bit addresses to have default option to >>>>>> move images to high DDR (above 4GB). TF-A and TEE are optional components >>>>>> but in the most cases TF-A is present all the time and TEE(OP-TEE) is used >>>>>> by some configurations too. >>>>>> >>>>>> 3rd generated image is boot.bin with updated user field which contains >>>>>> version number. This image can be used with updated Image Selector >>>>>> which supports A/B update mechanisms with rollback protection. >>>>>> >>>>>> 4th image is image.bin which binary file which contains boot.bin and >>>>>> u-boot.itb together and can be programmed via origin Image Selector. >>>>>> This image can be also used for creating one capsule which contains both >>>>>> boot images (in SPL boot flow). >>>>>> >>>>>> Signed-off-by: Michal Simek <michal.simek@amd.com> >>>>>> --- >>>>>> >>>>>> Currently I have this for testing purpose only to find missing bits and >>>>>> pieces in binman for cases I want to support. >>>>>> >>>>>> This patch depends on >>>>>> https://lore.kernel.org/r/ fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com >>>>>> >>>>>> --- >>>>>> arch/arm/dts/Makefile | 1 + >>>>>> arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ >>>>>> arch/arm/mach-zynqmp/Kconfig | 17 ++ >>>>>> configs/xilinx_zynqmp_kria_defconfig | 2 + >>>>>> 4 files changed, 244 insertions(+) >>>>>> create mode 100644 arch/arm/dts/zynqmp-som-binman.dts >>>>> >>>>> I'm pleased to see this. My only suggestion is to use '/bits/ 64' >>>>> instead of the macros, for 64-bit values. >>>> >>>> When I was playing with it some time ago it didn't work but it works now >>>> that's why no issue with it. >>> >>> One more thing on this one. I pretty much dislike that images are generated >>> to u-boot root folder. Isn't there a way that they will be written to >>> separate folder (deploy for example)? >> >> Or perhaps $(obj) ? > > Yes $(obj) is where they end up today. I consider output files from > binman to be on the same level as other files created by the build. > Then again, it does end up a bit of a mess, when mixed with the output > files. Some cleanup would be good. I remember a lot of discussion about if people should be using u-boot or u-boot.elf. Answer was simple but if output images are in separate folder it would IMHO better to understand. > I am not keen on 'deploy' as it nothing is being deployed - also it > sounds like a satellite or military attack. No problem with different name. > > One long-standing issue is that intermediate files are created in the > same directory. Perhaps we could put those in a binman-tmp directory? > They are necessary when things go wrong, but don't need to be used all > the time. +1 But I think we should try to move also that images which users should be using to separate folder completely. Again it doesn't need to be done by default but a way to configure it would be good. Thanks, Michal
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 65176c8fb836..df340cc30701 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -367,6 +367,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-sm-k24-revA-sck-kv-g-revB.dtb dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-smk-k24-revA-sck-kv-g-revB.dtb dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-sm-k24-revA-sck-kr-g-revB.dtb dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-smk-k24-revA-sck-kr-g-revB.dtb +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-som-binman.dtb dtb-$(CONFIG_ARCH_VERSAL) += \ versal-mini.dtb \ diff --git a/arch/arm/dts/zynqmp-som-binman.dts b/arch/arm/dts/zynqmp-som-binman.dts new file mode 100644 index 000000000000..7f9333b02023 --- /dev/null +++ b/arch/arm/dts/zynqmp-som-binman.dts @@ -0,0 +1,224 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * dts file for Xilinx ZynqMP SOMs (k24/k26) + * + * (C) Copyright 2024, Advanced Micro Devices, Inc. + * + * Michal Simek <michal.simek@amd.com> + */ + +#include <config.h> + +/dts-v1/; +/ { + binman: binman { + multiple-images; + fit-dtb.blob { + filename = "fit-dtb.blob"; + pad-byte = <0>; + fit { + fit,align = <0x8>; + fit,external-offset = <0x0>; + description = "DTBs for SOMs+CCs"; + fit,fdt-list-val = "zynqmp-smk-k26-revA", "zynqmp-smk-k26-revA-sck-kr-g-revA", "zynqmp-smk-k26-revA-sck-kr-g-revB", "zynqmp-smk-k26-revA-sck-kv-g-revA", "zynqmp-smk-k26-revA-sck-kv-g-revB", "zynqmp-sm-k26-revA-sck-kv-g-revA", "zynqmp-sm-k26-revA-sck-kv-g-revB", "zynqmp-sm-k26-revA-sck-kr-g-revB", "zynqmp-smk-k24-revA-sck-kd-g-revA", "zynqmp-smk-k24-revA-sck-kv-g-revB", "zynqmp-smk-k24-revA-sck-kr-g-revB", "zynqmp-sm-k24-revA-sck-kd-g-revA", "zynqmp-sm-k24-revA-sck-kv-g-revB", "zynqmp-sm-k24-revA-sck-kr-g-revB"; + + images { + @fdt-SEQ { + description = "NAME"; + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + hash-1 { + algo = "md5"; + }; + }; + }; + configurations { + default = "config-1"; + config-1 { + description = "SOM itself"; + fdt = "fdt-1"; + }; + config-2 { + description = "zynqmp-smk-k26-.*-sck-kr-g-revA"; + fdt = "fdt-2"; + }; + config-3 { + description = "zynqmp-smk-k26-.*-sck-kr-g-.*"; + fdt = "fdt-3"; + }; + config-4 { + description = "zynqmp-smk-k26-.*-sck-kv-g-rev[AZ]"; + fdt = "fdt-4"; + }; + config-5 { + description = "zynqmp-smk-k26-.*-sck-kv-g-.*"; + fdt = "fdt-5"; + }; + config-6 { + description = "zynqmp-sm-k26-.*-sck-kv-g-rev[AZ]"; + fdt = "fdt-6"; + }; + config-7 { + description = "zynqmp-sm-k26-.*-sck-kv-g-.*"; + fdt = "fdt-7"; + }; + config-8 { + description = "zynqmp-sm-k26-.*-sck-kr-g-.*"; + fdt = "fdt-8"; + }; + config-9 { + description = "zynqmp-smk-k24-.*-sck-kd-g-.*"; + fdt = "fdt-9"; + }; + config-10 { + description = "zynqmp-smk-k24-.*-sck-kv-g-.*"; + fdt = "fdt-10"; + }; + config-11 { + description = "zynqmp-smk-k24-.*-sck-kr-g-.*"; + fdt = "fdt-11"; + }; + config-12 { + description = "zynqmp-sm-k24-.*-sck-kd-g-.*"; + fdt = "fdt-12"; + }; + config-13 { + description = "zynqmp-sm-k24-.*-sck-kv-g-.*"; + fdt = "fdt-13"; + }; + config-14 { + description = "zynqmp-sm-k24-.*-sck-kr-g-.*"; + fdt = "fdt-14"; + }; + }; + }; + }; + + /* u-boot.itb generation in a static way */ +#define TEXT_BASE_DOWN (CONFIG_TEXT_BASE & 0xffffffff) +#define TEXT_BASE_UP ((CONFIG_TEXT_BASE >> 32) & 0xffffffff) + +#define BL31_BASE_DOWN (CONFIG_BL31_LOAD_ADDR & 0xffffffff) +#define BL31_BASE_UP ((CONFIG_BL31_LOAD_ADDR >> 32) & 0xffffffff) + +#define BL32_BASE_DOWN (CONFIG_BL32_LOAD_ADDR & 0xffffffff) +#define BL32_BASE_UP ((CONFIG_BL32_LOAD_ADDR >> 32) & 0xffffffff) + + itb { + filename = "u-boot.itb"; + pad-byte = <0>; + + fit { + description = "Configuration for Xilinx ZynqMP SoC"; + fit,align = <0x8>; + fit,external-offset = <0x0>; + images { + uboot { + description = "U-Boot (64-bit)"; + type = "firmware"; + os = "u-boot"; + arch = "arm64"; + compression = "none"; + load = <(TEXT_BASE_UP) (TEXT_BASE_DOWN)>; + entry = <(TEXT_BASE_UP) (TEXT_BASE_DOWN)>; + hash { + algo = "md5"; + }; + u-boot-nodtb { + }; + }; + atf { + description = "Trusted Firmware-A"; + type = "firmware"; + os = "arm-trusted-firmware"; + arch = "arm64"; + compression = "none"; + load = <(BL31_BASE_UP) (BL31_BASE_DOWN)>; + entry = <(BL31_BASE_UP) (BL31_BASE_DOWN)>; + hash { + algo = "md5"; + }; + atf-bl31 { + optional; + }; + }; + tee { + description = "OP-TEE"; + type = "tee"; + arch = "arm64"; + compression = "none"; + os = "tee"; + load = <(BL32_BASE_UP) (BL32_BASE_DOWN)>; + entry = <(BL32_BASE_UP) (BL32_BASE_DOWN)>; + tee-os { + optional; + }; + }; + fdt { + description = "Multi DTB fit image"; + type = "flat_dt"; + arch = "arm64"; + compression = "none"; + load = <0x0 0x100000>; + hash { + algo = "md5"; + }; + fdt-blob { + filename = "fit-dtb.blob"; + type = "blob-ext"; + }; + }; + }; + configurations { + default = "config-1"; + config-1 { + description = "Multi DTB with TF-A"; + firmware = "atf"; + loadables = "tee", "uboot", "fdt"; + }; + }; + }; + }; + + /* boot.bin generated with version string inside */ + bootimage { + filename = "boot.bin"; + pad-byte = <0>; + + blob-ext@1 { + offset = <0x0>; + filename = "spl/boot.bin"; + }; + /* Optional version string at offset 0x70 */ + blob-ext@2 { + offset = <0x70>; + filename = "version.bin"; + overlap; + optional; + }; + /* Optional version string at offset 0x94 */ + blob-ext@3 { + offset = <0x94>; + filename = "version.bin"; + overlap; + optional; + }; + }; + + /* Full QSPI image for recovery app */ + image { + filename = "image.bin"; + pad-byte = <0>; + + blob-ext@1 { + offset = <0x0>; + filename = "boot.bin"; + }; + blob-ext@2 { + offset = <CONFIG_SYS_SPI_U_BOOT_OFFS>; + filename = "u-boot.itb"; + }; + }; + }; +}; diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig index aea13622b68a..a74de68c0181 100644 --- a/arch/arm/mach-zynqmp/Kconfig +++ b/arch/arm/mach-zynqmp/Kconfig @@ -11,6 +11,9 @@ config SYS_VENDOR config SYS_SOC default "zynqmp" +config BINMAN + default y + config SYS_MEM_RSVD_FOR_MMU bool "Reserve memory for MMU Table" help @@ -132,6 +135,20 @@ config SPL_ZYNQMP_RESTORE_JTAG even if no eFuses were burnt. This option restores the interface if possible. +config BL31_LOAD_ADDR + hex "Load address of BL31 image (mostly TF-A)" + default 0xfffe5000 + help + The load address for the BL31 image. This value is used to build the + FIT image header that places BL31 in memory where it will run. + +config BL32_LOAD_ADDR + hex "Load address of BL32 image (mostly secure OS)" + default 0x60000000 + help + The load address for the BL32 image. This value is used to build the + FIT image header that places BL32 in memory where it will run. + config ZYNQ_SDHCI_MAX_FREQ default 200000000 diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index 2eff9f35c0f4..1b4c33d2974e 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -53,6 +53,7 @@ CONFIG_SYS_PBSIZE=2073 CONFIG_BOARD_EARLY_INIT_R=y CONFIG_CLOCKS=y CONFIG_SPL_MAX_SIZE=0x40000 +# CONFIG_SPL_BINMAN_SYMBOLS is not set # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_FS_LOAD_KERNEL_NAME="" CONFIG_SPL_FS_LOAD_ARGS_NAME="" @@ -233,6 +234,7 @@ CONFIG_VIDEO_ZYNQMP_DPSUB=y CONFIG_VIRTIO_MMIO=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_BLK=y +# CONFIG_BINMAN_FDT is not set CONFIG_PANIC_HANG=y CONFIG_TPM=y CONFIG_SPL_GZIP=y
There is necessary to do some steps to compose boot images. These steps were in scripts in layers for a while. That's why introduce description via binman to simplify wiring and remove all scripting around. This should make sure that everybody is up2date with the latest versions. The first step is to create fit image with DTBs with descriptions in configuration node which is written as regular expression to match all SOM versions. Description is there for k24 and k26 in spite of low level psu_init configuration is different. The reason is that it goes to u-boot.itb image which is the same for k24 and k26. u-boot.itb is another image which is generated. It is normally generated via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to be deprecated. FIT image by purpose is using 64bit addresses to have default option to move images to high DDR (above 4GB). TF-A and TEE are optional components but in the most cases TF-A is present all the time and TEE(OP-TEE) is used by some configurations too. 3rd generated image is boot.bin with updated user field which contains version number. This image can be used with updated Image Selector which supports A/B update mechanisms with rollback protection. 4th image is image.bin which binary file which contains boot.bin and u-boot.itb together and can be programmed via origin Image Selector. This image can be also used for creating one capsule which contains both boot images (in SPL boot flow). Signed-off-by: Michal Simek <michal.simek@amd.com> --- Currently I have this for testing purpose only to find missing bits and pieces in binman for cases I want to support. This patch depends on https://lore.kernel.org/r/fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.simek@amd.com --- arch/arm/dts/Makefile | 1 + arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++ arch/arm/mach-zynqmp/Kconfig | 17 ++ configs/xilinx_zynqmp_kria_defconfig | 2 + 4 files changed, 244 insertions(+) create mode 100644 arch/arm/dts/zynqmp-som-binman.dts