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.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.
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
signature.asc
Description: PGP signature
