Hi Michal,
On 6/13/25 09:59, Michal Simek wrote:
>
>
> On 6/13/25 09:38, Jerome Forissier wrote:
>>
>>
>> On 6/12/25 18:49, Tom Rini wrote:
>>> On Thu, Jun 12, 2025 at 05:32:41PM +0200, 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.foriss...@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
>>>
>>> Helper build scripts don't belong in the tools directory. If they're
>>> super helpful, I don't object to adding them to
>>> u-boot-extras/contrib/<you>/ directory.
>>
>> OK
>>
>>> But there's a number of
>>> documented examples already on checkout and build TF-A then do ... for
>>> your platform.
>>
>> There is doc/board/xilinx/zynqmp.rst which deals with quite few ZynqMP
>> boards but not the KV260. In addition, it has a number of shortcomings:
>> - It mentions pmu.bin but does not say where to get if from
>> - It doesn't say how to build TF-A (bl31.bin), some very specific build
>> options are needed.
>> - I consider that detailed build instructions belong in things called
>> scripts or Makefiles, that were invented long ago exactly for that
>> purpose :) IMO the documentation should tell the bare minimum and ideally
>> be unnecessary.
>>
>> I am not particularly proud of the fact that I spent more than a whole
>> day trying to get U-Boot master to boot on my KV260, and without the help
>> of Michal, no doubt I would still be trying... So, how about I submit the
>> zynqmp_kv260_build.sh script to the u-boot-extras/contrib/<me>/ directory
>> and just point to it in doc/board/xilinx/zynqmp.rst?
>
> no issue from my side.
OK so here you go:
>From a429f6563fc5f1433a2df8eabe6a42a98864701b Mon Sep 17 00:00:00 2001
From: Jerome Forissier <jerome.foriss...@linaro.org>
Date: Fri, 13 Jun 2025 13:39:10 +0200
Subject: [PATCH] contrib/jforissier: add zynqmp_kv260_build.sh
Add a build script for the AMD/Xilinx ZynqMP Kria KV260 board.
Signed-off-by: Jerome Forissier <jerome.foriss...@linaro.org>
---
contrib/jforissier/zynqmp_kv260_build.sh | 42 ++++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100755 contrib/jforissier/zynqmp_kv260_build.sh
diff --git a/contrib/jforissier/zynqmp_kv260_build.sh
b/contrib/jforissier/zynqmp_kv260_build.sh
new file mode 100755
index 0000000..967c946
--- /dev/null
+++ b/contrib/jforissier/zynqmp_kv260_build.sh
@@ -0,0 +1,42 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2025 Linaro Ltd.
+
+set -ex
+
+if [ "$1" == "-c" ]; then
+ # Clean: remove downloaded/converted files
+ rm -f bl31.elf bl31.bin pmufw.elf pmufw.bin zynqmp_fsbl.elf pmu_obj.bin
+ exit 0
+fi
+[ -e bl31.bin ] || {
+ wget
https://github.com/Xilinx/soc-prebuilt-firmware/raw/refs/heads/xlnx_rel_v2025.1/kv260-kria/bl31.elf
+ aarch64-linux-gnu-objcopy -O binary bl31.elf bl31.bin
+ BL31_LOAD_ADDR=$(aarch64-linux-gnu-readelf -l bl31.elf | awk '/Entry point/
{ print $3 }')
+}
+[ -e pmufw.bin ] || {
+ wget
https://github.com/Xilinx/soc-prebuilt-firmware/raw/refs/heads/xlnx_rel_v2025.1/kv260-kria/pmufw.elf
+ llvm-objcopy -O binary pmufw.elf pmufw.bin
+}
+[ -e pmu_obj.bin ] || {
+ wget
https://github.com/Xilinx/soc-prebuilt-firmware/raw/refs/heads/xlnx_rel_v2025.1/kv260-kria/zynqmp_fsbl.elf
+ aarch64-linux-gnu-objcopy --dump-section .sys_cfg_data=pmu_obj.bin
zynqmp_fsbl.elf
+}
+[ -e .config ] || {
+ make xilinx_zynqmp_kria_defconfig
+ cat << EOF >> .config
+CONFIG_PMUFW_INIT_FILE="pmufw.bin"
+CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="pmu_obj.bin"
+CONFIG_BL31_LOAD_ADDR=${BL31_LOAD_ADDR}
+CONFIG_BL32_LOAD_ADDR=0
+EOF
+}
+export BL31=bl31.bin
+export BL32=
+export TEE=
+export CROSS_COMPILE=aarch64-linux-gnu-
+make -j$(nproc) BINMAN_ALLOW_MISSING=1
+set +x
+echo Build was successful:
+ls -l qspi.bin
--
2.43.0
>
>
>>>> diff --git a/tools/zynqmp_pmufw_elf_convert.py
>>>> b/tools/zynqmp_pmufw_elf_convert.py
>>>> new file mode 100755
>>>> index 00000000000..b4eb2695831
>>>> --- /dev/null
>>>> +++ b/tools/zynqmp_pmufw_elf_convert.py
>>>> @@ -0,0 +1,96 @@
>>>> +#!/usr/bin/env python3
>>>> +# SPDX-License-Identifier: GPL-2.0+
>>>> +# Copyright (C) 2025 Linaro Ltd.
>>>> +#
>>>> +# Written by Gemini (Google AI) then reviewed and edited to remove some
>>>> comments
>>>
>>> I'm glad this calls out where it's from. I'm not comfortable for a
>>> number of ethical reasons on taking LLM-generated code. I'm also a
>>> little surprised we don't already have something like this with binman
>>> today?
>>
>> Nervermind. 'llvm-objcopy -O binary pmufw.elf pmufw.bin' works just
>> fine :) so I'll use that instead. Note that the binutils objcopy
>> cannot be used because it is target-specific and the MicroBlaze
>> version is not so easily available. While LLVM supports many targets
>> natively.
>
> yes/no. Toolchains are wired via buildman already and available at kernel.org.
> Connection to llvm is adding another dependency.
My main development setup is Ubuntu, and 'sudo apt install llvm' is easy.
buildman is certainly fine for many things (like building a bunch of commits
and platforms), but I quite like being able to simply run 'make' once the
initial setup is done. OK in this case that is 'make BINMAN_ALLOW_MISSING=1',
but close enough.
>
> I think putting this script to u-boot-extras is fine. To upstream u-boot
> could be more problematic because as I mentioned there are some issues with
> the way you use. You should be able to take bl31.elf from
> soc-prebuilt-firmware repo too.
Good suggestion indeed.
> You can also look what Neal did in buildroot to get it work which is better
> place for building tfa and putting images together from different locations.
Do you have a link? I am a big fan of buildroot for small developments setups.
Thanks,
--
Jerome
> Thanks,
> Michal
>
>
>
>
