* [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 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 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 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 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 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 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
* [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 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 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 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 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 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 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