[ Please note the cross-post and Reply-To ]
Hi folks,
As promised, here's a quick summary of what was discussed at the ARM
ports BoF session in Cape Town.
This year, unfortunately the session did not have video so I can't
link to it. I've taken a copy of the Gobby notes from the session,
alongside my small set of slides for the session (that also didn't get
shown!). [1]
We spoke about the past/present/future state of ARM ports in Debian.
armel
=====
armel is the longest-running of our current ARM ports in Debian,
starting in 2007. It's starting to become difficult to support. Debian
is the only common distro still supporting ARMv4t. While there is
still good upstream support in most major packages (e.g. Linux and
gcc), we're seeing a growing number of issues. Some packages
(e.g. NodeJS) don't support pre-ARMv7 at all any more. Another problem
is the lack of direct support for C++11 atomics - it's possible to use
a kernel helper to cover for this lack, but performance will be
terrible.
Possible future options for armel:
* Partial armel architecture?
We've talked about this in the past for various architectures, but
nobody has stepped up to work on it. The vast majority of the
outstanding armel use cases are going to be in headless servers so
we could maybe drop the desktop tasks and dependencies and keep
things like web server / mail server tasks that are much simpler.
Downside: There's no clear plan for how to create/maintain a
partial architecture, let alone how to release one. Potentially
huge amount of work needed.
* Update to ARMv5t (and maybe go headless)
We might be able to extend the life of armel by upping the minimum
spec, and would be able to continue supporting Kirkwood and Orion
based machines (e.g. NAS boxes) for a while longer. This would kill
support for v4t devices like Openmoko, but there are precious few
of these older devices still around.
Downside: as above if we try to do the partial architecture route;
if we don't we'll still have to support a full range of software on
older hardware.
Will need volunteers to make this work in either form, and while
some people are prepared to *help* (e.g. bdale and zumbi), nobody
stepped up in the BoF to lead such an effort. It needs both skill
and commitment of time.
* Release armel with stretch, then drop it
**This is the favoured option.** That would give EOL for armel in
2020, *potentially* later if there's an LTS release for stretch and
armel is included (as it is in wheezy). That would depend on
external labour or funding.
It's not easy (or popular) to remove an architecture from Debian,
but we're giving 4 years' notice of end of support.
armhf
=====
Much as in the Heidelberg BoF in terms of support and future.
Current port, first released with Wheezy. Due to cross-distro effort,
this setup (ARMv7 EABI using VFPv3D-16) is the default supported
32-bit ARM architecture in all distros now. We've got a couple of
kernel variants that will support just about any new devices shipping,
given updated drivers and device tree support.
Despite the ubiquity of v7 hardware that works, some people are still
making CPUs that *don't* work, e.g. new CPUs this year without any
hardware FPU. Not much we can or will do to support such broken
hardware.
Ignoring known-broken hardware stuff, almost any currently-shipping
ARMv7 device is likely to work with armhf. Yay!
There's been a recent effort to add an EFI shim layer into modern
U-Boot, which may allow for easier consistent boot support but there's
still issues to think about in terms of EFI variables etc.
arm64
=====
Most recent ARM port. All looking good now - we've been mostly able to
move on from Juno development platforms to real server hardware
now. We're using some APM Mustang machines and an AMD Seattle box
hosted by ARM and Linaro at the moment, and even real arm64 server
machines are finally coming available. Looking to move more of our ARM
buildds over onto these arm64 servers in the future, as this will
improve reliability and manageability.
We're using a single kernel for arm64, using DTB or ACPI for
configuration. Works well.
Affordable, usable machines are available now, e.g. the Cello or
SoftIron 1000 for ~$600. Linaro's 96boards machines are not using a
standard form factor which is sub-optimal. There's a Marvell arm64
board due soon (H2 2016) in ATX. The SoftIron 1000 doesn't have PCI,
but should be good for development/buildd otherwise. Another cheap
option is the Pine64. It's stuck on a vendor kernel for now, but
that's being steadily worked on. Cheap: quad A53, 2GB RAM, $29.
Other issues:
* ci.debian.net could do with more arm64 hardware, we'll see what we
can do to help
* UEFI Secure Boot for arm64 has an issue - there's nobody providing
a root CA. HP are doing their own for now; not sure what other
vendors can/will do. It's complicated (TM).
arm64 boards - http://www.96boards.org/
http://softiron.co.uk/
Misc
====
armhf question about using Neon extensions: We don't mandate Neon
support in the armhf ABI, as not all the supported boards have Neon -
including our own Marvell Armada XP based buildds. The armhf porter
box (harris.d.o) has Neon if people need to test. If software is
depending on detecting hardware support at compile time, that's
*broken* - detection should be done at runtime. Similar to SSE support
on X86 machines. There are good options already supported here. For
libraries, packages can build multiple copies with differing
optimisation and use hwcaps support in the runtime linker to select
the correct version. Alternatively, use ifunc to select the right
version(s) of specific functions at runtime.
Big endian support on ARM: While this is doable on the hardware (ARM
is endian-agnostic), it doesn't make sense for general purpose
distributions like Debian to (re)build everything in BE mode too -
there's not a compelling use case for us to spend the effort.
ILP32 port (arm64 equivalent of X32: a new 32-bit ABI for 64-bit
hardware) is in a similar place. While some folks may consider it
useful, there's no compelling reason for Debian or any other general
purpose distribution to ever care about it.
[1] http://www.einval.com/~steve/talks/Debconf16-arm-bof/
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Attachment:
signature.asc
Description: Digital signature