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

[Jerome Forissier]

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?

> 
> 
>> +  cp ${ATF_SRC}/build/zynqmp/release/bl31.bin .
>> +  rm -rf ${ATF_SRC}
>> +}
>> +[ -e pmufw.bin ] || {
>> +  wget https://github.com/Xilinx/soc-prebuilt-firmware/raw/refs/heads/xlnx_rel_v2023.1/kv260-kria/pmufw.elf
> 
> Better to use 2025.1 version.

Will update.

> 
>> +  ./tools/zynqmp_pmufw_elf_convert.py pmufw.elf pmufw.bin
>> +}
>> +[ -e pm_cfg_obj.o ] || {
>> +  wget https://github.com/Xilinx/embeddedsw/raw/refs/heads/xlnx_rel_v2023.1/lib/sw_apps/zynqmp_fsbl/misc/pm_cfg_obj.c
> 
> This is any generic configuration which is not aligned with standard firmware. It means yes you can use it but it is missing SOM specific configuration. It means for example power off don't need to work. Also this can work on kv260 only but don't need to work on kr260.
> 
> My way is to extract it from released fsbl instead but up2you.

I will do that in the next version. I will reply to your other reply.

Thanks,
-- 
Jerome

> 
> M