On Thu, Nov 20, 2025 at 01:20:21PM -0500, Greg Malysa wrote: > Hi Tom, > > On Tue, Nov 18, 2025 at 9:39 AM Tom Rini <[email protected]> wrote: > > > > [snip] > > > +# Build ldr tool for Analog Devices boards and create prefixed symlinks > > > to match > > > +# $(CROSS_COMPILE) as used by different supported platforms > > > +RUN git clone > > > https://github.com/analogdevicesinc/lnxdsp-arm-poky-linux-gnueabi-ldr.git > > > /opt/lnxdsp-arm-poky-linux-gnueabi-ldr && \ > > > > We need to be getting a specific branch/tag (or worst case, commit) and > > using --depth=1. > > I'll address this in v3, thanks. There's a release tag I can use. > > > > > [snip] > > > +ENV PATH="${PATH}:/opt/lnxdsp-arm-poky-linux-gnueabi-ldr" > > > > Does this actually do what you want, update the PATH for the shell that > > we spawn and run CI in? > > It does appear to do what I want, which is allow buildman to find and > invoke the ldr tool, but as for whether it is the right way to do it, > I am unsure. If I run and attach to a container to manually go through > the steps, without the ENV line I get: > > ~/adi-u-boot$ tools/buildman/buildman sc598-som-ezkit-spl > Building current source for 1 boards (1 thread, 32 jobs per thread) > aarch64: + sc598-som-ezkit-spl > +/bin/sh: 1: aarch64-linux-ldr: not found > > and with it, I get > > $ ./tools/buildman/buildman sc598-som-ezkit-spl > Building current source for 1 boards (1 thread, 32 jobs per thread) > aarch64: w+ sc598-som-ezkit-spl > +===================== WARNING ====================== > +CONFIG_OF_EMBED is enabled. This option should only > +be used for debugging purposes. Please use > +CONFIG_OF_SEPARATE for boards in mainline. > +See doc/develop/devicetree/control.rst for more info. > +==================================================== > 0 1 0 /1 sc598-som-ezkit-spl > > so it is sufficient for finding aarch64-linux-ldr. The CI build also > passes, which has previously failed on the world build stage for me, > when it was unable to locate the ldr executable.
Ah, good, OK.
> Bigger picture though, is hacking up $PATH the right way to do this?
> Buildman inherits the env it runs in, so it picks up the modified PATH
> and then adds the toolchain directory to PATH itself, so I could drop
> symlinks into the aarch64 and armv7 folders as well and have it work,
> but I thought that might be even less appropriate. ADI's packaging
> (for amd64 only) currently installs it as "ldr" (no CROSS_COMPILE
> prefix) into /usr/bin, which won't work for us either, because the
> yocto SDK build does add CROSS_COMPILE prefixes if one were to use
> that to build uboot outside of CI, and we need to somehow be
> compatible with all three options, which PATH+CROSS_COMPILE achieves
> for now.
>
> So the options are probably:
> 1) Create local symlinks to rename the binary and hack up env/$PATH to
> attach this
> 2) Drop symlinks into
> /opt/gcc-${TCVER}-nolibc/(aarch64-linux,arm-linux-gnueabi)/bin
> 3) Modify buildman to be aware of ldr and have a separate
> configuration section where we can round up settings
> 4) (Cannot be done for now) ldr tool rewrite as python
> package+executable wrapper, update binman to use the library and
> package in LDR format
>
> Option 4 actually makes a lot of sense, but it is not something I can
> get support for from ADI for the time being, but it would solve the
> other big problem: u-boot can produce a stage 1 and stage 2 boot ldr
> file for us by calling ldr with uboot artifacts only, but the stage 2
> ldr is rarely useful in production and is only used for standalone
> testing. It is typically repackaged in a separate yocto recipe to add
> optee and tfa, or to replace u-boot proper with a kernel for falcon
> boot, and being able to generate ldrs from binman would allow us to
> combine the other files as well.
Thanks for the details, I think for now, option 1 is OK enough, and a
future option 4 does sound like a good idea.
--
Tom
signature.asc
Description: PGP signature
