Mandate minimum ARM architecture of ARMv7 or ARM64

[alexellis]

Changes:

Mandate minimum ARM architecture of ARMv7 or ARM64

This removes compatibility with the Raspberry Pi Zero and B+

Description

Even with advancements in ARM support within projects and Docker images there are still issues that prevent us providing seamless support for ARMv6 (Raspberry Pi Zero)

• No image for NATS Streaming
• Images are often not checked for armv6 - i.e. the recent Alpine Golang image failed to work on armv6 due to incorrect compilation
• Device is too slow to be useful and has very limited RAM (512mb)
• Device cannot be used for testing Kubernetes (K8s mandates ARMv7 or ARM64)
• ARMv6 isn't available for testing on the cloud and needs a separate device.
• Having to test on RPi Zero and 2/3 slows down development / release cycles

ARMv6:

• Raspberry PI Zero / 1 / B+

ARMv7

• RPi 2/3 / Scaleway

ARM64:

• Packet.net / Qualcomm / Pine64 / Scaleway etc

In addition to all the above there appears to be a lack of interest or commitment from the community to help with ARMv6 support.

[rgee0]

I've always been an advocate of providing a consistent experience across all supported hardware architectures. If external dependancies are making it difficult to support a, or some, hardware platforms then I feel we should favour consistency of experience over breadth of supported hardware architectures.

One positive that ARMv6 would bring was cheap entry to clustering, however performance would be vastly different on a PiZero, even when compared with an ARMv7 equivalent. One could argue whether this contradicts the consistent experience advocacy. Performance aside if ARMv6 support was to continue then it may be a case of providing a minimal stack, which again pulls against the consistency aim.

If ARMv6 support is dropped, then one area that I think the project will need to be more specific about is in how 32-bit ARM is referred to - i.e. armhf may not be precise enough in a > ARMv7 only world.

[alexellis]

Thank you for your input on this Richard

[rgee0]

Are there any further thoughts on this?

Do we proceed at this point?

[alexellis]

On naming armhf vs armv7 - I'm OK moving to armv7.

[ulm0]

Problem with alpine is that armhf stands for armv6 a.k.a arm32v6 as mentioned in gliderlabs/docker-alpine#298

Have you ever considered cross-compiling armv6 bins using multi-stage dockerfile in an AMD64 machine?

Either resin/raspberrypi3-alpine or multiarch/alpine might be used in a Travis pipeline, personally I've used the latter with no problems. Same for armv8.

Then you can easily push the images and use the manifest-tool to modify the manifest list.

[alexellis]

I agree - armhf does represent armv6/arm32v6 which is compatible with armv7/armv32v7, that's why we build only armhf. @rgee0 suggests we build only for armv7 that is the proposal.

[alexellis]

@ulm0 on dropping support for arm32v6 see the detailed points in the "Description", these are unrelated to cross-compilation.

[alexellis]

Derek close

[alexellis]

For anyone landing here please see my guide for building an ARM / RPi cluster with RPi2/3, Tinkerboard or any other armv7 board -> https://blog.alexellis.io/build-your-own-bare-metal-arm-cluster/