[PATCH 05/12] docker: add Analog Devices tools to docker image

[Tom Rini]

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 <trini at konsulko.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251120/62c04d26/attachment.sig>