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

[Greg Malysa]

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.

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,
Greg