- CI/CD: Building 32-bit Arm offical Docker images
- Orchestration: OpenStack on Arm
- Hardware: Qualcomm Centriq 2400 architecture details
- Hardware: arm64 powered desktop, laptop design from Bero
- Open issues: Docker multiarch vs. Docker Swarm
Tianon Gravi of Infosiftr last week started to build official 32-bit Arm (armv7 and armv5) images for Docker using systems from the Works on Arm project located at Packet. These "Type 2A2" systems have a Hisilicon Hi1616 processor, which provides native 32-bit Arm commpilation support.
Tianon writes:
Our multi-week backlogged queue was completely caught up literally overnight for arm32v7, we were able to add arm32v5 and get it caught up in just about the same amount of time, and we were even able to re-enable arm32v5 support on several images where it was previously prohibitively slow such as python, php, ruby, and even gcc!
Jenkins is the CI/CD system used here, and you can see the current state of each of the jobs at the "doi-janky" site linked below.
John Studarus is working on an OpenStack launcher that will deploy a two-node OpenStack cluster on Packet's Type 2A (Cavium ThunderX) systems. This is a work in progress and will allow you to easily stand up several hosts, install the various OpenStack components, configure the network and start application workloads on this 64-bit Arm system.
John leads the OpenStack San Diego official user group getting the community excited about OpenStack! He frequently gives talks on cloud security, compliance and risk management. This work is supported by the Works on Arm project.
Qualcomm has released more details of their Centriq 2400 ("Amberwing") platform at the 2017 Linley Processor Conference. The new information includes a chip diagram describing a 60MB L3 cache, 6 channels of DDR4 memory, 32 PCIe lanes, 8 SATA ports, and 2 Gigabit Ethernet interfaces. The chip is built with a 10nm process, and is expected to be commercially available by the end of 2017.
Previously, Qualcomm had disclosed some parts of the architecture at the Hot Chips 2017 event, and reviews of the press coverage from that presentation are also helpful in understanding the design.
- https://www.qualcomm.com/news/onq/2017/10/05/qualcomm-centriq-2400-designed-scalability-and-throughput-performance
- https://www.qualcomm.com/news/media-center/press-kits/linley-processor-conference
- https://www.servethehome.com/qualcomm-centriq-2400-arm-cpu-hot-chips-29/
- https://www.youtube.com/watch?v=SdvZ8lRyV0o - Elsie Wahlig interview at Linaro Connect by Charbax
Bernhard Rosenkränzer (Bero) from the Linaro Mobile Group demonstrated builds of an Arm powered desktop design, using the MACCHIATObin Marvell ARMADA 8040 quad-core system as the core of his efforts. CNXSoft did a writeup based on an interview with Bero by Charbax.
Since MACCHIATOBin board complies with mini-ITX form factor, he could simply use off the shelf parts with a standard desktop case with power supply, NVIDIA or AMD Radeon graphics card, 16GB memory modules, and a 2 TB SSD drive. The AMD Radeon card fried due to overheating, so the demo was made with an NVIDIA card driven by Nouveau open source driver. The complete system was actually run on fully open source drivers and firmware, and Linux 4.14 mainline with 2 extra patches.
The interview also includes a discussion of an Arm laptop constructed from components including the pi-top case, which is designed to hold a Raspberry Pi which is "not bolted shut, so it's easy to modify."
- https://www.cnx-software.com/2017/10/03/macchiatobin-based-diy-arm-desktop-dragonboard-820c-based-diy-arm-laptop-video/
- https://lwn.net/Articles/733837/
- https://www.youtube.com/watch?v=8ItXpmLsINs - interview by Charbax
Two open issues make the user experience for running Docker Swarm on armv7 systems like the Raspberry Pi less than ideal. The fundamental issue is that several Arm based systems can run a variety of types of code, and this typing based on machine architecture is not as easy to discover as it should be.
Case in point is the Raspberry Pi 3 running Raspbian, which is capable of running both "arm32v6" (armel, with emulated floating point) and "arm32v7" (armhf, with hardware floating point). When presented with a multiarch Docker image, which one should it pick? Getting that answer correct every time is the challenge.
With the "new" manifest list for multi-arch support, there is a corner case on ARM where the picked-up architecture is not ideal. On a ARMv7 CPU running Docker (e.g. a Raspberry Pi 2/3), the architecture is armhf (so with floating point hardware support). However when pulling an image such as the official Debian, the "armel" variant is pulled. This is compatible with ARMv7 but emulates floating point operations instead of using the underlying hardware.
A similar but distinct problem affects Docker Swarm, which schedules jobs across systems and has to match strings to make sure it knows that a system that reports as 'aarch64' knows how to run 'arm64' binaries.