All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support
@ 2018-05-03 16:23 Luca Ceresoli
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path Luca Ceresoli
                   ` (4 more replies)
  0 siblings, 5 replies; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:23 UTC (permalink / raw)
  To: buildroot

Hi,

this patchset adds basic support for the ZynqMP family of ARM64
SoC+FPGA by Xilinx and for the ZCU106 board based on it.

This v3 addresses the comments received to v2 (thanks Thomas). The
main change is that the zynqmp-pmufw-binaries package does not exist
anymore: instead U-Boot downloads a single file using
EXTRA_DOWNLOADS. The rest are several sparse improvements that make
the whole work a lot cleaner.

The ZynqMP sets a few challenges that needed some work besides the
usual defconfig + readme that is enough for more classic and simple
SoCs.

First, it requires ARM Trusted Firmware in the U-Boot mkimage format,
not currently implemented. Nothing really hard here, this is addressed
in patch 2 (with a trivial preliminary cleanup in patch 1).

Patch 3 allows to pass an externally-supplied init file to U-Boot,
which is needed to boot boards not supported in the U-Boot source
code, or on the same boards but with a different configuration.

The next issue is the PMU (Platform Management Unit). It is a
Microblaze core that handles power and clock gating and the like, and
reprogramming it at runtime is necessary to boot any modern U-Boot and
Linux. Since we can't build Microblaze code out of the ARM64
toolchain, U-Boot obtains a pre-built binary using
EXTRA_DOWNLOADS. This is added in patch 4.

With all these in place, patch 5 just adds the defconfig and board
files.

Luca

Luca Ceresoli (5):
  arm-trusted-firmware: simplify release dir path
  arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin
  uboot: zynqmp: allow to use custom psu_init files
  uboot: zynqmp: generate SPL image with PMUFW binary
  configs: add Xilinx ZCU106 board (ZynqMP SoC)

 DEVELOPERS                                         |   2 +
 board/zynqmp/genimage.cfg                          |  28 +++++
 ...1-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch |  53 ++++++++++
 .../0002-arm64-zynqmp-Enable-booting-to-ATF.patch  | 115 +++++++++++++++++++++
 board/zynqmp/post-image.sh                         |  13 +++
 board/zynqmp/readme.txt                            |  52 ++++++++++
 boot/arm-trusted-firmware/Config.in                |   8 ++
 boot/arm-trusted-firmware/arm-trusted-firmware.mk  |  24 ++++-
 boot/uboot/Config.in                               |  43 ++++++++
 boot/uboot/uboot.mk                                |  35 +++++++
 configs/zynqmp_zcu106_defconfig                    |  31 ++++++
 11 files changed, 403 insertions(+), 1 deletion(-)
 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-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

-- 
2.7.4

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path
  2018-05-03 16:23 [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
@ 2018-05-03 16:23 ` Luca Ceresoli
  2018-05-04  7:14   ` Gary Bisson
  2018-05-28 20:34   ` Thomas Petazzoni
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 2/5] arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin Luca Ceresoli
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:23 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 v2 -> v3: none.
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] 20+ messages in thread
* [Buildroot] [PATCH v3 2/5] arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin
  2018-05-03 16:23 [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path Luca Ceresoli
@ 2018-05-03 16:23 ` Luca Ceresoli
  2018-05-28 20:46   ` Thomas Petazzoni
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:23 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 v2 -> v3 (Thomas):
 - Make the option not ZynqMP-specific
 - Simplify the grep+sed expression to extract the entry point address
 - Rather than hooks, just use directly BUILD_CMDS and INSTALL_IMAGES_CMDS
 - Use $(INSTALL), not install

Changes v1 -> v2: none.
---
 boot/arm-trusted-firmware/Config.in               |  8 ++++++++
 boot/arm-trusted-firmware/arm-trusted-firmware.mk | 21 +++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/boot/arm-trusted-firmware/Config.in b/boot/arm-trusted-firmware/Config.in
index 7aef87cb746c..885d93e62f47 100644
--- a/boot/arm-trusted-firmware/Config.in
+++ b/boot/arm-trusted-firmware/Config.in
@@ -71,6 +71,14 @@ 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_BL31_UBOOT
+	bool "Build BL31 U-Boot image"
+	select BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31
+	help
+	  Generates a U-Boot image named atf-uboot.ub containing
+	  bl31.bin.  This is used for example 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..054a000a1dd3 100644
--- a/boot/arm-trusted-firmware/arm-trusted-firmware.mk
+++ b/boot/arm-trusted-firmware/arm-trusted-firmware.mk
@@ -75,15 +75,36 @@ ifeq ($(BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31),y)
 ARM_TRUSTED_FIRMWARE_MAKE_TARGETS += bl31
 endif
 
+ifeq ($(BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31_UBOOT),y)
+define ARM_TRUSTED_FIRMWARE_BL31_UBOOT_BUILD
+# Get the entry point address from the elf.
+	BASE_ADDR=$$($(TARGET_READELF) -h $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/bl31/bl31.elf | \
+	             sed -r '/^  Entry point address:\s*(.*)/!d; s//\1/') && \
+	$(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_BL31_UBOOT_INSTALL
+	$(INSTALL) -m 0644 $(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
+endif
+
 define ARM_TRUSTED_FIRMWARE_BUILD_CMDS
 	$(ARM_TRUSTED_FIRMWARE_BUILD_FIPTOOL)
 	$(TARGET_CONFIGURE_OPTS) \
 		$(MAKE) -C $(@D) $(ARM_TRUSTED_FIRMWARE_MAKE_OPTS) \
 			$(ARM_TRUSTED_FIRMWARE_MAKE_TARGETS)
+	$(ARM_TRUSTED_FIRMWARE_BL31_UBOOT_BUILD)
 endef
 
 define ARM_TRUSTED_FIRMWARE_INSTALL_IMAGES_CMDS
 	cp -dpf $(ARM_TRUSTED_FIRMWARE_IMG_DIR)/*.bin $(BINARIES_DIR)/
+	$(ARM_TRUSTED_FIRMWARE_BL31_UBOOT_INSTALL)
 endef
 
 # Configuration check
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files
  2018-05-03 16:23 [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path Luca Ceresoli
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 2/5] arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin Luca Ceresoli
@ 2018-05-03 16:23 ` Luca Ceresoli
  2018-05-28 20:49   ` Thomas Petazzoni
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
  4 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:23 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 v2 -> v3:
 - Add a bool option to show/hidw all ZynqMP-specific config knobs
 - Move this patch before "uboot: zynqmp: generate SPL image with
   PMUFW binary"
 - Reword Config.in text

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 | 30 ++++++++++++++++++++++++++++++
 boot/uboot/uboot.mk  | 16 ++++++++++++++++
 2 files changed, 46 insertions(+)

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index 95c17e39865e..adde4040e55b 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -365,6 +365,36 @@ 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
+	help
+	  Enable options specific to the Xilinx ZynqMP family of SoCs.
+
+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) 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 generate custom files using the
+	  Xilinx development tools.
+
+	  Set this variable to the path where the psu_init_gpl.c file
+	  (and psu_init_gpl.h if needed) is located. U-Boot will build
+	  and link the user-provided file instead of the built-in
+	  one. 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 03bd7ea743ed..cbb899515181 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -274,6 +274,22 @@ define UBOOT_INSTALL_IMAGES_CMDS
 			$(BINARIES_DIR)/boot.scr)
 endef
 
+ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
+
+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
 	cp -dpf $(@D)/$(UBOOT_BIN_IFT) $(BINARIES_DIR)/
 endef
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary
  2018-05-03 16:23 [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
                   ` (2 preceding siblings ...)
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
@ 2018-05-03 16:23 ` Luca Ceresoli
  2018-05-28 20:53   ` Thomas Petazzoni
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
  4 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:23 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, and the boot ROM will load
both.

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>

---
Changes v2 -> v3:
 - don't use a "zynqmp-pmufw-binaries" package, just download a file
 - define kconfig fixups in a variable, then define
   UBOOT_KCONFIG_FIXUP_CMDS unconditionally at global scope (Thomas)
 - use $(INSTALL), not cp (Thomas)
 - $(...) instead of ${...} to reference make variables (Thomas)

Changes v1 -> v2:
 - split from a larger patch doing 2 things.
---
 boot/uboot/Config.in | 13 +++++++++++++
 boot/uboot/uboot.mk  | 19 +++++++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index adde4040e55b..948d09a65f42 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -373,6 +373,19 @@ config BR2_TARGET_UBOOT_ZYNQMP
 
 if BR2_TARGET_UBOOT_ZYNQMP
 
+config BR2_TARGET_UBOOT_ZYNQMP_PMUFW
+	string "PMU firmware location"
+	help
+	  Location of a PMU firmware binary.
+
+	  If set to an URL or a file path, instructs the U-Boot build
+	  process to generate a boot.bin (to be loaded by the ZynqMP
+	  boot ROM) containing both the U-Boot SPL and the PMU
+	  firmware in the Xilinx-specific boot format.
+
+	  If empty, the generated boot.bin will not contain a PMU
+	  firmware.
+
 config BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR
 	string "Custom psu_init_gpl files"
 	help
diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
index cbb899515181..266e42698d1b 100644
--- a/boot/uboot/uboot.mk
+++ b/boot/uboot/uboot.mk
@@ -276,6 +276,21 @@ endef
 
 ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
 
+UBOOT_ZYNQMP_PMUFW = $(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PMUFW))
+
+ifneq ($(UBOOT_ZYNQMP_PMUFW),)
+UBOOT_EXTRA_DOWNLOADS += $(UBOOT_ZYNQMP_PMUFW)
+BR_NO_CHECK_HASH_FOR += $(notdir $(UBOOT_ZYNQMP_PMUFW))
+define UBOOT_ZYNQMP_KCONFIG_FIXUP
+	$(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,"board/xilinx/zynqmp/pmufw.bin",$(@D)/.config)
+endef
+define UBOOT_ZYNQMP_COPY_PMUFW
+	$(INSTALL) -D -m 0644 $(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)) \
+		$(@D)/board/xilinx/zynqmp/pmufw.bin
+endef
+UBOOT_PRE_CONFIGURE_HOOKS += UBOOT_ZYNQMP_COPY_PMUFW
+endif # UBOOT_ZYNQMP_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
@@ -339,6 +354,10 @@ UBOOT_DEPENDENCIES += host-mkpimage
 UBOOT_POST_INSTALL_IMAGES_HOOKS += UBOOT_CRC_ALTERA_SOCFPGA_IMAGE
 endif
 
+define UBOOT_KCONFIG_FIXUP_CMDS
+	$(UBOOT_ZYNQMP_KCONFIG_FIXUP)
+endef
+
 ifeq ($(BR2_TARGET_UBOOT_ENVIMAGE),y)
 ifeq ($(BR_BUILDING),y)
 ifeq ($(call qstrip,$(BR2_TARGET_UBOOT_ENVIMAGE_SOURCE)),)
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC)
  2018-05-03 16:23 [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
                   ` (3 preceding siblings ...)
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
@ 2018-05-03 16:23 ` Luca Ceresoli
  2018-05-28 20:55   ` Thomas Petazzoni
  4 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-03 16:23 UTC (permalink / raw)
  To: buildroot

This adds support the Xilinx ZCU106 development board.

[Tested on the ES2 (Engineering Sample 2) version of the board]
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>

---
Changes v2 -> v3:
 - adapt to changed ATF option name
   (BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL31_UBOOT)
 - adapt to the new pmufw implementation in uboot (no
   zynqmp-pmufw-binaries package, just a downloadable file)
 - patches now upstream, update patch files

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 |  53 ++++++++++
 .../0002-arm64-zynqmp-Enable-booting-to-ATF.patch  | 115 +++++++++++++++++++++
 board/zynqmp/post-image.sh                         |  13 +++
 board/zynqmp/readme.txt                            |  52 ++++++++++
 configs/zynqmp_zcu106_defconfig                    |  31 ++++++
 7 files changed, 294 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-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 24d134cb70f9..d68be6f3602d 100644
--- a/DEVELOPERS
+++ b/DEVELOPERS
@@ -1100,8 +1100,10 @@ F:	package/ti-sgx-um/
 N:	Luca Ceresoli <luca@lucaceresoli.net>
 F:	board/olimex/a20_olinuxino/
 F:	board/zynq/
+F:	board/zynqmp/
 F:	configs/olimex_a20_olinuxino_*
 F:	configs/zynq_zed_defconfig
+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..60dd1465590a
--- /dev/null
+++ b/board/zynqmp/patches/uboot/0001-arm64-zynqmp-zcu106-fix-SPL-MMC-booting.patch
@@ -0,0 +1,53 @@
+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
+
+Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
+Cc: Michal Simek <michal.simek@xilinx.com>
+
+---
+Patch accepted upstream in a different form.
+
+ 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-Enable-booting-to-ATF.patch b/board/zynqmp/patches/uboot/0002-arm64-zynqmp-Enable-booting-to-ATF.patch
new file mode 100644
index 000000000000..62a59a5e7586
--- /dev/null
+++ b/board/zynqmp/patches/uboot/0002-arm64-zynqmp-Enable-booting-to-ATF.patch
@@ -0,0 +1,115 @@
+From 5e3cac50cc981e01d9072241035a8d4162560c71 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca@lucaceresoli.net>
+Date: Mon, 12 Mar 2018 17:18:38 +0100
+Subject: [PATCH] arm64: zynqmp: 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.
+
+Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
+Signed-off-by: Michal Simek <michal.simek@xilinx.com>
+---
+Fetch from:
+http://git.denx.de/?p=u-boot.git;a=commit;h=5e3cac50cc981e01d9072241035a8d4162560c71
+
+ configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
+ configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
+ configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
+ configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
+ configs/xilinx_zynqmp_zcu102_rev1_0_defconfig    | 1 +
+ configs/xilinx_zynqmp_zcu102_revA_defconfig      | 1 +
+ configs/xilinx_zynqmp_zcu102_revB_defconfig      | 1 +
+ 7 files changed, 7 insertions(+)
+
+diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+index c5bfa2b12638..488c72258b0e 100644
+--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
++++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+@@ -19,6 +19,7 @@ CONFIG_BOARD_EARLY_INIT_R=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
+diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+index f86dce403a42..5d501eec0edd 100644
+--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
++++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+@@ -20,6 +20,7 @@ CONFIG_BOARD_EARLY_INIT_R=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
+diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
+index 6e947cf56827..6f7eaebd7676 100644
+--- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
++++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
+@@ -16,6 +16,7 @@ CONFIG_BOARD_EARLY_INIT_R=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_CMD_MEMTEST=y
+ CONFIG_SYS_ALT_MEMTEST=y
+diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+index 1c934858c61c..7a3806cba4b5 100644
+--- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
++++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+@@ -17,6 +17,7 @@ CONFIG_BOARD_EARLY_INIT_R=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_CMD_MEMTEST=y
+ CONFIG_SYS_ALT_MEMTEST=y
+diff --git a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
+index e13c7c56f310..e4408f182ca0 100644
+--- a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
++++ b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
+@@ -19,6 +19,7 @@ CONFIG_BOARD_EARLY_INIT_R=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
+diff --git a/configs/xilinx_zynqmp_zcu102_revA_defconfig b/configs/xilinx_zynqmp_zcu102_revA_defconfig
+index 5b2cd495ee85..b52f6789fd4b 100644
+--- a/configs/xilinx_zynqmp_zcu102_revA_defconfig
++++ b/configs/xilinx_zynqmp_zcu102_revA_defconfig
+@@ -19,6 +19,7 @@ CONFIG_BOARD_EARLY_INIT_R=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
+diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig b/configs/xilinx_zynqmp_zcu102_revB_defconfig
+index e6530fbfe7ff..80592554f682 100644
+--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
++++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
+@@ -19,6 +19,7 @@ CONFIG_BOARD_EARLY_INIT_R=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..36643b2f4cdd
--- /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_BL31_UBOOT=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_UBOOT_ZYNQMP_PMUFW="https://github.com/lucaceresoli/zynqmp-pmufw-binaries/raw/416bf2e1b625993a2fb9fc14924ffe2247d5a0c2/bin/pmufw-zcu106-default-v2017.1.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] 20+ messages in thread
* [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path Luca Ceresoli
@ 2018-05-04  7:14   ` Gary Bisson
  2018-05-04 13:46     ` Luca Ceresoli
  2018-05-28 20:34   ` Thomas Petazzoni
  1 sibling, 1 reply; 20+ messages in thread
From: Gary Bisson @ 2018-05-04  7:14 UTC (permalink / raw)
  To: buildroot

Hi Luca,

On Thu, May 03, 2018 at 06:23:33PM +0200, Luca Ceresoli wrote:
> 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 v2 -> v3: none.
> 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)/

Actually the release folder isn't always in that directory. For
instance, the tegra platform requires another TARGET_SOC variable and
the bin files are under
build/$(ARM_TRUSTED_FIRMWARE_PLATFORM)/$(TARGET_SOC)/release/*.bin.
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/nvidia-tegra.rst

Don't get me wrong, your patch doesn't break anything, I just wanted to
inform you of that tegra case. My quick (and dirty) fix was to do a the
following:
find $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM) -name "*.bin" -exec cp -dpf {} $(BINARIES_DIR)/ \;

But if you want to have a generic ARM_TRUSTED_FIRMWARE_IMG_DIR I guess
the solution is to have an optional ARM_TRUSTED_FIRMWARE_TARGET_SOC
variable added to arm-trusted-firmware.mk.

Regards,
Gary

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path
  2018-05-04  7:14   ` Gary Bisson
@ 2018-05-04 13:46     ` Luca Ceresoli
  2018-05-04 15:05       ` Gary Bisson
  0 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-04 13:46 UTC (permalink / raw)
  To: buildroot

Hi Gary,

On 04/05/2018 09:14, Gary Bisson wrote:
> Hi Luca,
> 
> On Thu, May 03, 2018 at 06:23:33PM +0200, Luca Ceresoli wrote:
>> 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 v2 -> v3: none.
>> 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)/
> 
> Actually the release folder isn't always in that directory. For
> instance, the tegra platform requires another TARGET_SOC variable and
> the bin files are under
> build/$(ARM_TRUSTED_FIRMWARE_PLATFORM)/$(TARGET_SOC)/release/*.bin.
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/nvidia-tegra.rst
> 
> Don't get me wrong, your patch doesn't break anything, I just wanted to
> inform you of that tegra case. My quick (and dirty) fix was to do a the
> following:
> find $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM) -name "*.bin" -exec cp -dpf {} $(BINARIES_DIR)/ \;

So if I understood correctly the current .mk file would not work for
tegra, both with and without my patch.

Also your 'find' solution cannot work from ARM_TRUSTED_FIRMWARE_IMG_DIR
as I defined it, because of the added '/release' dir.

> But if you want to have a generic ARM_TRUSTED_FIRMWARE_IMG_DIR I guess
> the solution is to have an optional ARM_TRUSTED_FIRMWARE_TARGET_SOC
> variable added to arm-trusted-firmware.mk.

Well, using 'find' would be a simpler trick without clobbering the
Config.in space. But then in patch 2 I use ARM_TRUSTED_FIRMWARE_IMG_DIR
in several places, and using plain 'find' there would introduce
additional problems.

Do you think there is a way to extract the TARGET_SOC value
automatically, in order to avoid yet another Config.in variable in ATF?
I'm afraid I'm not optimistic on this...

An alternative, under the assumption that only one *.bin file is
generated, is: find that file wherever it is, and use the path to it
everywhere to reference to it. Pseudocode (perhaps better done in pure
make):

  ARM_TRUSTED_FIRMWARE_IMG = $(dir $(shell \
    find $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM) -name "*.bin" | \
    head -n1))

This would avoid any additional variables and give us the path of the
binary. Do you think it could work?

-- 
Luca

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path
  2018-05-04 13:46     ` Luca Ceresoli
@ 2018-05-04 15:05       ` Gary Bisson
  0 siblings, 0 replies; 20+ messages in thread
From: Gary Bisson @ 2018-05-04 15:05 UTC (permalink / raw)
  To: buildroot

Hi Luca,

On Fri, May 04, 2018 at 03:46:06PM +0200, Luca Ceresoli wrote:
> Hi Gary,
> 
> On 04/05/2018 09:14, Gary Bisson wrote:
> > Hi Luca,
> > 
> > On Thu, May 03, 2018 at 06:23:33PM +0200, Luca Ceresoli wrote:
> >> 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 v2 -> v3: none.
> >> 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)/
> > 
> > Actually the release folder isn't always in that directory. For
> > instance, the tegra platform requires another TARGET_SOC variable and
> > the bin files are under
> > build/$(ARM_TRUSTED_FIRMWARE_PLATFORM)/$(TARGET_SOC)/release/*.bin.
> > https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/nvidia-tegra.rst
> > 
> > Don't get me wrong, your patch doesn't break anything, I just wanted to
> > inform you of that tegra case. My quick (and dirty) fix was to do a the
> > following:
> > find $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM) -name "*.bin" -exec cp -dpf {} $(BINARIES_DIR)/ \;
> 
> So if I understood correctly the current .mk file would not work for
> tegra, both with and without my patch.

Exactly.

> Also your 'find' solution cannot work from ARM_TRUSTED_FIRMWARE_IMG_DIR
> as I defined it, because of the added '/release' dir.

Yes, that is why I bring it up here. I planned on sending that 'find'
trick as a RFC although I don't expect that solution to be accepted.

> > But if you want to have a generic ARM_TRUSTED_FIRMWARE_IMG_DIR I guess
> > the solution is to have an optional ARM_TRUSTED_FIRMWARE_TARGET_SOC
> > variable added to arm-trusted-firmware.mk.
> 
> Well, using 'find' would be a simpler trick without clobbering the
> Config.in space. But then in patch 2 I use ARM_TRUSTED_FIRMWARE_IMG_DIR
> in several places, and using plain 'find' there would introduce
> additional problems.

Yes. And to be honest, there's no real Tegra support in Buildroot right
now so I'm not against your series. Just wanted people to know about
that case.

> Do you think there is a way to extract the TARGET_SOC value
> automatically, in order to avoid yet another Config.in variable in ATF?
> I'm afraid I'm not optimistic on this...

Me neither, I don't see a way to extract the TARGET_SOC.

> An alternative, under the assumption that only one *.bin file is
> generated, is: find that file wherever it is, and use the path to it
> everywhere to reference to it. Pseudocode (perhaps better done in pure
> make):
> 
>   ARM_TRUSTED_FIRMWARE_IMG = $(dir $(shell \
>     find $(@D)/build/$(ARM_TRUSTED_FIRMWARE_PLATFORM) -name "*.bin" | \
>     head -n1))
> 
> This would avoid any additional variables and give us the path of the
> binary. Do you think it could work?

Yes I think that would work but I'm not fond of that 'find' command in
the first place. In my opinion having a TARGET_SOC variable, even if
empty for most platforms, is a more elegant solution.

But, I've CC'd Sergey to help in that decision process since he's the
one maintaining the package.

Regards,
Gary

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path Luca Ceresoli
  2018-05-04  7:14   ` Gary Bisson
@ 2018-05-28 20:34   ` Thomas Petazzoni
  1 sibling, 0 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2018-05-28 20:34 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu,  3 May 2018 18:23:33 +0200, Luca Ceresoli wrote:
> 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 v2 -> v3: none.
> Changes v1 -> v2: none.
> ---
>  boot/arm-trusted-firmware/arm-trusted-firmware.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied to next, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 2/5] arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 2/5] arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin Luca Ceresoli
@ 2018-05-28 20:46   ` Thomas Petazzoni
  0 siblings, 0 replies; 20+ messages in thread
From: Thomas Petazzoni @ 2018-05-28 20:46 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu,  3 May 2018 18:23:34 +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 v2 -> v3 (Thomas):
>  - Make the option not ZynqMP-specific
>  - Simplify the grep+sed expression to extract the entry point address
>  - Rather than hooks, just use directly BUILD_CMDS and INSTALL_IMAGES_CMDS
>  - Use $(INSTALL), not install

Applied to next, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
@ 2018-05-28 20:49   ` Thomas Petazzoni
  2018-05-29 20:45     ` Luca Ceresoli
  0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2018-05-28 20:49 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu,  3 May 2018 18:23:35 +0200, Luca Ceresoli wrote:

> +ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
> +
> +ifneq ($(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR)),)

It'd be nice to have an intermediate UBOOT_ZYNQMP_PSU_INIT_DIR variable
instead of calculating its qstripped value twice.

> +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/

However, the bigger question is why do we need this in the first
place ? This is in fact just patching the U-Boot source code. Why not
use a patch instead ? Aren't people in general anyway going to have
their own custom U-Boot Git tree, in which they will version control
their psu_init files ?

Since this really looks like a specialized patching step, I'm not sure
it really makes sense to add this. Unless you can convince me
otherwise :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
@ 2018-05-28 20:53   ` Thomas Petazzoni
  2018-05-29 20:46     ` Luca Ceresoli
  0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2018-05-28 20:53 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu,  3 May 2018 18:23:36 +0200, Luca Ceresoli wrote:
> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
> index cbb899515181..266e42698d1b 100644
> --- a/boot/uboot/uboot.mk
> +++ b/boot/uboot/uboot.mk
> @@ -276,6 +276,21 @@ endef
>  
>  ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
>  
> +UBOOT_ZYNQMP_PMUFW = $(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PMUFW))
> +
> +ifneq ($(UBOOT_ZYNQMP_PMUFW),)
> +UBOOT_EXTRA_DOWNLOADS += $(UBOOT_ZYNQMP_PMUFW)
> +BR_NO_CHECK_HASH_FOR += $(notdir $(UBOOT_ZYNQMP_PMUFW))
> +define UBOOT_ZYNQMP_KCONFIG_FIXUP
> +	$(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,"board/xilinx/zynqmp/pmufw.bin",$(@D)/.config)
> +endef
> +define UBOOT_ZYNQMP_COPY_PMUFW
> +	$(INSTALL) -D -m 0644 $(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)) \
> +		$(@D)/board/xilinx/zynqmp/pmufw.bin
> +endef

I'm wondering if your solution that consists in copying the PMU
firmware to the U-Boot source directory and then using that location in
the U-Boot configuration is better, or if we should simply make the
U-Boot configuration point to the location in $(UBOOT_DL_DIR), i.e:

$(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,$(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)),$(@D)/.config)

I'm not saying we _must_ do this, I'm wondering if it isn't simpler.

> +define UBOOT_KCONFIG_FIXUP_CMDS
> +	$(UBOOT_ZYNQMP_KCONFIG_FIXUP)
> +endef

This obviously won't work with a non-kconfig capable U-Boot version,
though admittedly ZynqMP support is sufficiently new in upstream U-Boot
that we're pretty much guaranteed that someone trying to build for
ZynqMP will have a kconfig-capable U-Boot. But to be sure, perhaps the
BR2_TARGET_UBOOT_ZYNQMP_PMUFW should have a "depends on
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG" ?

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC)
  2018-05-03 16:23 ` [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
@ 2018-05-28 20:55   ` Thomas Petazzoni
  2018-05-29 20:46     ` Luca Ceresoli
  0 siblings, 1 reply; 20+ messages in thread
From: Thomas Petazzoni @ 2018-05-28 20:55 UTC (permalink / raw)
  To: buildroot

Hello,

On Thu,  3 May 2018 18:23:37 +0200, Luca Ceresoli wrote:

> diff --git a/configs/zynqmp_zcu106_defconfig b/configs/zynqmp_zcu106_defconfig
> new file mode 100644
> index 000000000000..36643b2f4cdd
> --- /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_BL31_UBOOT=y

Shouldn't we specify an explicit version for ATF, just like it's done
for U-Boot and Linux ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files
  2018-05-28 20:49   ` Thomas Petazzoni
@ 2018-05-29 20:45     ` Luca Ceresoli
  2018-05-30 20:43       ` Arnout Vandecappelle
  0 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-29 20:45 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 28/05/2018 22:49, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu,  3 May 2018 18:23:35 +0200, Luca Ceresoli wrote:
> 
>> +ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
>> +
>> +ifneq ($(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PSU_INIT_DIR)),)
> 
> It'd be nice to have an intermediate UBOOT_ZYNQMP_PSU_INIT_DIR variable
> instead of calculating its qstripped value twice.
> 
>> +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/
> 
> However, the bigger question is why do we need this in the first
> place ? This is in fact just patching the U-Boot source code. Why not
> use a patch instead ? Aren't people in general anyway going to have
> their own custom U-Boot Git tree, in which they will version control
> their psu_init files ?

Of course course having a custom U-Boot tree with these files versioned
is a valid workflow, which does not need the present patch. But there
are other valid use cases.

> Since this really looks like a specialized patching step, I'm not sure
> it really makes sense to add this. Unless you can convince me
> otherwise :-)

The psu_init files are special because they contain
automatically-generated code to configure the SoC peripherals: enable
devices, set pinmuxes etc, which is not otherwise done at runtime. Have
a look at a few examples: [0] [1].

This file will change whenever the hardware *or* the configuration
changes (e.g. to enable peripherals).

It is perfectly fine if one wants to use a mainline U-Boot release or a
Xilinx release, unmodified, that works fine... *except* for the psu_init
file. With your proposed workflow all users will be forced to use a
custom git tree, just because they have a slightly different psu_init
file. With my patch these users can just use a "standard" U-Boot
(downloaded straight from the Internet), throw a psu_init file in their
Buildroot boards/ dir and change their Buildroot config to point to it.

Even though it's technically code, you can consider the psu_init
somewhat like a configuration file.

Did I convince you? :-)

[0]
http://git.denx.de/?p=u-boot.git;a=blob;f=board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c;h=fcd6a46ad9ffa0da06c4f0a67c2397aa4128ca29;hb=HEAD
[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=board/xilinx/zynqmp/zynqmp-zcu102-revA/psu_init_gpl.c;h=5f21c4747584815ba86e50a36906b6c1fe8af1ca;hb=HEAD

Regards,
-- 
Luca

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary
  2018-05-28 20:53   ` Thomas Petazzoni
@ 2018-05-29 20:46     ` Luca Ceresoli
  2018-05-31 21:29       ` Luca Ceresoli
  0 siblings, 1 reply; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-29 20:46 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 28/05/2018 22:53, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu,  3 May 2018 18:23:36 +0200, Luca Ceresoli wrote:
>> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
>> index cbb899515181..266e42698d1b 100644
>> --- a/boot/uboot/uboot.mk
>> +++ b/boot/uboot/uboot.mk
>> @@ -276,6 +276,21 @@ endef
>>  
>>  ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
>>  
>> +UBOOT_ZYNQMP_PMUFW = $(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PMUFW))
>> +
>> +ifneq ($(UBOOT_ZYNQMP_PMUFW),)
>> +UBOOT_EXTRA_DOWNLOADS += $(UBOOT_ZYNQMP_PMUFW)
>> +BR_NO_CHECK_HASH_FOR += $(notdir $(UBOOT_ZYNQMP_PMUFW))
>> +define UBOOT_ZYNQMP_KCONFIG_FIXUP
>> +	$(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,"board/xilinx/zynqmp/pmufw.bin",$(@D)/.config)
>> +endef
>> +define UBOOT_ZYNQMP_COPY_PMUFW
>> +	$(INSTALL) -D -m 0644 $(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)) \
>> +		$(@D)/board/xilinx/zynqmp/pmufw.bin
>> +endef
> 
> I'm wondering if your solution that consists in copying the PMU
> firmware to the U-Boot source directory and then using that location in
> the U-Boot configuration is better, or if we should simply make the
> U-Boot configuration point to the location in $(UBOOT_DL_DIR), i.e:
> 
> $(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,$(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)),$(@D)/.config)
> 
> I'm not saying we _must_ do this, I'm wondering if it isn't simpler.

This would definitely be better, but it wouldn't work because the U-Boot
makefile looks for $(srctree)/$(CONFIG_BOOT_INIT_FILE), not just
$(CONFIG_BOOT_INIT_FILE). So the file must be relative to
$(@D)/board/xilinx/zynqmp/, i.e. $(srctree).

Of course this could be fixed in U-Boot...

>> +define UBOOT_KCONFIG_FIXUP_CMDS
>> +	$(UBOOT_ZYNQMP_KCONFIG_FIXUP)
>> +endef
> 
> This obviously won't work with a non-kconfig capable U-Boot version,
> though admittedly ZynqMP support is sufficiently new in upstream U-Boot
> that we're pretty much guaranteed that someone trying to build for
> ZynqMP will have a kconfig-capable U-Boot.

Indeed.

> But to be sure, perhaps the
> BR2_TARGET_UBOOT_ZYNQMP_PMUFW should have a "depends on
> BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG" ?

Ok, that can be done anyway, no problem.

-- 
Luca

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC)
  2018-05-28 20:55   ` Thomas Petazzoni
@ 2018-05-29 20:46     ` Luca Ceresoli
  0 siblings, 0 replies; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-29 20:46 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On 28/05/2018 22:55, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu,  3 May 2018 18:23:37 +0200, Luca Ceresoli wrote:
> 
>> diff --git a/configs/zynqmp_zcu106_defconfig b/configs/zynqmp_zcu106_defconfig
>> new file mode 100644
>> index 000000000000..36643b2f4cdd
>> --- /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_BL31_UBOOT=y
> 
> Shouldn't we specify an explicit version for ATF, just like it's done
> for U-Boot and Linux ?

Absolutely. Will fix that.

Thanks,
-- 
Luca

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files
  2018-05-29 20:45     ` Luca Ceresoli
@ 2018-05-30 20:43       ` Arnout Vandecappelle
  2018-05-31 21:30         ` Luca Ceresoli
  0 siblings, 1 reply; 20+ messages in thread
From: Arnout Vandecappelle @ 2018-05-30 20:43 UTC (permalink / raw)
  To: buildroot



On 29-05-18 22:45, Luca Ceresoli wrote:
> Hi Thomas,
> 
> On 28/05/2018 22:49, Thomas Petazzoni wrote:
[snip]
>> Since this really looks like a specialized patching step, I'm not sure
>> it really makes sense to add this. Unless you can convince me
>> otherwise :-)
> 
> The psu_init files are special because they contain
> automatically-generated code to configure the SoC peripherals: enable
> devices, set pinmuxes etc, which is not otherwise done at runtime. Have
> a look at a few examples: [0] [1].
 Regards,
 Arnout
> 
> This file will change whenever the hardware *or* the configuration
> changes (e.g. to enable peripherals).
> 
> It is perfectly fine if one wants to use a mainline U-Boot release or a
> Xilinx release, unmodified, that works fine... *except* for the psu_init
> file. With your proposed workflow all users will be forced to use a
> custom git tree, just because they have a slightly different psu_init
> file. With my patch these users can just use a "standard" U-Boot
> (downloaded straight from the Internet), throw a psu_init file in their
> Buildroot boards/ dir and change their Buildroot config to point to it.
> 
> Even though it's technically code, you can consider the psu_init
> somewhat like a configuration file.

 Yeah, I guess you could say it's a kind of dts but as a .c file instead of a
.dts file. Right?

> 
> Did I convince you? :-)

 You convinced me :-)

 Regards,
 Arnout

> 
> [0]
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c;h=fcd6a46ad9ffa0da06c4f0a67c2397aa4128ca29;hb=HEAD
> [1]
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/xilinx/zynqmp/zynqmp-zcu102-revA/psu_init_gpl.c;h=5f21c4747584815ba86e50a36906b6c1fe8af1ca;hb=HEAD
> 
> Regards,
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary
  2018-05-29 20:46     ` Luca Ceresoli
@ 2018-05-31 21:29       ` Luca Ceresoli
  0 siblings, 0 replies; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-31 21:29 UTC (permalink / raw)
  To: buildroot

Hi,

On 29/05/2018 22:46, Luca Ceresoli wrote:
> Hi Thomas,
> 
> On 28/05/2018 22:53, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Thu,  3 May 2018 18:23:36 +0200, Luca Ceresoli wrote:
>>> diff --git a/boot/uboot/uboot.mk b/boot/uboot/uboot.mk
>>> index cbb899515181..266e42698d1b 100644
>>> --- a/boot/uboot/uboot.mk
>>> +++ b/boot/uboot/uboot.mk
>>> @@ -276,6 +276,21 @@ endef
>>>  
>>>  ifeq ($(BR2_TARGET_UBOOT_ZYNQMP),y)
>>>  
>>> +UBOOT_ZYNQMP_PMUFW = $(call qstrip,$(BR2_TARGET_UBOOT_ZYNQMP_PMUFW))
>>> +
>>> +ifneq ($(UBOOT_ZYNQMP_PMUFW),)
>>> +UBOOT_EXTRA_DOWNLOADS += $(UBOOT_ZYNQMP_PMUFW)
>>> +BR_NO_CHECK_HASH_FOR += $(notdir $(UBOOT_ZYNQMP_PMUFW))
>>> +define UBOOT_ZYNQMP_KCONFIG_FIXUP
>>> +	$(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,"board/xilinx/zynqmp/pmufw.bin",$(@D)/.config)
>>> +endef
>>> +define UBOOT_ZYNQMP_COPY_PMUFW
>>> +	$(INSTALL) -D -m 0644 $(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)) \
>>> +		$(@D)/board/xilinx/zynqmp/pmufw.bin
>>> +endef
>>
>> I'm wondering if your solution that consists in copying the PMU
>> firmware to the U-Boot source directory and then using that location in
>> the U-Boot configuration is better, or if we should simply make the
>> U-Boot configuration point to the location in $(UBOOT_DL_DIR), i.e:
>>
>> $(call KCONFIG_SET_OPT,CONFIG_PMUFW_INIT_FILE,$(UBOOT_DL_DIR)/$(notdir $(UBOOT_ZYNQMP_PMUFW)),$(@D)/.config)
>>
>> I'm not saying we _must_ do this, I'm wondering if it isn't simpler.
> 
> This would definitely be better, but it wouldn't work because the U-Boot
> makefile looks for $(srctree)/$(CONFIG_BOOT_INIT_FILE), not just
> $(CONFIG_BOOT_INIT_FILE). So the file must be relative to
> $(@D)/board/xilinx/zynqmp/, i.e. $(srctree).
> 
> Of course this could be fixed in U-Boot...

...which is in progress, see the patch:
https://patchwork.ozlabs.org/patch/923351/

-- 
Luca

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files
  2018-05-30 20:43       ` Arnout Vandecappelle
@ 2018-05-31 21:30         ` Luca Ceresoli
  0 siblings, 0 replies; 20+ messages in thread
From: Luca Ceresoli @ 2018-05-31 21:30 UTC (permalink / raw)
  To: buildroot

Hi Arnout,

On 30/05/2018 22:43, Arnout Vandecappelle wrote:
> 
> 
> On 29-05-18 22:45, Luca Ceresoli wrote:
>> Hi Thomas,
>>
>> On 28/05/2018 22:49, Thomas Petazzoni wrote:
> [snip]
>>> Since this really looks like a specialized patching step, I'm not sure
>>> it really makes sense to add this. Unless you can convince me
>>> otherwise :-)
>>
>> The psu_init files are special because they contain
>> automatically-generated code to configure the SoC peripherals: enable
>> devices, set pinmuxes etc, which is not otherwise done at runtime. Have
>> a look at a few examples: [0] [1].
>  Regards,
>  Arnout
>>
>> This file will change whenever the hardware *or* the configuration
>> changes (e.g. to enable peripherals).
>>
>> It is perfectly fine if one wants to use a mainline U-Boot release or a
>> Xilinx release, unmodified, that works fine... *except* for the psu_init
>> file. With your proposed workflow all users will be forced to use a
>> custom git tree, just because they have a slightly different psu_init
>> file. With my patch these users can just use a "standard" U-Boot
>> (downloaded straight from the Internet), throw a psu_init file in their
>> Buildroot boards/ dir and change their Buildroot config to point to it.
>>
>> Even though it's technically code, you can consider the psu_init
>> somewhat like a configuration file.
> 
>  Yeah, I guess you could say it's a kind of dts but as a .c file instead of a
> .dts file. Right?

Right, in that they both contain some configuration data. But with the
difference that a dtb is usually a separate file from the kernel, while
the psu_init is compiled and linked in the bootloader binary. psu_init
is more similar to an appended DTB.

-- 
Luca

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2018-05-31 21:30 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-03 16:23 [Buildroot] [PATCH v3 0/5] Add Xilinx ZynqMP and ZCU106 board support Luca Ceresoli
2018-05-03 16:23 ` [Buildroot] [PATCH v3 1/5] arm-trusted-firmware: simplify release dir path Luca Ceresoli
2018-05-04  7:14   ` Gary Bisson
2018-05-04 13:46     ` Luca Ceresoli
2018-05-04 15:05       ` Gary Bisson
2018-05-28 20:34   ` Thomas Petazzoni
2018-05-03 16:23 ` [Buildroot] [PATCH v3 2/5] arm-trusted-firmware: generate atf-uboot.ub image of bl31.bin Luca Ceresoli
2018-05-28 20:46   ` Thomas Petazzoni
2018-05-03 16:23 ` [Buildroot] [PATCH v3 3/5] uboot: zynqmp: allow to use custom psu_init files Luca Ceresoli
2018-05-28 20:49   ` Thomas Petazzoni
2018-05-29 20:45     ` Luca Ceresoli
2018-05-30 20:43       ` Arnout Vandecappelle
2018-05-31 21:30         ` Luca Ceresoli
2018-05-03 16:23 ` [Buildroot] [PATCH v3 4/5] uboot: zynqmp: generate SPL image with PMUFW binary Luca Ceresoli
2018-05-28 20:53   ` Thomas Petazzoni
2018-05-29 20:46     ` Luca Ceresoli
2018-05-31 21:29       ` Luca Ceresoli
2018-05-03 16:23 ` [Buildroot] [PATCH v3 5/5] configs: add Xilinx ZCU106 board (ZynqMP SoC) Luca Ceresoli
2018-05-28 20:55   ` Thomas Petazzoni
2018-05-29 20:46     ` Luca Ceresoli

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.