AArch64 planning BoF at DebConf

July 20th, 2012 - 11:20 am ET by Steve McIntyre | Report spam

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

Hi folks,

Here's a summary of what we discussed in the AArch64 port planning BoF
[1] last week (10th July). Thanks to the awesome efforts of the
DebConf video team, the video of the session is already online [2] in
case you missed it. I've also attached the Gobby notes that were taken
during the session. Again, thanks to the people who took part - we had
a very useful discussion. Slides are up on my website [3].

Naming

Naming issues: ARM are calling the new 64-bit architecture
AArch64. Other people don't like that and various other names have
been proposed for use elsewhere. Debian/Ubuntu developers have already
picked the name "arm64" in dpkg and elsewhere.

ARMv8 summary
=

For more details, look at http://arm.com/architecture. Quick summary:

* Carries over the ARMv7 feature set.
* First 64bit ARM CPU, runs 32bit code too.
* ARM Neon SIMD.
* VFPv3 as from ARMv7.
* Includes ARM proprietary security extensions.
* Supports virtualisation and LPAE.

New 64-bit (A64) instruction set
==

* Fixed length 32-bit instructions.
* 5 bits of register space -> 31 general purpose 64 bit registers.
* SIMD 32x128bit registers
* Better support for different FP modes
* Improved atomic support
* Neon required (believed, but confirm!)

Roadmap
=

* ARMv7 will continue. Cortex-A9, Cortex-A15, Cortex-A7 etc.
* ARMv8 under development.
* Expect to see first v8 hardware late 2013 onwards, specs due later
in 2012.

Demo
=

I showed an ARM "Fast Model" running AArch64 software: a Linux kernel
(3.4) and an Ubuntu (Natty) based userland. The userland AArch64
software was all built using xdeb. Basic-ish LAMP stack for
demonstration (as might be expected for a simple server workload):
Apache, Postgres, Dropbear ssh, PHP. Not a *quick* machine to run
things in, but fast enough for demonstration and verification.

Also demonstrated a 32-bit armhf chroot: standard 32-bit software
build as provided elsewhere in Debian/Ubuntu, no changes
needed. AArch64 will happily run existing ARM software. Showed Xorg,
xfce and firefox running.

Bootstrapping
=

Kernel patches for AArch64 have just been sent upstream for comments
on Friday 6th July[5].

The toolchain already works (as you can see from the demo). gcc
patches are already in a branch upstream[4], binutils etc. coming
shortly. People are currently cross-building small systems and testing
in the model.

ARM and Linaro are going to be helping by working on projects to aid
bootstrapping:

* Basic OpenEmbedded rootfs
* Backporting toolchain changes into gcc 4.7
* Shared bug tracker at Linaro to help sharing issues and patches
across distros

I'm hoping to get AArch64 bootstrapped and ready for release in Debian
by Wheezy+1, which I acknowledge will take a lot of work in a
comparatively short space of time. We will need to cross-bootstrap as
much as possible, verifying things in the model. Existing bootstrap
work done by Wookey and co. will help a lot here. As soon as we can
get access to hardware, start building natively and try and get into
debian-ports. *If* we can get everything going well, into main archive
ASAP after that.

It's useful that ARMv8 will happily run existing armhf software, so we
can run that as a base on systems for build machines etc. We've learnt
the lesson from armhf bringup that using unstable to host buildds is
painful!

Because of multi-arch, we will also get to use 32-bit armhf software
elsewhere where it's useful, e.g. 32-bit openjdk will run out of the
box until we get a 64-bit version.

Misc
=

There's no support in qemu yet, but many people are interested in it
for a variety of reasons. Once sufficient specs are released, I'd
expect work to happen quickly.

How to help
==

First things first: make sure your packages cross-build well, and make
your Multi-Arch build-dependencies work. There are a lot of patches
already in the BTS to help with these.

Next: help make more of the archive work for automatic bootstrapping
and cross-building.

Once we can get hold of models and then hardware, help to test and
verify more of the system. Fun places to get involved are language
bootstraps - in many cases, the runtime / compiler for a language will
be written *in* that language, so there's work to cross-bootstrap the
first build and bring things up from there.

Get involved on the debian-arm list (and elsewhere) and keep
communicating about what you're working on and what you'd like to do.

[1] http://penta.debconf.org/dc12_sched...82.en.html
[2] http://meetings-archive.debian.net/...anning.ogv
[3] http://www.einval.com/~steve/talks/Debconf12-aarch64/
[4] svn://gcc.gnu.org/gcc/branches/ARM/aarch64branch
[5] http://lkml.indiana.edu/hypermail/l...03025.html

Steve McIntyre, Cambridge, UK. steve@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Please take notes here
ARM insist on it being called AArch64. Likely to be arm64 in Debian (name
already in dpkg arch tables, and autoconf tests).
ARMv8 summary
Carries over the ARMv7 feature set. First 64bit ARM CPU, runs 32bit code too.
ARM Neon SIMD. VFPv3 as from ARMv7. Includes ARM proprietary security extensions.
supports virtualisation and LPAE. Fixed length 32-bit instructions.
5 bits of register space, 31 general purpose 64 bit registers.
SIMD 32x128bit registers. Better support for FP.
Improved atomic support. Neon required.

Roadmap
ARMv7 will continue. Cortex-A9 A15, A7 etc.
ARMv8 under development. Hardware late 2013 onwards, specs late 2012.
http://arm.com/architecture

Demo
"FastModel", Ubuntu based system. Linux 3.4 for the model. Some port work
already done for apache, dropbear etc. All crossbuilt Maverick/Natty
using xdeb. 130+ packages built. For the demo, running a 32bit armhf Xorg
and firefox.

Bootstrapping
Toolchain does work. Cross built base system tested via model.
Kernel patches sent upstream for comments on Friday
(http://lkml.indiana.edu/hypermail/l...03025.html).
Basic rootfs via OpenEmbedded
Toolchain changes to be backported to gcc-4.7
Shared bug tracker.

Cross-bootstrap for Debian.
Wheezy+1 would be nice.
openjdk 32 bit will run out of the box due to MultiArch.

To help:
Make packages cross-build well and make your build-dependencies MultiArch.

To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120720151222.GB11301@einval.com

Follow the discussion Replies

8 replies

Make a reply

Replies

#1 Henrique de Moraes Holschuh

July 20th, 2012 - 04:00 pm ET | Report spam

On Fri, 20 Jul 2012, Steve McIntyre wrote:

Naming
==>
Naming issues: ARM are calling the new 64-bit architecture
AArch64. Other people don't like that and various other names have
been proposed for use elsewhere. Debian/Ubuntu developers have already
picked the name "arm64" in dpkg and elsewhere.

Maybe a patch should be sent to GNU config upstream so that arm64
becomes known to config.sub and config.guess as an alias for aarch64?

If the answer is yes, please do so ASAP and mail me as soon as you get a
go from upstream, so that I can fold the change in autotools-dev and
request a freeze exception to get the alias in Wheezy.

"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

Reply to this message

#2 Wookey

July 20th, 2012 - 09:20 pm ET | Report spam

+++ Henrique de Moraes Holschuh [2012-07-20 16:55 -0300]:

On Fri, 20 Jul 2012, Steve McIntyre wrote:
> Naming
> ==> >
> Naming issues: ARM are calling the new 64-bit architecture
> AArch64. Other people don't like that and various other names have
> been proposed for use elsewhere. Debian/Ubuntu developers have already
> picked the name "arm64" in dpkg and elsewhere.

Maybe a patch should be sent to GNU config upstream so that arm64
becomes known to config.sub and config.guess as an alias for aarch64?

That's not necessary, because dpkg (-architecture) does the necessary
conversions between 'debian arch name' and 'GNU arch/triplet names'.

So autotools already has aarch64-linux-gnu and that works fine with
Debian (in the same way that 'amd64' is 'x86_64-linux-gnu' from a GNU
tools POV). The one _good_ reason for using the aarch64 name is avoiding
accidental matches with arm* in various bits of configery so leaving
that alone probably makes sense despite the silly name.

Arm64 everywhere would have been neater but unless someone is
volunteering for a massive argument and changing upstream gcc and
glibc and autofoo and volunteering to fix up the configery that will
break in numerous places it's best left well alone. (I was all for
changing it for a while, but have been persuaded, not by ARM, I hasten
to add :-) that we have more important things to do with our time than
bikeshed about upstream's funny naming, which does at least have the
major benefit of being a unique string.)

Wookey
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

Reply to this message

#3 Henrique de Moraes Holschuh

July 20th, 2012 - 09:50 pm ET | Report spam

On Sat, 21 Jul 2012, Wookey wrote:

Arm64 everywhere would have been neater but unless someone is
volunteering for a massive argument and changing upstream gcc and

No way. it is difficult to do better at this kind of thing than Linus, and
he has already said his piece :-p It won't be aarch64 in the kernel either,
AFAIK.

changing it for a while, but have been persuaded, not by ARM, I hasten
to add :-) that we have more important things to do with our time than
bikeshed about upstream's funny naming, which does at least have the
major benefit of being a unique string.)

Yeah, but it did make the world a bit uglier. Oh well. It could be worse,
it could be an iArm, or an iLeg, instead of an aarch ;-)

"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

Reply to this message

#4 Luke Kenneth Casson Leighton

July 20th, 2012 - 10:20 pm ET | Report spam

On Fri, Jul 20, 2012 at 4:12 PM, Steve McIntyre wrote:

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

noted :)

I'm hoping to get AArch64 bootstrapped and ready for release in Debian
by Wheezy+1, which I acknowledge will take a lot of work in a
comparatively short space of time. We will need to cross-bootstrap as
much as possible, verifying things in the model. Existing bootstrap
work done by Wookey and co. will help a lot here.

*scratches head*... um... gah, this is awkward. where do i begin.
ok, cast your minds back to when, to begin the armhf port,
konstantinous was having a hell of a job getting beyond the circular
build dependencies (within even the core packages) that have crept
into the debian packaging. not the install dependencies of the core
packages, which are known to be circular, but the *build*
dependencies.

worst-case example: if you want to build a new version of a package,
you have to have the old one's header file package installed. but to
build that one, you need the previous... and so on, eventually getting
back possibly several *years* to a time when that circular build
dependency didn't exist, but of course the source code for those older
packages and *their* build dependencies could possibly now no longer
exist (especially if the cross-over point was isolated in between
debian major releases)

if you recall, i asked konstantinous if he could best document all of
the circular build dependencies that he had encountered, so that the
issues that he had encountered could be addressed, or the work-arounds
that he created could be duplicated in future, possibly in an
automated fashion. he declined to do so, unfortunately. also, a
number of people, if i recall, mentioned words to the effect of "new
architectures don't come along that often, so don't worry about it".

@begin awkward embarrassing moment, feel free to gloss over
i also made some recommendations and offered to knock together a build
infrastructure which would have augmented the existing debian build
system, (which would have leveraged the best free software
cross-compiling and qemu-compile-enabled toolchain that there is, and
made it debian-aware) but the recommendations were, sadly, viewed as -
once again - "oo the fuck's this lkcl telling us what the fuck to do,
we've been doing this for years, oo der fuck does ee fink ee is,
trying to take over debian, let's vilify him, deliberately
misunderstand what he's saying as much as we can as often as we can,
make him look a fool so we look good and he'll go away ahhh that's
better: we can go back to doing it our way, now, and stay in control
yessss" rather than being viewed as what they were offered as: an
augmentation of and an enhancement of the existing debian build
system, offered *without* prejudice and entirely in good faith.
@end awkward moment.

*rueful*.

so, anyway. *shakes head to clear the air*.

here we are, only 18 months later, and there's *another* architecture
already on the horizon (*1)! whilst this is fantastic news, and very
very exciting, i really don't know whether to laugh or cry in sympathy
at the task ahead for the key debian developers, especially you,
wookey.

i just hope that there's some trick that can be pulled, here -
something like starting up with an arm64 kernel but running pure
32-bit packages, then being able compile one-by-one each package as
well as its 32-bit mapping in /usr/lib64, instead of having to do a
complete total laborious "everything-in-one-go" hacked-together
bootstrap like konstantinous had to.

i'm sure i saw a procedure somewhere, dating back to 2005, which
allowed a live 32-bit i386 debian system to be upgraded (without a
total reinstall!) live to an amd64 one, but... yeah, iii don't believe
it involved having to build every single amd64 package first :)

well - good luck: i'm rooting for ya! things are just moving so fast
in the ARM world, it's amazing.

l.

(*1) ... and what happens when there's an arm64 armv9 or armv10 or...
arm64-die-hard-with-a-vengeance-float, such that *another*
architecture is needed? what happens if the gnu/hurd team get some
resources together and want to do an arm-hurd *and* an arm64-hurd
architecture? what will it take to make the task of creating new
architectures that much easier than it is right now?

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/CAPweEDwyzN...XZR4pQ3wy=

Reply to this message

#5 Lars Wirzenius

July 21st, 2012 - 03:00 am ET | Report spam

On Sat, Jul 21, 2012 at 02:12:41AM +0100, Wookey wrote:

tools POV). The one _good_ reason for using the aarch64 name is avoiding
accidental matches with arm* in various bits of configery so leaving
that alone probably makes sense despite the silly name.

How much of the arm* silliness is there actually? There's already quite
significant changes between various arm sub-architectures, so matching
on arm* can already be considered a bad idea.

I wrote a book on personal productivity: http://gtdfh.branchable.com/

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

Reply to this message

Create a new topicNext page

Make a reply

Make your own search

AArch64 planning BoF at DebConf

Similar topics

Replies