Hi folks,
Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference [1]. I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.
We had some lively discussion about the state of ARM Linux distros at
the Linaro Connect [2] event in Cambridge last week. It rapidly became
clear that some of the topics we discussed deserve a wider audience,
so we're suggesting a meetup at Plumbers for that bigger
discussion. The initial proposed agenda is:
* ARM hard-float
+ What is it and why does it matter?
+ How can distributions keep compatible (i.e. gcc triplet to
describe the port)?
* Adding support for ARM as an architecture to the Linux Standard
Base (LSB)
+ Does it matter?
+ What's needed?
* FHS - multi-arch coming soon, how do we proceed?
* 3D support on ARM platforms
+ Open GL vs. GLES - which is appropriate?
but I'm sure that other people will think of more issues they'd like
to discuss. :-)
If you wish to attend, please reply to the cross-distro list and let
us know to expect you. Make sure you're registered to attend Plumbers
Conf, and get your travel and accommodation organised ASAP.
[1] http://www.linuxplumbersconf.org/2011/
[2] http://connect.linaro.org/
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
[ Please forward this to anyone else who should get a copy - and ask
them to signup to cross-distro@linaro because that's where we'll talk ]
Folks,
At the 2011 Linux Plumbers Conference in Santa Rosa, we held an ARM
minisummit to discuss a few cross-distribution issues surrounding the
"hard float" ABI for v7, and the ARM device and OS ecosystem in general.
This mail is intended to summarize the key actions from that meeting.
1). We discussed some of the different distributions (Debian, ChromeOS,
Fedora, MeeGo, Mozilla, Ubuntu, etc.). We all agree on a common notion
of what "hard float" means: it's the ARM AAPCS hardware floating point
stuff in section 6, with the -d16 register set of the VFPv3 being used.
Although there is some possibility to standardize v6, we decided we are
interested only in the present and future at this point (and that's v7).
Some use Thumb2, some don't, but interworking allows for that (we in
Fedora accidentally built a few packages with Thumb2 and will be undoing
that without users even noticing). NEON is similarly an optional feature
(supported by hwcaps) and not a required part of the core ABI. So it's
really just the ABI that we all care about, and we all agree on it.
For toolchain folks, this means we all agree on the following:
--with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux
(some of us may target different optimizations, etc. of course but that
is down to an application to decide whether it cares only about Cortex+)
2). We agreed on the importance of cross-distro binary compatibility. It
seems a number of distributions are excited by Debian's multi-arch
approach (as am I), but not all of us will be moving to it any time
soon. In the shorter term, if the runtime linker will have a special
path, we can work around that with symlinks, but it's a kludge. Our
preferred goal (from the meeting) is that everyone use this target:
arm-linux-gnueabihf
(Red Hat toolchains will include the vendor, but it is dropped by
autotools when actually generating the paths and comparisons). I will
advocate for Fedora ARM to switch to this target when possible, and in
the interim will try to ensure we can establish some symlinks for the
ability to run binaries compiled against Debian and Ubuntu on Fedora. I
don't know what our timeline will be for this, but it's not something
that's really landed everywhere yet. We at least agree on paths now!
3). We agree that it is a good idea to do LSB. Adam Conrad (Canonical)
and I agreed to represent community interests in driving this. We do
know that we'll be preferring OpenGL ES 2.0 over OpenGL (same namespace
within the library means one default choice is required). There will be
many other things :) We agree that the main benefit to pursuing LSB is
that it promotes the idea of working together and being compatible. It
may be that we don't have the same level of compliance on ARM, but some
level of conformance to some common standard(s) is a good start! :)
4). We decided that we should have a standing Cross Distro meeting at
Linaro Connect events, beginning with the next one in November. We will
also facilitate a "show and tell" for apps at Connect, and have an
opportunity to demo different distributions. We will add a specific
session at the next Connect to continue this discussion.
Finally, we agreed we should keep the conversation going. I apologize
for being a little tardy in sending this mail, but I want to kickstart
further discussion and get this ball rolling again. I'll ping Adam about
LSB (and thanks again to Jesse for the deep dive on GL). Meanwhile,
David can grab ownership of organizing the Cross Distro meeting at
Connect (I would like to assist). Anyone else got actions?
Jon.
Hi,
Sorry for the cross post and long email :-)
Currently I am working on a very initial state build of Mandriva for arm.
Thanks to Jeff Johnson for giving me ssh access to armv7 hosts, and
Matthew Dawkins for building several Mandriva/Unity linux armv5
packages.
What I am trying to understand now is about choice of float abi.
I understand that the IHI0042D_aapcs.pdf file I donwload says
to use vfp registers for float/double arguments, but softfp seems
too good to miss, as armv5 should be around for some time yet.
So, I have two chroots, running:
softfp# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper
Target: armv7l-mandriva-linux-gnueabi
Configured with:
/home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure
--prefix=/usr --build=i586-mandriva-linux-gnu
--host=armv7l-mandriva-linux-gnueabi
--target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx
--with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux
--enable-languages=c,c++ --enable-threads=posix --disable-libssp
--disable-libmudflap
Thread model: posix
gcc version 4.6.1 20110722 (Mandriva) (GCC)
thumb# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper
Target: armv7l-mandriva-linux-gnueabi
Configured with:
/home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure
--prefix=/usr --build=i586-mandriva-linux-gnu
--host=armv7l-mandriva-linux-gnueabi
--target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx
--with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a
--with-mode=thumb --with-float=hard --with-fpu=vfpv3-d16
--with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix
--disable-libssp --disable-libmudflap
Thread model: posix
gcc version 4.6.1 20110722 (Mandriva) (GCC)
This is unmodified upstream gcc, and using a set of bootstrap
scripts from a git branch I made on a checkout of
git clone git://fedorapeople.org/~djdelorie/bootstrap.git
Since I am still very "arm noob" :-) and just yesterday did
the thumb build to learn about thumb, so far, my impression
is that the best approach should be to use thumb+softfp.
Just so you know I am running thumb and arm builds, with
thumb using hard float and the softfp with arm instructions set:
softfp# objdump -d /usr/lib/libm.so | less
[...]
00008d30 <__ieee754_atan2>:
8d30: e3a0c000 mov ip, #0
8d34: e347cff0 movt ip, #32752 ; 0x7ff0
8d38: e92d4030 push {r4, r5, lr}
8d3c: ed2d8b10 vpush {d8-d15}
8d40: e3a05000 mov r5, #0
8d44: ec432b18 vmov d8, r2, r3
8d48: e3475ff0 movt r5, #32752 ; 0x7ff0
8d4c: e003c00c and ip, r3, ip
8d50: e15c0005 cmp ip, r5
8d54: e24dd02c sub sp, sp, #44 ; 0x2c
8d58: e1a04003 mov r4, r3
8d5c: ec410b19 vmov d9, r0, r1
8d60: e1a05002 mov r5, r2
8d64: 0a000022 beq 8df4 <__ieee754_atan2+0xc4>
[...]
thumb# objdump -d /usr/lib/libm.so | less
[...]
00007884 <__ieee754_atan2>:
7884: 2100 movs r1, #0
7886: 2000 movs r0, #0
7888: f6c7 71f0 movt r1, #32752 ; 0x7ff0
788c: ec53 2b11 vmov r2, r3, d1
7890: f6c7 70f0 movt r0, #32752 ; 0x7ff0
7894: 4019 ands r1, r3
7896: 4281 cmp r1, r0
7898: e92d 03f0 stmdb sp!, {r4, r5, r6, r7, r8, r9}
789c: ed2d 8b10 vpush {d8-d15}
78a0: 461c mov r4, r3
78a2: b08a sub sp, #40 ; 0x28
78a4: eeb0 8b41 vmov.f64 d8, d1
78a8: 4616 mov r6, r2
78aa: eeb0 9b40 vmov.f64 d9, d0
78ae: d03c beq.n 792a <__ieee754_atan2+0xa6>
[...]
I am kind of trying to figure what "The Industry" says about it,
and just checked the linaro gcc-4.6 relevant changes for me
right now, that are...
+ --with-arch=armv7-a --with-tune=cortex-a8 \
+ --with-float=$(float_abi) --with-fpu=neon \
+# check if we're building for armel or armhf
+ifeq ($(DEB_TARGET_ARCH),armhf)
+ float_abi := hard
+else ifneq (,$(filter $(DEB_TARGET_ARCH), arm armel))
+ float_abi := softfp
+endif
If I understand correctly, neon will have better support for
simd instructions right?
Either way, I used two simple benchmarks to try to sell
myself the idea of breaking compatibility with armv5 or
older binaries, but still not convinced, but, as I said, we
should use whatever "The Industry" chooses :-)
I used for benchmark http://www.tux.org/~mayer/linux/bmark.html
and http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI…
and also compared with my home computer (quad)core i5 x86_64,
and attached results...
Thanks and again sorry for cross posting and long email,
Paulo
On 28.09.2011, at 12:50, Steve McIntyre wrote:
> On Tue, Sep 27, 2011 at 06:31:51PM +0200, Alexander Graf wrote:
>> On 27.09.2011, at 18:19, Steve McIntyre wrote:
>>>
>>> Out of curiosity, what are you using as a triplet for your hard-float
>>> port? The discussion at LPC focussed on this to some extent:
>>>
>>> http://lists.linaro.org/pipermail/cross-distro/2011-September/000054.html
>>
>>
>> Ah, nice. I didn't find that mail before. I only found one where the
>> discussion on the target names "armhf" and "armv7hl" was raised, so
>> we named the target "armv7hl" to be compatible with Fedora and Meego.
>
> Fair enough, the internal name doesn't matter much. :-)
Well, it actually does matter because rpm compares it with the output of uname to check if the architecture is compatible. However, if we call it "armv7hl", we are incompatible with armv7l which logically would be missing VFP capabilities. Now, uname unfortunately only emits armv7l (see arch/arm/mm/proc-v7.S), so we never know if our host is capable of running armv7hl code.
So we can either build our packages against armv7hl, breaking the assumption that we can find the machine type from uname (basically adding a hack that armv7hl is compatible to armv7l).
Or we could build our packages against armv7l which is what the kernel emits (good!), but would diverge from how Fedora and Meego call their packages.
We're currently not sure which path would be the better one to walk down on. What's the rationale from the other distro folks here?
Alex
Please coordinate with Jon Masters at RedHat/Fedora and Adam Conrad at
Ubuntu/Debian on this. (Cc'ing the cross-distro list, through which the
recent ARM summit at Linux Plumbers was organized.)
Cheers,
- Michael
On Sep 16, 2011 8:41 AM, "David Gilbert" <david.gilbert(a)linaro.org> wrote:
> OK, so we seem to have agreement here that what we want is autodetect
> for eglibc and
> forget about the triplet; well technically that probably makes my life
> easier, and I don't
> think it's too hard a sell.
>
> Dave
>
> _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Folks,
I want to let you know I have some notes from LPC that I will be sending
out. I didn't get to this on Friday, so I plan to have it out first
thing Mon. I'll followup to this thread once I have that taken care of.
Jon.
Jon Masters <jcm(a)edison.jonmasters.org> wrote:
>---begin log---
>jonmasters [19:14:43] <infinity:#linaro-armhf> lool: jonmasters took
>pretty comprehensive notes, not sure if he's sent them anywhere yet.
>jonmasters [19:14:59] <infinity:#linaro-armhf> jonmasters: ^
>---end of log---
I will send notes later. Before Mon anyway.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Folks,
A couple of things from me. Split into two sections:
Dialin
------
IRC: #linaro-armhf (irc.freenode.net)
Time: 8pm Pacific tonight.
I have had a special line setup on the Red Hat Conference system. To
dial into this, use one of the following country-specific codes with the
access code of 6177591337 (which is my US cellphone number btw).
Global Network Access
Toll-Free Dial-in Numbers:
Australia : 1800337169
Brazil : 08008921002
Finland : 0800117116
France : 0805632867
Germany : 08006647541
United Kingdom: 08006948057
United States: 18004518679
Agenda
------
(Steve already sent out a comprehensive agenda)
To Steve's other point around topics for tonight, I agree that the only
things (being brutally honest also here) I really care about is
hardfloat and standardization. I think we should collectively consider
at the start of the meeting whether it makes sense (IMO it does) to
confine our discussion to topics we can make progress on in the limited
time that we have. I also suggest seeing if we can find another time to
followup tomorrow that we can all agree on. For those of us here in
person, I assume there can be dinner/beverages after. I am open to
grabbing a late dinner if anyone else is interested too.
Topics I would like to specifically include in the discussion:
1. Agree that all the distros want hard float. And what that means (just
refer to the AAPCS stuff we all already know). Basically a statement "we
the assembled Linux community will be supporting a common definition of
hardfloat in our distributions", etc. I have people asking me on and off
about hardfloat thinking every distro is doing its own thing...which
actually is far worse than reality. So, let's fix this with a generic
fluffy media-friendly statement.
2. Cross standardization. Not just LSB but how are we going to keep
these discussions going? There is the hardfloat IRC channel, etc. but I
think this is bigger than HF. I want an ongoing cross-distro discussion
around ARM standards. That can be cross-distro, but it *must* actually
have some agreed framework, with regular syncups. I would go as far as
to say we need a regular phone call (can be once a month) just to force
us all to keep this collective ball rolling.
Thanks!
Jon.
P.S. Please forward this information to anyone else who should dial in.
I am not yet certain this will actually work given that this isn't a
regular LF event so the folks I would usually ask for assistance hooking
this up (an actual, non-cell phone with some kind of speakerphone that
will work, etc.) but I'm pinging folks now.
