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

[Tom Rini]

On Fri, Jun 13, 2025 at 09:59:52AM +0200, 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.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
> > > 
> > > 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.

I am also fine with this approach (and you should have access to the
repository, and I need to go do some admin work to make it easier to add
all custodians), and once Michal is happy with the script too.

> 
> 
> > > > 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.
> 
> 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.
> 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.

FWIW, it's things like this as to why I prefer more and better
documentation in u-boot itself and build scripts in contrib. Everything
has so many other use cases and then host dependencies that it's a Lot
OF Work to have something that handles everything. Having seen a number
of "helper build scripts" that then went very wrong once out in the wild
over the years is another part of my reasoning.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250613/29341c7b/attachment.sig>