Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it. --- tools/docker.arm/Dockerfile | 104 ++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 tools/docker.arm/Dockerfile
diff --git a/tools/docker.arm/Dockerfile b/tools/docker.arm/Dockerfile new file mode 100644 index 0000000000..9d754da353 --- /dev/null +++ b/tools/docker.arm/Dockerfile @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: GPL-2.0+ +# This Dockerfile is used to build an image for runing the U-Boot sandbox on +# the armv7 architecture. + +FROM ubuntu:jammy-20221003@sha256:60c321f2700325103a0c185adeadfd5a93dbb3cd67dfbdd5b79a8aafa38325c2 + +ENV DEBIAN_FRONTEND=noninteractive + +# Update and install things from apt now +RUN apt-get update && apt-get install -y \ + automake \ + autopoint \ + bc \ + binutils-dev \ + bison \ + build-essential \ + clang-13 \ + coreutils \ + cpio \ + cppcheck \ + curl \ + device-tree-compiler \ + dosfstools \ + e2fsprogs \ + efitools \ + erofs-utils \ + expect \ + fakeroot \ + flex \ + gawk \ + gdisk \ + git \ + gnu-efi \ + gnutls-dev \ + graphviz \ + grub-efi-arm-bin \ + help2man \ + iasl \ + imagemagick \ + iputils-ping \ + libconfuse-dev \ + libgit2-dev \ + libjson-glib-dev \ + libguestfs-tools \ + libgnutls28-dev \ + libgnutls30 \ + liblz4-tool \ + libpixman-1-dev \ + libpython3-dev \ + libsdl1.2-dev \ + libsdl2-dev \ + libseccomp-dev \ + libssl-dev \ + libtool \ + libudev-dev \ + libusb-1.0-0-dev \ + linux-image-generic \ + lzma-alone \ + lzop \ + mount \ + mtd-utils \ + mtools \ + net-tools \ + ninja-build \ + openssl \ + picocom \ + parted \ + pkg-config \ + python-is-python3 \ + python2.7 \ + python3 \ + python3-dev \ + python3-pip \ + python3-sphinx \ + python3-virtualenv \ + rpm2cpio \ + sbsigntool \ + sloccount \ + socat \ + softhsm2 \ + sparse \ + srecord \ + sudo \ + swig \ + util-linux \ + uuid-dev \ + virtualenv \ + xxd \ + zip \ + && rm -rf /var/lib/apt/lists/* + +# Make kernels readable for libguestfs tools to work correctly +RUN chmod +r /boot/vmlinu* + +# Create our user/group +RUN echo uboot ALL=NOPASSWD: ALL > /etc/sudoers.d/uboot +RUN useradd -m -U uboot +USER uboot:uboot + +# Create the buildman config file +RUN /bin/echo -e "[toolchain]\nroot = /usr" > ~/.buildman +RUN /bin/echo -e "\n[toolchain-prefix]" >> ~/.buildman +RUN /bin/echo -e "\n[toolchain-alias]" >> ~/.buildman +RUN /bin/echo -e "\nsandbox = arm" >> ~/.buildman
On 10/16/22 09:43, Heinrich Schuchardt wrote:
Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardtheinrich.schuchardt@canonical.com
I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it.
We also need a separate requirements.txt with pygit2==1.6.1 due the different version of libgit in the armhf version of Ubuntu Jammy.
Best regards
Heinrich
On Sun, Oct 16, 2022 at 12:03:30PM +0200, Heinrich Schuchardt wrote:
On 10/16/22 09:43, Heinrich Schuchardt wrote:
Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardtheinrich.schuchardt@canonical.com
I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it.
We also need a separate requirements.txt with pygit2==1.6.1 due the different version of libgit in the armhf version of Ubuntu Jammy.
So, what are the general best practices to have a Dockerfile that can be / is used for generating multiple platforms worth of images? We should aim for a single Dockerfile that can be used for x86-64, armv7 and aarch64.
On 10/28/22 21:04, Tom Rini wrote:
On Sun, Oct 16, 2022 at 12:03:30PM +0200, Heinrich Schuchardt wrote:
On 10/16/22 09:43, Heinrich Schuchardt wrote:
Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardtheinrich.schuchardt@canonical.com
I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it.
We also need a separate requirements.txt with pygit2==1.6.1 due the different version of libgit in the armhf version of Ubuntu Jammy.
So, what are the general best practices to have a Dockerfile that can be / is used for generating multiple platforms worth of images? We should aim for a single Dockerfile that can be used for x86-64, armv7 and aarch64.
As we execute bash commands in the Dockerfile we could use if/fi and case/esac to work around differences between architectures.
Except on amd64 we only want to execute the sandbox. So there is no need to build GRUB, QEMU, and swtmp/libtmps.
Best regards
Heinrich
On Fri, Oct 28, 2022 at 09:14:13PM +0200, Heinrich Schuchardt wrote:
On 10/28/22 21:04, Tom Rini wrote:
On Sun, Oct 16, 2022 at 12:03:30PM +0200, Heinrich Schuchardt wrote:
On 10/16/22 09:43, Heinrich Schuchardt wrote:
Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardtheinrich.schuchardt@canonical.com
I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it.
We also need a separate requirements.txt with pygit2==1.6.1 due the different version of libgit in the armhf version of Ubuntu Jammy.
So, what are the general best practices to have a Dockerfile that can be / is used for generating multiple platforms worth of images? We should aim for a single Dockerfile that can be used for x86-64, armv7 and aarch64.
As we execute bash commands in the Dockerfile we could use if/fi and case/esac to work around differences between architectures.
For unavoidable differences, yes, OK.
Except on amd64 we only want to execute the sandbox. So there is no need to build GRUB, QEMU, and swtmp/libtmps.
Why? There's no reason one shouldn't be able to run the whole of CI on aarch64 hosts, unless there's QEMU bugs, or similar issues. The first use might be just to do sandbox runs but I don't want to limit things without strong reason ($X doesn't work, would be a good reason to limit).
Hi,
On Fri, 28 Oct 2022 at 13:19, Tom Rini trini@konsulko.com wrote:
On Fri, Oct 28, 2022 at 09:14:13PM +0200, Heinrich Schuchardt wrote:
On 10/28/22 21:04, Tom Rini wrote:
On Sun, Oct 16, 2022 at 12:03:30PM +0200, Heinrich Schuchardt wrote:
On 10/16/22 09:43, Heinrich Schuchardt wrote:
Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardtheinrich.schuchardt@canonical.com
I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it.
We also need a separate requirements.txt with pygit2==1.6.1 due the different version of libgit in the armhf version of Ubuntu Jammy.
So, what are the general best practices to have a Dockerfile that can be / is used for generating multiple platforms worth of images? We should aim for a single Dockerfile that can be used for x86-64, armv7 and aarch64.
As we execute bash commands in the Dockerfile we could use if/fi and case/esac to work around differences between architectures.
For unavoidable differences, yes, OK.
Except on amd64 we only want to execute the sandbox. So there is no need to build GRUB, QEMU, and swtmp/libtmps.
Why? There's no reason one shouldn't be able to run the whole of CI on aarch64 hosts, unless there's QEMU bugs, or similar issues. The first use might be just to do sandbox runs but I don't want to limit things without strong reason ($X doesn't work, would be a good reason to limit).
I'm not sure where this is going, but how do we build sandbox on ARM? Do we need to use the cross compiler? I'd love to see this happen.
Regards, Simon
On Thu, Nov 10, 2022 at 01:40:35PM -0700, Simon Glass wrote:
Hi,
On Fri, 28 Oct 2022 at 13:19, Tom Rini trini@konsulko.com wrote:
On Fri, Oct 28, 2022 at 09:14:13PM +0200, Heinrich Schuchardt wrote:
On 10/28/22 21:04, Tom Rini wrote:
On Sun, Oct 16, 2022 at 12:03:30PM +0200, Heinrich Schuchardt wrote:
On 10/16/22 09:43, Heinrich Schuchardt wrote:
Provide an armv7 docker environment to build and test the sandbox.
Signed-off-by: Heinrich Schuchardtheinrich.schuchardt@canonical.com
I have been discussing with Simon, if we can test sandbox_defconfig build on arm in a docker container. This RFC is just a small step on the path to it.
We also need a separate requirements.txt with pygit2==1.6.1 due the different version of libgit in the armhf version of Ubuntu Jammy.
So, what are the general best practices to have a Dockerfile that can be / is used for generating multiple platforms worth of images? We should aim for a single Dockerfile that can be used for x86-64, armv7 and aarch64.
As we execute bash commands in the Dockerfile we could use if/fi and case/esac to work around differences between architectures.
For unavoidable differences, yes, OK.
Except on amd64 we only want to execute the sandbox. So there is no need to build GRUB, QEMU, and swtmp/libtmps.
Why? There's no reason one shouldn't be able to run the whole of CI on aarch64 hosts, unless there's QEMU bugs, or similar issues. The first use might be just to do sandbox runs but I don't want to limit things without strong reason ($X doesn't work, would be a good reason to limit).
I'm not sure where this is going, but how do we build sandbox on ARM? Do we need to use the cross compiler? I'd love to see this happen.
I'm going to keep an eye on the billing tab, but, I believe I have now signed up for a free and reasonably spec'd arm64 oracle cloud compute image and installed the gitlab runner on it. We'll want to put some additional logic in the gitlab-ci.yml file so that only certain jobs would run on runners with the lets say aarch64 tag, but, here's how we do it I believe.
participants (3)
-
Heinrich Schuchardt -
Simon Glass -
Tom Rini