[RFC PATCH] docker: add ADI build-related tools to docker image

[RFC PATCH] docker: add ADI build-related tools to docker image

[Greg Malysa]

ADI processors require packaging with the ldr utility for bootrom
compatibility. Normally this is available as part of our yocto-derived
toolchain but it is not a part of any other premade toolchain, so it is
otherwise unavailable in the docker image for CI. This patch adds a
source build from the ADI maintained github repository. The same ldr
tool is used for arm and arm64 for all of our boards with names adjusted
to match the expected $(CROSS_COMPILE) for these boards.

Signed-off-by: Greg Malysa <malysagreg@gmail.com>

---
Hi Tom, I'm not sure exactly how changes to the docker image for uboot
testing work so I wanted to get feedback on my approach here before
including it in a larger series that will include the ADI boards. I
think that maybe 10 years ago the ldr tool was available as part of some
toolchain tarballs at least, but it is gone from everywhere except the
ADI forks now. So in order to build the sc5xx boards in CI, we need to
add the ldr tool. I've built an image based on the resulting docker file
and -next and then hooked it up to my gitlab runner to test things out
and this is compatible with our upcoming patches as well for a full
clean CI run. Please let me know if I've made some mistakes or if this
isn't the right way to submit changes for the docker image.


---
 tools/docker/Dockerfile | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index 569912303fc..f444accf326 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -299,6 +299,15 @@ RUN wget -O - https://coreboot.org/releases/coreboot-24.08.tar.xz | tar -C /tmp
     sudo cp build/coreboot.rom build/cbfstool /opt/coreboot/ && \
     rm -rf /tmp/coreboot-24.08
 
+# Build ldr tool for ADI boards and install to match expected abi name
+RUN git clone https://github.com/analogdevicesinc/lnxdsp-arm-poky-linux-gnueabi-ldr.git /tmp/lnxdsp-arm-poky-linux-gnueabi-ldr && \
+	cd /tmp/lnxdsp-arm-poky-linux-gnueabi-ldr/src/ldr && \
+	ls && \
+	./configure && \
+	make -j $(nproc) && \
+	cp ldr /usr/bin/arm-linux-gnueabi-ldr && \
+	cp ldr /usr/bin/aarch64-linux-ldr
+
 # Create our user/group
 RUN echo uboot ALL=NOPASSWD: ALL > /etc/sudoers.d/uboot
 RUN useradd -m -U uboot
-- 
2.45.2

Re: [RFC PATCH] docker: add ADI build-related tools to docker image

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Fri, Mar 21, 2025 at 01:37:42AM -0400, Greg Malysa wrote:

> ADI processors require packaging with the ldr utility for bootrom
> compatibility. Normally this is available as part of our yocto-derived
> toolchain but it is not a part of any other premade toolchain, so it is
> otherwise unavailable in the docker image for CI. This patch adds a
> source build from the ADI maintained github repository. The same ldr
> tool is used for arm and arm64 for all of our boards with names adjusted
> to match the expected $(CROSS_COMPILE) for these boards.
> 
> Signed-off-by: Greg Malysa <malysagreg@gmail.com>
> 
> ---
> Hi Tom, I'm not sure exactly how changes to the docker image for uboot
> testing work so I wanted to get feedback on my approach here before
> including it in a larger series that will include the ADI boards. I
> think that maybe 10 years ago the ldr tool was available as part of some
> toolchain tarballs at least, but it is gone from everywhere except the
> ADI forks now. So in order to build the sc5xx boards in CI, we need to
> add the ldr tool. I've built an image based on the resulting docker file
> and -next and then hooked it up to my gitlab runner to test things out
> and this is compatible with our upcoming patches as well for a full
> clean CI run. Please let me know if I've made some mistakes or if this
> isn't the right way to submit changes for the docker image.

Since these are new platforms, we should really be using binman for
manipulating the output images, and then also fetching / building any of
the custom vendor tooling that's also required. I'm not sure off-hand of
a good example however.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]