* [Buildroot] [PATCH v2-RESEND 1/6] arm-trusted-firmware: simplify release dir path
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
@ 2018-04-06 16:34 ` Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting Luca Ceresoli
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-06 16:34 UTC (permalink / raw)
To: buildroot
The path to the binary images is very long. Since we are about to make
a larger use of it, let's use a variable to make it somewhat shorter.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Changes v1 -> v2: none.
---
boot/arm-trusted-firmware/arm-trusted-firmware.mk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
index 4bac916e3108..212bb5049f2b 100644
--- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
+++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
@@ -25,6 +25,7 @@ endif
ARM_TRUSTED_FIRMWARE_INSTALL_IMAGES = YES
ARM_TRUSTED_FIRMWARE_PLATFORM = $(call qstrip,$(BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM))
+ARM_TRUSTED_FIRMWARE_IMG_DIR = $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM)/release
ARM_TRUSTED_FIRMWARE_MAKE_OPTS += \
CROSS_COMPILE="$(TARGET_CROSS)" \
@@ -82,7 +83,7 @@ define ARM_TRUSTED_FIRMWARE_BUILD_CMDS
endef
define ARM_TRUSTED_FIRMWARE_INSTALL_IMAGES_CMDS
- cp -dpf $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM)/release/*.bin $(BINARIES_DIR)/
+ cp -dpf $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/*.bin $(BINARIES_DIR)/
endef
# Configuration check
--
2.7.4
^ permalink raw reply related [flat|nested] 14+ messages in thread* [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 1/6] arm-trusted-firmware: simplify release dir path Luca Ceresoli
@ 2018-04-06 16:34 ` Luca Ceresoli
2018-04-09 21:08 ` Thomas Petazzoni
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package Luca Ceresoli
` (3 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-06 16:34 UTC (permalink / raw)
To: buildroot
U-Boot SPL for the Xilinx ZynqMP SoCs needs ATF in this format to load
it.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
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(+)
diff --git a/boot/arm-trusted-firmware/Config.in b/boot/arm-trusted-firmware/Config.in
index 7aef87cb746c..dca9958423b9 100644
--- a/boot/arm-trusted-firmware/Config.in
+++ b/boot/arm-trusted-firmware/Config.in
@@ -71,6 +71,15 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
typically used on platforms where another bootloader (e.g
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.
+
config BR2_TARGET_ARM_TRUSTED_FIRMWARE_UBOOT_AS_BL33
bool "Use U-Boot as BL33"
depends on BR2_TARGET_UBOOT
diff --git a/boot/arm-trusted-firmware/arm-trusted-firmware.mk b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
index 212bb5049f2b..69aac4ee3eb4 100644
--- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
+++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
@@ -86,6 +86,27 @@ define ARM_TRUSTED_FIRMWARE_INSTALL_IMAGES_CMDS
cp -dpf $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/*.bin $(BINARIES_DIR)/
endef
+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') && \
+ $(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)
+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
+endif
+
# Configuration check
ifeq ($(BR2_TARGET_ARM_TRUSTED_FIRMWARE)$(BR_BUILDING),yy)
--
2.7.4
^ permalink raw reply related [flat|nested] 14+ messages in thread* [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting Luca Ceresoli
@ 2018-04-09 21:08 ` Thomas Petazzoni
2018-04-11 21:12 ` Luca Ceresoli
0 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2018-04-09 21:08 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 6 Apr 2018 18:34:17 +0200, Luca Ceresoli wrote:
> U-Boot SPL for the Xilinx ZynqMP SoCs needs ATF in this format to load
> it.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>
> 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(+)
>
> diff --git a/boot/arm-trusted-firmware/Config.in b/boot/arm-trusted-firmware/Config.in
> index 7aef87cb746c..dca9958423b9 100644
> --- a/boot/arm-trusted-firmware/Config.in
> +++ b/boot/arm-trusted-firmware/Config.in
> @@ -71,6 +71,15 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
> typically used on platforms where another bootloader (e.g
> 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.
> +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!)
> + $(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
> +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.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread* [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting
2018-04-09 21:08 ` Thomas Petazzoni
@ 2018-04-11 21:12 ` Luca Ceresoli
0 siblings, 0 replies; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-11 21:12 UTC (permalink / raw)
To: buildroot
Hi,
On 09/04/2018 23:08, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 6 Apr 2018 18:34:17 +0200, Luca Ceresoli wrote:
>> U-Boot SPL for the Xilinx ZynqMP SoCs needs ATF in this format to load
>> it.
>>
>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>>
>> 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(+)
>>
>> diff --git a/boot/arm-trusted-firmware/Config.in b/boot/arm-trusted-firmware/Config.in
>> index 7aef87cb746c..dca9958423b9 100644
>> --- a/boot/arm-trusted-firmware/Config.in
>> +++ b/boot/arm-trusted-firmware/Config.in
>> @@ -71,6 +71,15 @@ config BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
>> typically used on platforms where another bootloader (e.g
>> 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.
>
>> +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!)
>
>> + $(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
>
>> +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.
Thanks for the review. These changes will be in v3.
Bye,
--
Luca
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 1/6] arm-trusted-firmware: simplify release dir path Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 2/6] arm-trusted-firmware: generate atf-uboot.ub for ZynqMP booting Luca Ceresoli
@ 2018-04-06 16:34 ` Luca Ceresoli
2018-04-09 21:13 ` Thomas Petazzoni
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 4/6] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
` (2 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-06 16:34 UTC (permalink / raw)
To: buildroot
Downloads pre-built binary firmwares for the Xilinx ZynqMP SoCs PMU.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Changes v1 -> v2: none.
---
DEVELOPERS | 1 +
boot/Config.in | 1 +
boot/zynqmp-pmufw-binaries/Config.in | 19 ++++++++++++++++
.../zynqmp-pmufw-binaries.hash | 3 +++
.../zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.mk | 26 ++++++++++++++++++++++
5 files changed, 50 insertions(+)
create mode 100644 boot/zynqmp-pmufw-binaries/Config.in
create mode 100644 boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.hash
create mode 100644 boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.mk
diff --git a/DEVELOPERS b/DEVELOPERS
index 9d23fa51b876..eb4781c1e3cd 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1070,6 +1070,7 @@ F: package/ti-sgx-um/
N: Luca Ceresoli <luca@lucaceresoli.net>
F: board/olimex/a20_olinuxino/
+F: boot/zynqmp-pmufw-binaries/
F: configs/olimex_a20_olinuxino_*
F: package/agentpp/
F: package/exim/
diff --git a/boot/Config.in b/boot/Config.in
index 3687c41a2c00..a23886997c9f 100644
--- a/boot/Config.in
+++ b/boot/Config.in
@@ -19,5 +19,6 @@ source "boot/ts4800-mbrboot/Config.in"
source "boot/uboot/Config.in"
source "boot/vexpress-firmware/Config.in"
source "boot/xloader/Config.in"
+source "boot/zynqmp-pmufw-binaries/Config.in"
endmenu
diff --git a/boot/zynqmp-pmufw-binaries/Config.in b/boot/zynqmp-pmufw-binaries/Config.in
new file mode 100644
index 000000000000..e39561cbf91e
--- /dev/null
+++ b/boot/zynqmp-pmufw-binaries/Config.in
@@ -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"
+ 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".
+
+endif
diff --git a/boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.hash b/boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.hash
new file mode 100644
index 000000000000..a60566445290
--- /dev/null
+++ b/boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.hash
@@ -0,0 +1,3 @@
+# Locally computed
+sha256 b74808c93522a39bedecd64bd5a75fd766f267e1d540f45dbfe868694f49b1d7 zynqmp-pmufw-binaries-ec64e06b836a0841f40bd52434f6919c5dafb133.tar.gz
+sha256 235b467980655706d5fded5baf3d8b52ddb102a9e0c26804a67c0ec719042d38 license.txt
diff --git a/boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.mk b/boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.mk
new file mode 100644
index 000000000000..91aec04f907a
--- /dev/null
+++ b/boot/zynqmp-pmufw-binaries/zynqmp-pmufw-binaries.mk
@@ -0,0 +1,26 @@
+################################################################################
+#
+# zynqmp-pmufw-binaries
+#
+################################################################################
+
+ZYNQMP_PMUFW_BINARIES_VERSION = ec64e06b836a0841f40bd52434f6919c5dafb133
+ZYNQMP_PMUFW_BINARIES_SITE = $(call github,lucaceresoli,zynqmp-pmufw-binaries,$(ZYNQMP_PMUFW_BINARIES_VERSION))
+
+ZYNQMP_PMUFW_BINARIES_LICENSE = X11 with Xilinx exception
+ZYNQMP_PMUFW_BINARIES_LICENSE_FILES = license.txt
+
+ZYNQMP_PMUFW_BINARIES_IMAGE = $(call qstrip,$(BR2_TARGET_ZYNQMP_PMUFW_BINARIES_IMAGE))
+ZYNQMP_PMUFW_BINARIES_INSTALL_IMAGES = YES
+
+define ZYNQMP_PMUFW_BINARIES_INSTALL_IMAGES_CMDS
+ $(INSTALL) -D -m 0644 $(@D)/$(ZYNQMP_PMUFW_BINARIES_IMAGE) $(BINARIES_DIR)/pmufw.bin
+endef
+
+ifeq ($(ZYNQMP_PMUFW_BINARIES),y)
+ifeq ($(ZYNQMP_PMUFW_BINARIES_IMAGE),)
+$(error No PMU firmware image file name set. Check your BR2_TARGET_ZYNQMP_PMUFW_BINARIES_IMAGE setting)
+endif
+endif
+
+$(eval $(generic-package))
--
2.7.4
^ permalink raw reply related [flat|nested] 14+ messages in thread* [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package Luca Ceresoli
@ 2018-04-09 21:13 ` Thomas Petazzoni
2018-04-11 21:03 ` Luca Ceresoli
0 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2018-04-09 21:13 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 6 Apr 2018 18:34:18 +0200, Luca Ceresoli wrote:
> diff --git a/boot/zynqmp-pmufw-binaries/Config.in b/boot/zynqmp-pmufw-binaries/Config.in
> new file mode 100644
> index 000000000000..e39561cbf91e
> --- /dev/null
> +++ b/boot/zynqmp-pmufw-binaries/Config.in
> @@ -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"
> + 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 :-/
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package
2018-04-09 21:13 ` Thomas Petazzoni
@ 2018-04-11 21:03 ` Luca Ceresoli
2018-04-12 9:09 ` Thomas Petazzoni
0 siblings, 1 reply; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-11 21:03 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 09/04/2018 23:13, Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 6 Apr 2018 18:34:18 +0200, Luca Ceresoli wrote:
>
>> diff --git a/boot/zynqmp-pmufw-binaries/Config.in b/boot/zynqmp-pmufw-binaries/Config.in
>> new file mode 100644
>> index 000000000000..e39561cbf91e
>> --- /dev/null
>> +++ b/boot/zynqmp-pmufw-binaries/Config.in
>> @@ -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"
>> + 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 ?
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.
But maybe we can reconsider this topic later, when the repo contains at
least 2 versions, or at least 2 boards, or at least 2 configs... :)
> 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).
> 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.
[0]
https://github.com/lucaceresoli/zynqmp-pmufw-builder/blob/master/build.sh
Any idea or suggestion is very welcome, although I think we cannot do
much more than looking for the least evil solution...
Bye,
--
Luca
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package
2018-04-11 21:03 ` Luca Ceresoli
@ 2018-04-12 9:09 ` Thomas Petazzoni
2018-05-03 16:26 ` Luca Ceresoli
0 siblings, 1 reply; 14+ messages in thread
From: Thomas Petazzoni @ 2018-04-12 9:09 UTC (permalink / raw)
To: buildroot
Hello Luca,
On Wed, 11 Apr 2018 23:03:17 +0200, Luca Ceresoli wrote:
> > 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.
> > 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).
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.
> > 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.
Yeah, the integration with Buildroot here is really not great, because
Crosstool-NG will do its own downloading, etc.
> 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.
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 ! :-)
> Any idea or suggestion is very welcome, although I think we cannot do
> much more than looking for the least evil solution...
I think for now the solution you propose to add an option in U-Boot to
indicate the path/URL to the PMUFW binary is the easiest one. It can
always be improved later if better solutions emerge.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package
2018-04-12 9:09 ` Thomas Petazzoni
@ 2018-05-03 16:26 ` Luca Ceresoli
0 siblings, 0 replies; 14+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:26 UTC (permalink / raw)
To: buildroot
Hi,
On 12/04/2018 11:09, Thomas Petazzoni wrote:
> Hello Luca,
>
> On Wed, 11 Apr 2018 23:03:17 +0200, Luca Ceresoli wrote:
>
>>> 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.
>
>>> 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).
>
> 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.
I just sent v3 which implements this. Thanks Yann for having fixed
EXTRA_DOWNLOADS! :)
>>> 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.
>
> Yeah, the integration with Buildroot here is really not great, because
> Crosstool-NG will do its own downloading, etc.
>
>> 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.
>
> 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 ! :-)
Which perhaps means I should improve my communication skills! :-\
Bye,
--
Luca
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2-RESEND 4/6] uboot: zynqmp: generate SPL image with PMUFW binary
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
` (2 preceding siblings ...)
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 3/6] zynqmp-pmufw-binaries: new package Luca Ceresoli
@ 2018-04-06 16:34 ` Luca Ceresoli
2018-04-09 21:26 ` Thomas Petazzoni
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 5/6] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 6/6] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
5 siblings, 1 reply; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-06 16:34 UTC (permalink / raw)
To: buildroot
In order to boot on the Xilinx ZynqMP SoCs, U-Boot SPL requires a
recent PMU firmware loaded. Instruct U-Boot to add pmufw.bin to the
boot.bin file together with U-Boot SPL, to the boot ROM will load
both.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Changes v1 -> v2:
- split from a larger patch doing 2 things.
---
boot/uboot/Config.in | 11 +++++++++++
boot/uboot/uboot.mk | 13 +++++++++++++
2 files changed, 24 insertions(+)
diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index cef8ccd3cd0d..68c0be05d95a 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -368,6 +368,17 @@ config BR2_TARGET_UBOOT_ZYNQ_IMAGE
for u-boot-dtb.img file so this U-Boot format is required
to be set.
+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
diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
index 24d3e4ef5485..e81a9fd41dab 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -278,6 +278,19 @@ define UBOOT_INSTALL_IMAGES_CMDS
$(BINARIES_DIR)/boot.scr)
endef
+ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
+
+UBOOT_DEPENDENCIES += zynqmp-pmufw-binaries
+define UBOOT_KCONFIG_FIXUP_CMDS
+ $(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,"board/xilinx/zynqmp/pmufw.bin",$(@D)/.config)
+endef
+define UBOOT_ZYNQMP_COPY_PMUFW
+ cp ${BINARIES_DIR}/pmufw.bin $(@D)/board/xilinx/zynqmp/
+endef
+UBOOT_PRE_CONFIGURE_HOOKS += UBOOT_ZYNQMP_COPY_PMUFW
+
+endif # BR2_TARGET_UBOOT_ZYNQMP
+
define UBOOT_INSTALL_OMAP_IFT_IMAGE
cp -dpf $(@D)/$(UBOOT_BIN_IFT) $(BINARIES_DIR)/
endef
--
2.7.4
^ permalink raw reply related [flat|nested] 14+ messages in thread* [Buildroot] [PATCH v2-RESEND 4/6] uboot: zynqmp: generate SPL image with PMUFW binary
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 4/6] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
@ 2018-04-09 21:26 ` Thomas Petazzoni
0 siblings, 0 replies; 14+ messages in thread
From: Thomas Petazzoni @ 2018-04-09 21:26 UTC (permalink / raw)
To: buildroot
Hello,
On Fri, 6 Apr 2018 18:34:19 +0200, Luca Ceresoli wrote:
> +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
> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
> index 24d3e4ef5485..e81a9fd41dab 100644
> --- a/boot/uboot/uboot.mk
> +++ b/boot/uboot/uboot.mk
> @@ -278,6 +278,19 @@ define UBOOT_INSTALL_IMAGES_CMDS
> $(BINARIES_DIR)/boot.scr)
> endef
>
> +ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
> +
> +UBOOT_DEPENDENCIES += zynqmp-pmufw-binaries
> +define UBOOT_KCONFIG_FIXUP_CMDS
> + $(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,"board/xilinx/zynqmp/pmufw.bin",$(@D)/.config)
> +endef
I'd prefer if the definition of UBOOT_KCONFIG_FIXUP_CMDS was outside
this condition, and uses a variable like $(UBOOT_ZYNQMP_CONFIG_FIXUP)
instead.
> +define UBOOT_ZYNQMP_COPY_PMUFW
> + cp ${BINARIES_DIR}/pmufw.bin $(@D)/board/xilinx/zynqmp/
Please use $(...) instead of ${...} to reference make variables. And
use $(INSTALL) -D -m 0644 :)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Buildroot] [PATCH v2-RESEND 5/6] uboot: zynqmp: allow to use custom psu_init files
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
` (3 preceding siblings ...)
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 4/6] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
@ 2018-04-06 16:34 ` Luca Ceresoli
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 6/6] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
5 siblings, 0 replies; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-06 16:34 UTC (permalink / raw)
To: buildroot
U-Boot SPL configures pinmuxes, clocks and other low-level devices. On
the Xilinx ZynqMP SoCs the code to do this resides in a file called
psu_init_gpl.c which is initially generated by the Xilinx development
tools. Add an option to pass these files from the outside (e.g. in the
board files).
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Changes v1 -> v2:
- split from a larger patch doing 2 things
- document the option of having psu_init_gpl.c without .h
---
boot/uboot/Config.in | 22 ++++++++++++++++++++++
boot/uboot/uboot.mk | 12 ++++++++++++
2 files changed, 34 insertions(+)
diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index 68c0be05d95a..55a99aea23d8 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -379,6 +379,28 @@ config BR2_TARGET_UBOOT_ZYNQMP
(downloaded by the zynqmp-pmufw-binaries package) formatted
with the Xilinx-specific format.
+if BR2_TARGET_UBOOT_ZYNQMP
+config BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR
+ string "Custom psu_init_gpl files"
+ help
+ On ZynqMP the booloader is responsible for some basic
+ initializations, such as enabling peripherals and configuring
+ pinmuxes. The psu_init_gpl.c file (and, optionally,
+ psu_init_gpl.h), generated by the Xilinx development tools,
+ contains the code for such initializations.
+
+ Although U-Boot contains psu_init_gpl.c files for some boards,
+ each of them describes only one specific configuration. Users of
+ a different board, or needing a different configuration, can
+ provide a different file here, and U-Boot will build and link
+ the user-provided file instead of the built-in one.
+
+ Set this variable to the path where the psu_init_gpl.c file (and
+ psu_init_gpl.h if needed) is located. Leave empty to use the
+ files provided by U-Boot.
+
+endif
+
config BR2_TARGET_UBOOT_ALTERA_SOCFPGA_IMAGE_CRC
bool "CRC image for Altera SoC FPGA (mkpimage)"
depends on BR2_arm
diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
index e81a9fd41dab..38d3c4019ee9 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -289,6 +289,18 @@ define UBOOT_ZYNQMP_COPY_PMUFW
endef
UBOOT_PRE_CONFIGURE_HOOKS += UBOOT_ZYNQMP_COPY_PMUFW
+ifneq ($(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR)),)
+define UBOOT_ZYNQMP_COPY_PSU_INIT
+# In U-Boot's board/xilinx/zynqmp/Makefile the bundled psu_init_gpl.c
+# has precedence over ours if placed in a subdir whose name matches
+# CONFIG_DEFAULT_DEVICE_TREE. Delete them all to be sure we use ours.
+ rm -f $(@D)/board/xilinx/zynqmp/*/psu_init*.[ch]
+ cp $(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR))/psu_init_gpl.[ch] \
+ $(@D)/board/xilinx/zynqmp/
+endef
+UBOOT_PRE_CONFIGURE_HOOKS += UBOOT_ZYNQMP_COPY_PSU_INIT
+endif # BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR
+
endif # BR2_TARGET_UBOOT_ZYNQMP
define UBOOT_INSTALL_OMAP_IFT_IMAGE
--
2.7.4
^ permalink raw reply related [flat|nested] 14+ messages in thread* [Buildroot] [PATCH v2-RESEND 6/6] configs: add Xilinx ZCU106 board (ZynqMP SoC)
2018-04-06 16:34 [Buildroot] [PATCH v2-RESEND 0/6] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
` (4 preceding siblings ...)
2018-04-06 16:34 ` [Buildroot] [PATCH v2-RESEND 5/6] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
@ 2018-04-06 16:34 ` Luca Ceresoli
5 siblings, 0 replies; 14+ messages in thread
From: Luca Ceresoli @ 2018-04-06 16:34 UTC (permalink / raw)
To: buildroot
This adds support the Xilinx ZCU106 development board.
Mainline U-Boot does not have a zcu106 defconfig, so iet's use U-Boot
from the Xilinx master branch, which has one. But since that defconfig
does not boot from SD card, add two patches to fix that.
[Tested on the ES2 (Engineering Sample 2) version of the board]
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Changes v1 -> v2:
- don't provide psu_init files: the xilinx master branch has a
defconfig that works (with 2 patches)
---
DEVELOPERS | 2 +
board/zynqmp/genimage.cfg | 28 +++++++++++
...1-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch | 56 ++++++++++++++++++++++
...arm64-zynqmp-zcu106-enable-booting-to-ATF.patch | 39 +++++++++++++++
board/zynqmp/post-image.sh | 13 +++++
board/zynqmp/readme.txt | 52 ++++++++++++++++++++
configs/zynqmp_zcu106_defconfig | 31 ++++++++++++
7 files changed, 221 insertions(+)
create mode 100644 board/zynqmp/genimage.cfg
create mode 100644 board/zynqmp/patches/uboot/0001-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch
create mode 100644 board/zynqmp/patches/uboot/0002-arm64-zynqmp-zcu106-enable-booting-to-ATF.patch
create mode 100755 board/zynqmp/post-image.sh
create mode 100644 board/zynqmp/readme.txt
create mode 100644 configs/zynqmp_zcu106_defconfig
diff --git a/DEVELOPERS b/DEVELOPERS
index eb4781c1e3cd..228a731a9de6 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1070,8 +1070,10 @@ F: package/ti-sgx-um/
N: Luca Ceresoli <luca@lucaceresoli.net>
F: board/olimex/a20_olinuxino/
+F: board/zynqmp/
F: boot/zynqmp-pmufw-binaries/
F: configs/olimex_a20_olinuxino_*
+F: configs/zynqmp_zcu106_defconfig
F: package/agentpp/
F: package/exim/
F: package/libpjsip/
diff --git a/board/zynqmp/genimage.cfg b/board/zynqmp/genimage.cfg
new file mode 100644
index 000000000000..30be086d7d42
--- /dev/null
+++ b/board/zynqmp/genimage.cfg
@@ -0,0 +1,28 @@
+image boot.vfat {
+ vfat {
+ files = {
+ "boot.bin",
+ "u-boot.bin",
+ "atf-uboot.ub",
+ "system.dtb",
+ "Image"
+ }
+ }
+ size = 32M
+}
+
+image sdcard.img {
+ hdimage {
+ }
+
+ partition boot {
+ partition-type = 0xC
+ bootable = "true"
+ image = "boot.vfat"
+ }
+
+ partition rootfs {
+ partition-type = 0x83
+ image = "rootfs.ext4"
+ }
+}
diff --git a/board/zynqmp/patches/uboot/0001-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch b/board/zynqmp/patches/uboot/0001-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch
new file mode 100644
index 000000000000..a3c7b6265616
--- /dev/null
+++ b/board/zynqmp/patches/uboot/0001-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch
@@ -0,0 +1,56 @@
+From e5d72ed8339eb05285448aad3c89d21e4d18fd29 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca@lucaceresoli.net>
+Date: Mon, 26 Feb 2018 09:40:34 +0100
+Subject: [PATCH 1/2] arm64: zynqmp: zcu106: fix SPL MMC booting
+
+The U-Boot SPL generated with the current zcu106 defconfig cannot boot
+from MMC:
+
+ [...]
+ U-Boot SPL 2018.01 (Feb 21 2018 - 17:47:14)
+ EL Level: EL3
+ Trying to boot from MMC1
+ sdhci_transfer_data: Error detected in status(0x408020)!
+ spl_load_image_fat_os: error reading image u-boot.bin, err - -2
+ spl_load_image_fat: error reading image u-boot.img, err - -6
+ SPL: failed to boot from all boot devices
+ ### ERROR ### Please RESET the board ###
+
+Fix by lowering the rpll value. The new value for the RPLL_CTRL
+register comes from the current psu_init_gpl.c from the HDF file at
+https://github.com/xilinx/hdf-examples/tree/01ad8ea5fd1989abf4ea5a072d019a16cb2bc546/zcu106-zynqmp
+(generated by Vivado v2017.4).
+
+RPLL and sdio1_ref clocks before and after this change:
+
+ - Old values: RPLL 1.36 GHz, sdio1_ref 272 MHz
+ - New values: RPLL 1.16 GHz, sdio1_ref 233 MHz
+
+Patch submitted upstream.
+
+Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
+Cc: Michal Simek <michal.simek@xilinx.com>
+
+---
+Changes v1 -> v2:
+ - add old/new clocks to commit message (Michal).
+---
+ board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c b/board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c
+index 4d18abe000ca..e6fa477e53e7 100644
+--- a/board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c
++++ b/board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c
+@@ -10,7 +10,7 @@
+ static unsigned long psu_pll_init_data(void)
+ {
+ psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4E2C62U);
+- psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00013C00U);
++ psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00014600U);
+ psu_mask_write(0xFF5E0030, 0x00000008U, 0x00000008U);
+ psu_mask_write(0xFF5E0030, 0x00000001U, 0x00000001U);
+ psu_mask_write(0xFF5E0030, 0x00000001U, 0x00000000U);
+--
+2.7.4
+
diff --git a/board/zynqmp/patches/uboot/0002-arm64-zynqmp-zcu106-enable-booting-to-ATF.patch b/board/zynqmp/patches/uboot/0002-arm64-zynqmp-zcu106-enable-booting-to-ATF.patch
new file mode 100644
index 000000000000..df6a57eb1667
--- /dev/null
+++ b/board/zynqmp/patches/uboot/0002-arm64-zynqmp-zcu106-enable-booting-to-ATF.patch
@@ -0,0 +1,39 @@
+From 2e3b94597550501a58488504ad506ba50074aecd Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca@lucaceresoli.net>
+Date: Wed, 7 Mar 2018 18:29:26 +0100
+Subject: [PATCH 2/2] arm64: zynqmp: zcu106: enable booting to ATF
+
+U-Boot is now able to boot to ARM Trusted Firmware (ATF). The boot
+flow is SPL(EL3) loads ATF and full u-boot and jump to ATF(EL3) which
+pass control to full u-boot(EL2). This has been tested on zcu106, so
+enable it in this defconfig.
+
+To generate an image that triggers this booting flow, you need to pass
+'-O arm-trusted-firmware' to mkimage.
+
+Patch submitted upstream.
+
+Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
+Cc: Michal Simek <michal.simek@xilinx.com>
+
+---
+Changes v1 -> v2: none.
+---
+ configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/configs/xilinx_zynqmp_zcu106_revA_defconfig b/configs/xilinx_zynqmp_zcu106_revA_defconfig
+index 71da160cd78b..0575ee00fd8b 100644
+--- a/configs/xilinx_zynqmp_zcu106_revA_defconfig
++++ b/configs/xilinx_zynqmp_zcu106_revA_defconfig
+@@ -27,6 +27,7 @@ CONFIG_SPL=y
+ CONFIG_SPL_OS_BOOT=y
+ CONFIG_SPL_RAM_SUPPORT=y
+ CONFIG_SPL_RAM_DEVICE=y
++CONFIG_SPL_ATF=y
+ CONFIG_SYS_PROMPT="ZynqMP> "
+ CONFIG_FASTBOOT=y
+ CONFIG_FASTBOOT_FLASH=y
+--
+2.7.4
+
diff --git a/board/zynqmp/post-image.sh b/board/zynqmp/post-image.sh
new file mode 100755
index 000000000000..2e7bcbaab60f
--- /dev/null
+++ b/board/zynqmp/post-image.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+# By default U-Boot loads DTB from a file named "system.dtb", so
+# let's use a symlink with that name that points to the *first*
+# devicetree listed in the config.
+
+FIRST_DT=$(sed -nr \
+ -e 's|^BR2_LINUX_KERNEL_INTREE_DTS_NAME="xilinx/([-_/[:alnum:]]*).*"$|\1|p' \
+ ${BR2_CONFIG})
+
+[ -z "${FIRST_DT}" ] || ln -fs ${FIRST_DT}.dtb ${BINARIES_DIR}/system.dtb
+
+support/scripts/genimage.sh -c board/zynqmp/genimage.cfg
diff --git a/board/zynqmp/readme.txt b/board/zynqmp/readme.txt
new file mode 100644
index 000000000000..18d0491add21
--- /dev/null
+++ b/board/zynqmp/readme.txt
@@ -0,0 +1,52 @@
+********************************
+Xilinx ZCU106 board - ZynqMP SoC
+********************************
+
+This document describes the Buildroot support for the ZCU106 board by
+Xilinx, based on the Zynq UltraScale+ MPSoC (aka ZynqMP). It has been
+tested with the EK-U1-ZCU106-ES2 pre-production board.
+
+How to build it
+===============
+
+Configure Buildroot:
+
+ $ make zynqmp_zcu106_defconfig
+
+Compile everything and build the rootfs image:
+
+ $ make
+
+Result of the build
+-------------------
+
+After building, you should get a tree like this:
+
+ output/images/
+ +-- atf-uboot.ub
+ +-- bl31.bin
+ +-- boot.bin
+ +-- boot.vfat
+ +-- Image
+ +-- pmufw.bin
+ +-- rootfs.ext2
+ +-- rootfs.ext4 -> rootfs.ext2
+ +-- sdcard.img
+ +-- system.dtb -> zynqmp-zcu106-revA.dtb
+ +-- u-boot.bin
+ `-- zynqmp-zcu106-revA.dtb
+
+How to write the SD card
+========================
+
+WARNING! This will destroy all the card content. Use with care!
+
+The sdcard.img file is a complete bootable image ready to be written
+on the boot medium. To install it, simply copy the image to an SD
+card:
+
+ # dd if=output/images/sdcard.img of=/dev/sdX
+
+Where 'sdX' is the device node of the SD.
+
+Eject the SD card, insert it in the board, and power it up.
diff --git a/configs/zynqmp_zcu106_defconfig b/configs/zynqmp_zcu106_defconfig
new file mode 100644
index 000000000000..cf8f2b14a971
--- /dev/null
+++ b/configs/zynqmp_zcu106_defconfig
@@ -0,0 +1,31 @@
+BR2_aarch64=y
+BR2_GLOBAL_PATCH_DIR="board/zynqmp/patches/"
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/zynqmp/post-image.sh"
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_GIT=y
+BR2_LINUX_KERNEL_CUSTOM_REPO_URL="git://github.com/Xilinx/linux-xlnx.git"
+BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="xilinx-v2017.4"
+BR2_LINUX_KERNEL_DEFCONFIG="xilinx_zynqmp"
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="xilinx/zynqmp-zcu106-revA"
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+# BR2_TARGET_ROOTFS_TAR is not set
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="zynqmp"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_ZYNQMP_UB_MKIMAGE=y
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_GIT=y
+BR2_TARGET_UBOOT_CUSTOM_REPO_URL="git://github.com/xilinx/u-boot-xlnx.git"
+BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="228801a215909365ae1dcdd799034195ad7264f7"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="xilinx_zynqmp_zcu106_revA"
+BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME="spl/boot.bin"
+BR2_TARGET_UBOOT_ZYNQMP=y
+BR2_TARGET_ZYNQMP_PMUFW_BINARIES_IMAGE="zcu106-default/pmufw.bin"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
--
2.7.4
^ permalink raw reply related [flat|nested] 14+ messages in thread