[RFC PATCH] tools: zynqmp: add build script and documentation for ZynqMP KV260

Jerome Forissier jerome.forissier at linaro.org
Fri Jun 13 14:39:57 CEST 2025



On 6/13/25 14:33, Michal Simek wrote:
> 
> 
> On 6/13/25 14:25, Jerome Forissier wrote:
>> Hi Michal,
>>
>> On 6/13/25 09:55, Michal Simek wrote:
>>>
>>>
>>> On 6/12/25 17:32, Jerome Forissier wrote:
>>>> Add a script to help build a functional U-Boot binary for the ZynqMP
>>>> Kria KV260. Also add some documentation.
>>>>
>>>> Signed-off-by: Jerome Forissier <jerome.forissier at linaro.org>
>>>> ---
>>>>
>>>>    doc/board/xilinx/index.rst        |  1 +
>>>>    doc/board/xilinx/zynqmp-kv260.rst | 27 +++++++++
>>>>    tools/zynqmp_kv260_build.sh       | 43 ++++++++++++++
>>>>    tools/zynqmp_pmufw_elf_convert.py | 96 +++++++++++++++++++++++++++++++
>>>>    4 files changed, 167 insertions(+)
>>>>    create mode 100644 doc/board/xilinx/zynqmp-kv260.rst
>>>>    create mode 100755 tools/zynqmp_kv260_build.sh
>>>>    create mode 100755 tools/zynqmp_pmufw_elf_convert.py
>>>>
>>>> diff --git a/doc/board/xilinx/index.rst b/doc/board/xilinx/index.rst
>>>> index 2e31fe3f3a4..3f3a85b709c 100644
>>>> --- a/doc/board/xilinx/index.rst
>>>> +++ b/doc/board/xilinx/index.rst
>>>> @@ -9,4 +9,5 @@ Xilinx
>>>>       xilinx
>>>>       zynq
>>>>       zynqmp
>>>> +   zynqmp-kv260
>>>>       zynqmp-r5
>>>> diff --git a/doc/board/xilinx/zynqmp-kv260.rst b/doc/board/xilinx/zynqmp-kv260.rst
>>>> new file mode 100644
>>>> index 00000000000..219bbd602e9
>>>> --- /dev/null
>>>> +++ b/doc/board/xilinx/zynqmp-kv260.rst
>>>> @@ -0,0 +1,27 @@
>>>> +.. SPDX-License-Identifier: GPL-2.0
>>>> +..  (C) Copyright 2025 Linaro Ltd.
>>>> +
>>>> +ZYNQMP KV260
>>>> +============
>>>> +
>>>> +Building
>>>> +--------
>>>> +
>>>> +To build for the KV260:
>>>> +
>>>> +   $ ./tools/zynqmp_kv260_build.sh
>>>> +
>>>> +The first invocation will fetch and build some required binaries (bl31.bin,
>>>> +pm_cfg_obj.o, pmufw.bin). Subsequently `make` can be invoked directly as
>>>> +follows:
>>>> +
>>>> +   $ export BL31=bl31.bin
>>>> +   # export CROSS_COMPILE=aarch64-linux-gnu-
>>>> +   $ make -j$(nproc) BINMAN_ALLOW_MISSING=1
>>>> +
>>>> +Flashing
>>>> +--------
>>>> +
>>>> +Press the FWUEN button on the carrier board, the press and release the RESET
>>>> +button, then release FWUEN. Connect to the embedded HTTP server and upload
>>>> +`qspi.bin`. Press and release RESET again.
>>>> diff --git a/tools/zynqmp_kv260_build.sh b/tools/zynqmp_kv260_build.sh
>>>> new file mode 100755
>>>> index 00000000000..3cf7147e3a6
>>>> --- /dev/null
>>>> +++ b/tools/zynqmp_kv260_build.sh
>>>> @@ -0,0 +1,43 @@
>>>> +#!/bin/bash
>>>> +# SPDX-License-Identifier: GPL-2.0+
>>>> +#
>>>> +# Copyright (C) 2025 Linaro Ltd.
>>>> +
>>>> +set -ex
>>>> +
>>>> +if [ "$1" == "-c" ]; then
>>>> +  rm -f bl31.bin pmufw.elf pmufw.bin pm_cfg_obj.c pm_cfg_obj.o
>>>> +  exit 0
>>>> +fi
>>>> +[ -e bl31.bin ] || {
>>>> +  ATF_SRC=$(mktemp -d /tmp/arm-trusted-firmware.XXXXXXXXXX)
>>>> +  git clone https://github.com/ARM-software/arm-trusted-firmware ${ATF_SRC}
>>>> +  make -C ${ATF_SRC} -j$(nproc) bl31 CROSS_COMPILE=aarch64-linux-gnu- \
>>>> +      LOG_LEVEL=40 ZYNQMP_CONSOLE=cadence1 CONSOLE_RUNTIME=cadence1 \
>>>> +      RESET_TO_BL31=1 PLAT=zynqmp ZYNQMP_ATF_MEM_BASE=0x10000 \
>>>> +      ZYNQMP_ATF_MEM_SIZE=0x2ffff ENABLE_LTO=1
>>>
>>> As I told you this is shortcut. Recommendation is to put TF-A to OCM with FSBL.
>>> That's why there are some challenges in connection to fit both of them there.
>>>
>>> Another thing is that none is creating reservation for TFA in DT. When you boot Linux than there is big chance that user application will rewrite TF-A and you break your platform because of missing protection.
>>
>> OK. What if the bl31.elf from soc-prebuilt-firmware is used? It has load address
>> at 0xfffea000. Is it on-chip memory? Is this area protected from access by the
>> Linux kernel in the DT?
>>
> 
> yes OCM. It is not protected but it is also not described in DT that's why Linux is not aware about it.

OK. For many U-Boot development tasks it doesn't really matter. As
long as U-Boot runs and hands over to the kernel it's enough.

-- 
Jerome
> 
> M


More information about the U-Boot mailing list