[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Summary of the ARM ports BoF at DC15

[ Please note the cross-post and Reply-To ]

Hi folks,

As promised, here's a quick summary of what was discussed at the BoF
session in Heidelberg. Apologies for the delay - it takes a while to
write these up, especially when struck down with the traditional
post-DebConf plague. :-(

Thanks to the awesome efforts of our video team, the session is
already online [1]. I've taken a copy of the Gobby notes too,
alongside my small set of slides for the session. [2]

As part of the "Ports" track at DebConf, We spoke about the
past/present/future state of ARM ports in Debian.


First released with Lenny, supports ARMv4t & later. QNAS etc. kirkwood
& some freedombox. Toolchain and kernel support upstream are probably
never going away due to the massive number of simple ARM devices still
being made and shipped, however...

Should we keep it for Stretch? Maybe with subarchitecture support,
when available. We still have some users, but not *many*. tbm would
miss it and is still supporting quite a lot of users. Could we get the
people who care about armel to do a minimally-supported LTS for
Jessie/Stretch? Typical users are now on NAS boxes or some
Freedomboxes, just using server software - no X, no graphics etc.
Should be possible?

Still supported upstream but becoming problematic on some
fronts. Hence, we need to consider the future, as we're spending real
human effort supporting armel. Unless it's really important, should we
reduce the effort being spent?

On the flip side, Debian is the only mainstream distro that still
supports older ARM hardware. ARMv5-based hardware is still being made
and sold today.

Known worries/issues:

 * Kernel size due to very restrictive flash space; has been a
   problem, but not believed to be affecting current users so much
   now. Several problematic sub-arches have been dropped. The ixp
   flavour is *definitely* not going to be supported for another
   release. We've suggested in the past that the way to work around
   the restrictive flash space would be to write a trivial bootloader
   but there's not been any effort spent there.

 * There's a good chance that we've built some things that don't work
   on v4t already, due to not using v4t hardware for build and test
   any more. That was already likely when we were using v5 buildd
   hardware, and it's only going to become more of an issue now we're
   using v7 buildd hardware. We *might* have to shift to v5 at least -
   there are only a tiny number of v4t devices that people care about
   any more, it seems.

Summary: if people care about armel for Stretch, they should make
noise NOW and convince people it's needed and can/should be supported
in 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

Ignoring known-broken hardware stuff, almost any currently-shipping
ARMv7 device is likely to work with armhf. Yay!


Most recent port, first shipped with Jessie. It's working well
overall, with just some minor things left to port and optimise. Maddog
is organising a competition to encourage people to port code and
optimise code for arm64 in some packages. The hardest remaining bits
are those language runtimes where the support is written *in* the
language in question: porters need to have a deep understanding of the
language *and* any new architecture.

Big, important language runtimes have already happened due to
upstreams already doing the work: Java being a good example. In some
cases, upstream have done the work but it's not yet filtered into a
Debian stable release (NodeJS, freepascal etc.) and there are others
where ports are known to exist but are not yet publically released
(e.g. Mono). But there's still plenty of scope for people to get
involved and help with porting a lot of software.

Real devices (including real servers) will be hitting the market very
shortly, which will make life easier for us. Linaro's 96boards.org
program was mentioned as a source of boards, and that prompted
complaints about continuing lack of upstream support. We're hoping
that will be fixed soon...!

Fairly well-known PC component manufacturers like Gigabyte and Asus
are already starting to sell hardware based around Applied Micro's
X-Gene CPU. Certain other large vendors like HP are also producing
higher-end X-Gene based hardware (Moonshot), so options are widening!

We even had a demo of an arm64-powered laptop in the talk, courtesy of
Chen Baozi. We tried to show it on video, but it didn't quite
work. :-/ Lots of interesting projects out there, and we're hoping to
see arm64 going mainstream in the near future.

Due to the tighter design constraints being used for ARMv8 devices, we
expect that we'll have a much easier time supporting all the likely
arm64 platforms with a single kernel etc. ACPI is in the spec for
arm64 servers, which will help.

Buildds and hardware

We have lots of donated Marvell Armada XP dev boards for building
armel and armhf, and they're mostly great. Still have one remaining
imx53 board as a porter box for people who might need to debug 32-bit
Neon stuff.

We have a range of options for arm64 hardware: donated Junos, X-Genes
and an AMD Seattle. We have issues with the machines that we have at
the moment, but things are improving. DSA want us to replace the dev
boards with proper server machines that are more stable and easier to
manage. We're hoping to get more people to donate/loan newer big arm64
machines as they become available, and this will make our lives

Some of the software for armel cannot run on the arm64 machines,
unfortunately. There are ARMv4t instructions that trigger exceptions
due to missing support in ARMv8 CPUs. This will be another problem for
armel as we move forward. Kernel exception handling will allow this
code to work in future, but *massively* slower than if supported in
the hardware so it's not really an option for us.

Scientific software

People are seeing issues with unit test timing out - what should they
do? Tests are working fine on normal machines but timing out on
buildds. If they're actually just taking too long, then the buildd
timeouts can be raised. BUT: they might actually be showing real
problems, e.g. with locking. Check on a porterbox too. Ask on the
debian-arm list for more help if needed. Is it worth building
scientific packages on armel? Possibly - we currently try to build
everything, you never know when people will have a valid use case that
you didn't think of...

Small use case devices

For less popular, small use-case devices, are there any lower bounds
on what we'll ship in terms of DTBs? If the dts is in mainline and
works, then the dtb can be made available - it's very cheap for us!

Question about Oluxino boards and making them work - currently needs
modifying u-boot. Talk to Karsten Merker - he's the export on this!


What differences should be expected when using qemu compared to
developing with real hardware? Performance will change noticeably,
threading may change quite a bit.


Wookey wants to know what cross targets are useful for ARM-hosted
systems. Talk to him!

ARM live images

We're planning on doing some arm64 (and maybe armhf) images in the
near future. Harder with armhf due to the variation in devices and
booting support. arm64 with UEFI will be much easier. Hoping to be
demoing stuff soon!


Work is planned to set up a LAVA service running tests and CI on ARM
devices hosted by Linaro, but there have been some holdups. More news
coming soon, hopefully.

ARM porting access

DDs have access to porter boxes already; Linaro is offering access to
ARMv8 devices for upstream porting too.

[1] http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/ARM_ports_BoF.webm
[2] http://www.einval.com/~steve/talks/Debconf15-state-of-the-arm/

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

Reply to: