Start adding support for potential aarch64 build

[allexoll]

Hi,

This PR brings what's needed in this repository to start to have some support for a potential aarch64 build for symbiflow.

This does not mean that symbiflow now supports aarch64, far from it, but since symbiflow is all of these hardwired gits, better to start somewhere.

Here we just add some switch case testing for which arch we are running on and fills the ressources name for it.

Of course, remarks welcome!

Alexis Marquet

[mithro]

Is it possible to add some testing?

(It would be great to add POWER architecture in the future too.)

[allexoll]

I'm not sure what kind of test would be pertinent for this, I know travis supports aarch64 & ppc64le so it would be easy on that side.

The issue is that i'm pretty sure some other things need to be fixed in other repository for a similar test-suite as amd64 to pass for aarch64.

what kind of tests were you thinking about?

[mithro]

@allexoll -- I was thinking maybe seeing if you can setup builds using GitHub Actions? @umarcor might have some ideas. I know that people are using GitHub Actions to build multi-arch containers for Docker. A quick Google search turned up the following links;

• https://blog.oddbit.com/post/2020-09-25-building-multi-architecture-im/
• https://github.com/docker/setup-qemu-action
• https://github.com/ahmetozer/github-actions-multi-arch-container-ghcr.io
• https://github.com/marketplace/actions/run-on-architecture
• https://github.com/eclipse/che-jwtproxy/actions/runs/202468400/workflow
• https://github.community/t/testing-against-multiple-architectures/17111
• https://itnext.io/building-multi-cpu-architecture-docker-images-for-arm-and-x86-3-building-in-github-action-ci-a382feab5af9
• https://itnext.io/ci-cd-for-a-multi-arch-go-application-using-github-actions-docker-buildx-helm-and-kubernetes-f415a42b2c82

@kgugala from Antmicro was also setting up self hosted runners for GitHub Actions and was looking at using the Antmicro RPi cluster stuff.

• https://antmicro.com/blog/2021/03/github-actions-self-hosted-runners/
• https://antmicro.com/blog/2021/04/scalenode-server-oriented-raspberry-pi4-baseboard/
• https://antmicro.com/blog/2021/08/open-source-github-actions-runners-with-gcp-and-terraform/

Building multi-architecture images with GitHub Actions · The Odd Bit

At work we have a cluster of IBM Power 9 systems running OpenShift. The problem with this environment is that nobody runs Power 9 on their desktop, and Docker Hub only offers automatic build support for the x86 architecture. This means there’s no convenient options for building Power 9 Docker images…or so I thought. It turns out that Docker provides GitHub actions that make the process of producing multi-architecture images quite simple.

GitHub

GitHub - docker/setup-qemu-action: GitHub Action to configure Qemu support

GitHub Action to configure Qemu support. Contribute to docker/setup-qemu-action development by creating an account on GitHub.

GitHub

GitHub - ahmetozer/github-actions-multi-arch-container-ghcr.io: Github actions multi-architecture container guide repository.

Github actions multi-architecture container guide repository. - GitHub - ahmetozer/github-actions-multi-arch-container-ghcr.io: Github actions multi-architecture container guide repository.

GitHub

Run on architecture - GitHub Marketplace

Run commands in a Linux container with a specific CPU architecture (armv6, armv7, aarch64, s390x, ppc64le)

GitHub

Github action with multi-CPU architecture support and multi docker file support (#30) · eclipse/che-jwtproxy@935b358

Contribute to eclipse/che-jwtproxy development by creating an account on GitHub.

GitHub Community

Testing against multiple architectures

I’m trying to migrate a project from Travis to Github Actions but I can’t find how I specify different architectures. Is this currently not possible? I would preferably run my tests on the host but I’ve also tried running in a container: test_linux_arm: runs-on: ubuntu-latest container: image: arm64v8/python:3.7-buster steps: - uses: actions/checkout@v1 - name: Test run: | python -c "import platform; print(platform.machine())" But this results in...

Medium

Building Multi-CPU Architecture Docker Images for ARM and x86 (3): Building in GitHub Action CI

Building Multi-Arch Docker Images in Github Action CI

Medium

CI/CD for a Multi-Arch Golang Application Using GitHub Actions, Helm and Kubernetes

How to setup your CI/CD in a Cloud environment

Antmicro · GitHub Actions self-hosted runners, Build Event Server and Google Cloud

Antmicro · Scalenode - server-oriented baseboard for Raspberry Pi 4 compute module

Antmicro · Open source custom GitHub Actions runners with Google Cloud and Terraform

[umarcor]

We are using dbhi/qus in hdl/containers. That allows building for arm, arm64, ppc64 and s390x. The summary is:

1. Execute https://github.com/hdl/containers/blob/main/utils/setup.sh#L35-L43.
2. Use a "foreign" container. For instance, arm32v7/ubuntu:focal, arm64v8/ubuntu:focal, etc.

We can provide a variant of the conda container, for foreign architectures. That's based on Debian Bullseye. Would that be useful in the CI of this repo?

GitHub

containers/setup.sh at main · hdl/containers

Building and deploying container images for open source electronic design automation (EDA) - containers/setup.sh at main · hdl/containers

[allexoll]

That seems a good idea to me. I think it would be doable with travis as is, we would just need to add a arch keyword (ref: https://docs.travis-ci.com/user/multi-cpu-architectures/).

I'm currently testing to see which packages can build as is and which cannot and what fixes would be needed, but so far it seems that many packages would need some fix to allow for aarch64 build. I'll add an issue to track the progress on that front soon, and I think the question of CI will be answered by then.

We could keep this PR as draft until then if you want?

[mithro]

Travis is sadly no longer usable for open source projects (and has had lots off issues) but we can use GitHub Actions using both the GitHub free provided runners and the Google provided "self hosted runners" on Google Cloud Platform;

• https://earthly.dev/blog/migrating-from-travis/
• https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works
• https://arstechnica.com/information-technology/2021/09/travis-ci-flaw-exposed-secrets-for-thousands-of-open-source-projects/

Earthly Blog

Migrating Your Open Source Builds Off Of Travis CI

Starting in early December, a mad dash has been underway to migrate open-source projects off of Travis CI. What happened and where should you move ...

Travis CI's new pricing plan threw a wrench in my open source works | Jeff Geerling

Ars Technica

Travis CI flaw exposed secrets of thousands of open source projects

Developers furious at Travis CI's "insanely embarrassing 'security bulletin.'"

[allexoll]

I see. That seems like a big undertaking and i don't think i'm familiar enough with the project to be able to take it on, at least for now. I'll keep working on aarch64 support until then.

[allexoll]

@umarcor I believe hdlc's images are also all built for amd64, correct? See:

$ docker run --rm -it hdlc/conda "/bin/uname" "-m"
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
x86_64

Building it locally also produces a x86_64 image, because I believe that the base image is also only published for x86_64.

Looking at the conda.dockerfile:

RUN curl -fsSL https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh > conda_installer.sh \
 && chmod +x conda_installer.sh \ 

I'm confused how that would work with qus? since the binary installer is still the x86_64 version? or am I missing some detail that would make this fit together.

But it seems that the base image is specifically set to ARG ARCHITECTURE='amd64' ...

If hdlc/container is a better place to start my effort, I'd be happy to do it over there, especially if we want to end up using their container for GA over here.

[mithro]

Adding support for aarch64 into these conda packages is great work! I think @antmicro and @umarcor can probably take on the making the CI up and going?

[umarcor]

@umarcor I believe hdlc's images are also all built for amd64, correct?

It depends on what you mean with "all". There are several images built for multiple architectures. However, all the conda|symbiflow images are currently built for amd64 only.

Building it locally also produces a x86_64 image, because I believe that the base image is also only published for x86_64.

When building it locally, there is an argument to override the architecture. However, as you found out, it needs tweaking the dockerfile/script as well.

I'm confused how that would work with qus? since the binary installer is still the x86_64 version? or am I missing some detail that would make this fit together.

The dockerfile/script needs to me modified in order to use a different URL depending on the architecture.

But it seems that the base image is specifically set to ARG ARCHITECTURE='amd64' ...

That's an argument, which can be overriden through the --build-arg when calling docker run. Nevertheless, pyHDLC (the utilities in hdl/containers) support overriding it through arg --architecture (-a); hence, you don't need to care about it. See https://hdl.github.io/containers/dev/Utils.html#pyhdlc-build and https://github.com/hdl/containers/blob/main/utils/pyHDLC/__init__.py#L418.

If hdlc/container is a better place to start my effort, I'd be happy to do it over there, especially if we want to end up using their container for GA over here.

I created this feature branch as an starting point: https://github.com/hdl/containers/commits/conda-multiarch. So, we need to handle how to tweak the URL depending on the base/architecture (note that the names used by docker don't match the ones used by conda). Do you want to tackle it?

[umarcor]

As commented in hdl/containers#54 (comment), Conda containers for "foreign" architectures are available now. Hence, they can be used in CI along with dbhi/qus to build Conda for arm64, ppc64 or s390x.

However, this repository seems to be unmaintained since 2020. I'd say that the current upstream are the repos in org 'hdl'. It would be sensible to continue in hdl/conda-eda.

[unixb0y]

Anything new about this? F4PGA still not working in Ubuntu 22.04 VM on a M2 Pro machine.

[allexoll]

Fiy as a temporary way to do that, you can use Rosetta in UTM to run x86 stuff: https://docs.getutm.app/advanced/rosetta/

UTM Documentation

Rosetta

Documentation for UTM virtual machines