Add Xilinx ZynqMP and ZCU106 board support

U-Boot SPL for the Xilinx ZynqMP SoCs needs ATF in this format to load it.

Signed-off-by Luca Ceresoli <[email protected]>

Changes v1 -> v2: none.

---
 boot/arm-trusted-firmware/Config.in               |  9 +++++++++
 boot/arm-trusted-firmware/arm-trusted-firmware.mk | 21 +++++++++++++++++++++
 2 files changed, 30 insertions(+)

boot/arm-trusted-firmware/Config.in +0 -0

index 7aef87cb746c..dca9958423b9 100644
@@ -71,6 +71,15 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
 	  typically used on platforms where another bootloader (e.g

Hello,

Quoted 17 lines · Luca Ceresoli

U-Boot SPL for the Xilinx ZynqMP SoCs needs ATF in this format to load it.

Signed-off-by Luca Ceresoli <[email protected]>

Changes v1 -> v2: none.

---
 boot/arm-trusted-firmware/Config.in               |  9 +++++++++
 boot/arm-trusted-firmware/arm-trusted-firmware.mk | 21 +++++++++++++++++++++
 2 files changed, 30 insertions(+)

boot/arm-trusted-firmware/Config.in +0 -0

index 7aef87cb746c..dca9958423b9 100644
@@ -71,6 +71,15 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
 	  typically used on platforms where another bootloader (e.g

boot/arm-trusted-firmware/Config.in config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31 · line 81

Quoted 10 lines

boot/arm-trusted-firmware/Config.in +8 -0

 	  U-Boot) encapsulates ATF BL31.
 
+config BR2_TARGET_ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_MKIMAGE
+	bool "Generate a U-Boot image (for Xilinx ZynqMP U-Boot)"
+	depends on BR2_cortex_a53
+	select BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
+	help
+	  Uses mkimage from uboot-tools to encapsulate bl31.bin into
+	  a U-Boot image named atf-uboot.ub. This is needed by the
+	  Xilinx version of U-Boot SPL to load ATF on the ZynqMP SoC.

In fact this doesn't look like very Xilinx-specific. It just encapsulates the bl31 image in a U-Boot image format. This could potentially be used by other platforms as well.

So, perhaps we could make this:

config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31_UBOOT
bool "Build BL31 U-Boot image"
select BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
help
This option will generate a bl31.bin that is encapsulates into a U-Boot image named atf-uboot.ub. This is for example used by the Xilinx version of U-Boot SPL to load ATF on the ZynqMP SoC.

boot/arm-trusted-firmware/Config.in config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31

Quoted 6 lines

boot/arm-trusted-firmware/Config.in +6 -0

+ifeq ($(BR2_TARGET_ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_MKIMAGE),y)
+define ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_MKIMAGE
+# Get the entry point address from the elf.
+	BASE_ADDR=$$($(TARGET_READELF) -h $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/bl31/bl31.elf | \
+	             grep -E -m 1 -i "entry point.*?0x" | \
+	             sed -r 's/.*?(0x.*?)/\1/g') && \

Meh, what a mess to get the entry point address :-/ Could this be simplified with:

$(TARGET_READELF) -h $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/bl31/bl31.elf | sed '/^ Entry point address: *\(.*\)/!d; s//\1/'

(Thanks Yann!)

boot/arm-trusted-firmware/Config.in

Quoted 8 lines

boot/arm-trusted-firmware/Config.in +8 -0

+	$(HOST_DIR)/bin/mkimage \
+		-A arm64 -O arm-trusted-firmware -C none \
+		-a $${BASE_ADDR} -e $${BASE_ADDR} \
+		-d $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/bl31.bin \
+		$(ARM_TRUSTED_FIRMWARE_IMG_DIR)/atf-uboot.ub
+endef
+define ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_INSTALL
+	install $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/atf-uboot.ub $(BINARIES_DIR)

Should be:

	$(INSTALL) -m 0644 -D $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/atf-uboot.ub $(BINARIES_DIR)/atf-uboot.ub

boot/arm-trusted-firmware/Config.in

Quoted 5 lines

boot/arm-trusted-firmware/Config.in +5 -0

+endef
+ARM_TRUSTED_FIRMWARE_MAKE_OPTS += RESET_TO_BL31=1
+ARM_TRUSTED_FIRMWARE_DEPENDENCIES += host-uboot-tools
+ARM_TRUSTED_FIRMWARE_POST_BUILD_HOOKS += ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_MKIMAGE
+ARM_TRUSTED_FIRMWARE_POST_INSTALL_IMAGES_HOOKS += ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_INSTALL

Rather than hooks, just use directly ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_MKIMAGE and ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_INSTALL in the BUILD_CMDS and INSTALL_IMAGES_CMDS. Of course, remove the ZYNQMP part of the variable names if you agree with my proposal above.

boot/zynqmp-pmufw-binaries/Config.in new file +7 -0

new file mode 100644
index 000000000000..e39561cbf91e
@@ -0,0 +1,19 @@
+config BR2_TARGET_ZYNQMP_PMUFW_BINARIES
+	bool "Zynqmp PMU firmware"
+	depends on BR2_aarch64
+	help
+	  This package provides precompiled firmwares for the Platform
+	  Management Unit (PMU) of the Xilinx ZynqMP family of SoCs.
+

Hello,

Quoted 19 lines · Luca Ceresoli

boot/zynqmp-pmufw-binaries/Config.in new file +13 -0

new file mode 100644
index 000000000000..e39561cbf91e
@@ -0,0 +1,19 @@
+config BR2_TARGET_ZYNQMP_PMUFW_BINARIES
+	bool "Zynqmp PMU firmware"
+	depends on BR2_aarch64
+	help
+	  This package provides precompiled firmwares for the Platform
+	  Management Unit (PMU) of the Xilinx ZynqMP family of SoCs.
+
+	  https://github.com/lucaceresoli/zynqmp-pmufw-binaries
+
+if BR2_TARGET_ZYNQMP_PMUFW_BINARIES
+
+config BR2_TARGET_ZYNQMP_PMUFW_BINARIES_IMAGE
+	string "PMU firmware image file"

boot/zynqmp-pmufw-binaries/Config.in line 17

Quoted 4 lines

boot/zynqmp-pmufw-binaries/Config.in new file +4 -0

+	help
+	  Enter the path to the PMU firmware file for your board and
+	  configuration, relative to the repository top directory.
+	  Example: "zcu106-default/pmufw.bin".

So this hints at the fact that this firmware is board specific. Is that correct ? If so, shouldn't we plan on making the Git repo and its version configurable ?

I mean, what are the chances that for some random ZynqMP board, your Github repo will contain the appropriate firmware file ?

Generally speaking, it's a bit annoying that we can't build this from source. I understand it needs a Microblaze toolchain, so it's very difficult to integrate in Buildroot :-/

Quoted 3 lines

So this hints at the fact that this firmware is board specific. Is that correct ? If so, shouldn't we plan on making the Git repo and its version configurable ?

The firmware is board-specific and configuration-specific. The plan for that repo, however, is to have all supported board+config combinations supported in all versions, thus the lack of a version selection knob.

Quoted 2 lines

I mean, what are the chances that for some random ZynqMP board, your Github repo will contain the appropriate firmware file ?

Good point. My repo there is ready to hold any possible board+config combination that is interesting for known boards. I would love to host more boards there (contributilns would be welcome). However I don't think we'll ever see any custom board, which reduces its usefulness.

Thus a simpler, but more flexible, option might be to nuke the zynqmp-pmufw-binaries BR package and let uboot fetch the pmufw.bin from a plain URL (https:// or file://). For standard devboards the URL could point to my repo, but it can be anywhere else (for custom boards).

Quoted 3 lines

Generally speaking, it's a bit annoying that we can't build this from source. I understand it needs a Microblaze toolchain, so it's very difficult to integrate in Buildroot :-/

Indeed, and this is *the* big topic.

There are several variations that could be considered, but none have been attempted AFAIK. Here they are, simplest to hardest:

1. Build the PMUFW in Buildroot (kind of)

Add a script (e.g. board/zynqmp/build-pmufw.sh) that builds a microblaze toolchain and the PMUFW with a given config. The commands are already
there: [0].

The script would then be called manually before Buildroot runs, or it could be wrapped in a Buildroot package that uboot depends on. Takes ~8 minutes on a modern quad core machine.

* Simple to do, not well integrated, longer build time.

2. Let SPL install the PMUFW config

This is what the Xilinx workflow does (in the Xilinx FSBL, which is more or less equivalent to U-Boot SPL). This allows The PMUFW can be a unique blob for all boards.

This moves the configuration object from a piece of early firmware (PMUFW) to another piece of early firmware (SPL). Both pieces are residing in the same BOOT.BIN file, so there's no added flexibility for the "user": upon a config change, you still have to update the BOOT.BIN file in the boot medium.

There are also licensing issues preventing this, since the configuration object file license is not compatible with the U-Boot license. Xilinx _might_ be willing to fix this, however.

* Could be doable, perhaps tricky.

3. Don't have any config object...

...and change the PMUFW source code to assign dynamically peripherals to cores at runtime, based on requests from cores! :->

* Maybe doable, potentially dangerous, definitely hard to do.

Any idea or suggestion is very welcome, although I think we cannot do much more than looking for the least evil solution...

Hello Luca,

Quoted 7 lines · Luca Ceresoli

Quoted 3 lines

So this hints at the fact that this firmware is board specific. Is that correct ? If so, shouldn't we plan on making the Git repo and its version configurable ?

The firmware is board-specific and configuration-specific. The plan for that repo, however, is to have all supported board+config combinations supported in all versions, thus the lack of a version selection knob.

"all" ? I'm pretty sure a lot of people will be doing custom designs, and will not be willing to push their firmware binary to your public repository.

Quoted 8 lines

Quoted 2 lines

I mean, what are the chances that for some random ZynqMP board, your Github repo will contain the appropriate firmware file ?

Good point. My repo there is ready to hold any possible board+config combination that is interesting for known boards. I would love to host more boards there (contributilns would be welcome). However I don't think we'll ever see any custom board, which reduces its usefulness.

Quoted 4 lines

Thus a simpler, but more flexible, option might be to nuke the zynqmp-pmufw-binaries BR package and let uboot fetch the pmufw.bin from a plain URL (https:// or file://). For standard devboards the URL could point to my repo, but it can be anywhere else (for custom boards).

Ah, this seems like a better option indeed, especially since the firmware is a single file. It could be locally available, or downloaded from HTTP. Sounds like a good plan.

Quoted 15 lines

Quoted 3 lines

Generally speaking, it's a bit annoying that we can't build this from source. I understand it needs a Microblaze toolchain, so it's very difficult to integrate in Buildroot :-/

Indeed, and this is *the* big topic.

There are several variations that could be considered, but none have been attempted AFAIK. Here they are, simplest to hardest:

1. Build the PMUFW in Buildroot (kind of)

Add a script (e.g. board/zynqmp/build-pmufw.sh) that builds a microblaze toolchain and the PMUFW with a given config. The commands are already
there: [0].

Quoted 5 lines

The script would then be called manually before Buildroot runs, or it could be wrapped in a Buildroot package that uboot depends on. Takes ~8 minutes on a modern quad core machine.

* Simple to do, not well integrated, longer build time.

Yeah, the integration with Buildroot here is really not great, because Crosstool-NG will do its own downloading, etc.

Quoted 20 lines

2. Let SPL install the PMUFW config

This is what the Xilinx workflow does (in the Xilinx FSBL, which is more or less equivalent to U-Boot SPL). This allows The PMUFW can be a unique blob for all boards.

This moves the configuration object from a piece of early firmware (PMUFW) to another piece of early firmware (SPL). Both pieces are residing in the same BOOT.BIN file, so there's no added flexibility for the "user": upon a config change, you still have to update the BOOT.BIN file in the boot medium.

There are also licensing issues preventing this, since the configuration object file license is not compatible with the U-Boot license. Xilinx _might_ be willing to fix this, however.

* Could be doable, perhaps tricky.

3. Don't have any config object...

Quoted 4 lines

...and change the PMUFW source code to assign dynamically peripherals to cores at runtime, based on requests from cores! :->

* Maybe doable, potentially dangerous, definitely hard to do.

Not sure I understand enough of what the PMUFW is doing to understand
(2) and (3). And yes, I did attend your talk at FOSDEM about ZynqMP ! :-)

boot/uboot/Config.in +11 -0

+config BR2_TARGET_UBOOT_ZYNQMP
+	bool "Boot on the Xilinx ZynqMP SoCs"
+	depends on BR2_aarch64
+	select BR2_TARGET_ZYNQMP_PMUFW_BINARIES
+	help
+	  Instruct the U-Boot build process to generate a file named
+	  boot.bin, which is the file loaded by the ZynqMP boot ROM.
+	  boot.bin contains both the U-Boot SPL and the PMU firmware
+	  (downloaded by the zynqmp-pmufw-binaries package) formatted
+	  with the Xilinx-specific format.
+
 config BR2_TARGET_UBOOT_ALTERA_SOCFPGA_IMAGE_CRC
 	bool "CRC image for Altera SoC FPGA (mkpimage)"
 	depends on BR2_arm

boot/uboot/uboot.mk +0 -0

index 24d3e4ef5485..e81a9fd41dab 100644