10:22 a.m.
Hi all,
I wanted to kick off a discussion, I think that with the work that
Seneca is doing for armv6hl to support the Raspberry Pi most of the
need for building sfp has gone away. I would like us to drop support
for sfp in F19 that means that anyone running a kirkwood based system
would get supported software updates for approximately 13 months from
now. with cubie boards and other devices coming around that are cheap
and more powerful and similar options I think there is little benefit
to continuing to support sfp.
Ive put in a request to get numbers of people using the arm and armhfp
portions of mirrormanager to get some idea of the number of users out
there, though i suspect most arm are raspberry pi and people building
in mock.
Dennis
10:37 a.m.
On Fri, 25 Jan 2013 10:22:23 -0600, Dennis Gilmore <dennis(a)ausil.us>
wrote:
Hi all,
I wanted to kick off a discussion, I think that with the work that
Seneca is doing for armv6hl to support the Raspberry Pi most of the
need for building sfp has gone away. I would like us to drop support
for sfp in F19 that means that anyone running a kirkwood based system
would get supported software updates for approximately 13 months from
now. with cubie boards and other devices coming around that are cheap
and more powerful and similar options I think there is little benefit
to continuing to support sfp.
Ive put in a request to get numbers of people using the arm and
armhfp
portions of mirrormanager to get some idea of the number of users out
there, though i suspect most arm are raspberry pi and people building
in mock.
I am inclined to agree.
At the same time, however, this poses a few related questions?
With essentially dropping armv5tel, does it make sense to replace
it with what is very obviously going to be an arch with extremely
short-lived support-worthyness? Or would it be better to just drop
everything less than armv7hl and be done with it, and free up all
the resources for focusing on the primary target?
The focus question is particularly important considering that in
the near future there will also be the 64-bit ARM arch to support.
Or to put it another way - if armv5tel is drop-worthy, does
what is essentially one device (the Pi) warrant the maintenance
of an arch all by itself? If the answer to this is close to
yes, then what about dropping armv7hl in favour of armv6hl as
the only supported 32-bit ARM arch?
What is the performance gap, hardware being equal, between:
armv5tel -> armv6hl
armv6hl -> armv7hl
The answer to that question seems like it ought to factor
into any decision made.
Do any of the long standing issues of armv5tel (atomics?) go
away when using armv6hl?
Gordan
10:54 a.m.
On Fri, Jan 25, 2013 at 4:37 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
On Fri, 25 Jan 2013 10:22:23 -0600, Dennis Gilmore
<dennis(a)ausil.us> wrote:
>
> Hi all,
>
> I wanted to kick off a discussion, I think that with the work that
> Seneca is doing for armv6hl to support the Raspberry Pi most of the
> need for building sfp has gone away. I would like us to drop support
> for sfp in F19 that means that anyone running a kirkwood based system
> would get supported software updates for approximately 13 months from
> now. with cubie boards and other devices coming around that are cheap
> and more powerful and similar options I think there is little benefit
> to continuing to support sfp.
>
> Ive put in a request to get numbers of people using the arm and armhfp
> portions of mirrormanager to get some idea of the number of users out
> there, though i suspect most arm are raspberry pi and people building
> in mock.
I am inclined to agree.
At the same time, however, this poses a few related questions?
With essentially dropping armv5tel, does it make sense to replace
it with what is very obviously going to be an arch with extremely
short-lived support-worthyness? Or would it be better to just drop
everything less than armv7hl and be done with it, and free up all
the resources for focusing on the primary target?
The focus question is particularly important considering that in
the near future there will also be the 64-bit ARM arch to support.
Or to put it another way - if armv5tel is drop-worthy, does
what is essentially one device (the Pi) warrant the maintenance
of an arch all by itself? If the answer to this is close to
yes, then what about dropping armv7hl in favour of armv6hl as
the only supported 32-bit ARM arch?
We're not really replacing it. There's currently 3 arches across 2
koji instances. armv5tel and armv7 are on the "official" Fedora ARM
secondary and the armv6hl is a project being run by Seneca. We'd be
dropping armv5tel from the "official" project leaving only armv7 there
with Seneca continuing to run the armv6hl project separately. armv6hl
won't be added to the "official" Fedora ARM secondary infra.
This is in preparation of promoting armv7 to a primary architecture at
which point the Fedora ARM secondary will remain around for the
lifecycle of F-17 - F-19 for building of updates. Once F-19 (or what
ever the last armv7 release of Fedora ARM is as a secondary arch) is
EOL that infra would be decommissioned. The armv6hl infra will remain
as long as Seneca and others believe it's worth time in maintaining.
What is the performance gap, hardware being equal, between:
armv5tel -> armv6hl
armv6hl -> armv7hl
The answer to that question seems like it ought to factor
into any decision made.
Do any of the long standing issues of armv5tel (atomics?) go
away when using armv6hl?
Yes, atomics is supported on armv6hl.
11:17 a.m.
On 01/25/2013 08:22 AM, Dennis Gilmore wrote:
Hi all,
I wanted to kick off a discussion, I think that with the work that
Seneca is doing for armv6hl to support the Raspberry Pi most of the
need for building sfp has gone away. I would like us to drop support
for sfp in F19 that means that anyone running a kirkwood based system
would get supported software updates for approximately 13 months from
now. with cubie boards and other devices coming around that are cheap
and more powerful and similar options I think there is little benefit
to continuing to support sfp.
I've been thinking the same thing. This still gives people on kirkwood
plugs over a year of active support, and Pi users will continue to have
support via armv6hl. Another added benefit is that this will free up
rawhide build systems which can be used by other Fedora communities who
want to run projects on the ARM boxes (COPR, infra, etc).
Ive put in a request to get numbers of people using the arm and
armhfp
portions of mirrormanager to get some idea of the number of users out
there, though i suspect most arm are raspberry pi and people building
in mock.
That'll be some great information to have. It would be interesting to
know Seneca's Pi download stats, too.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
11:18 a.m.
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
Hi all,
I wanted to kick off a discussion, I think that with the work that
Seneca is doing for armv6hl to support the Raspberry Pi most of the
need for building sfp has gone away. I would like us to drop support
for sfp in F19 that means that anyone running a kirkwood based system
would get supported software updates for approximately 13 months from
now. with cubie boards and other devices coming around that are cheap
and more powerful and similar options I think there is little benefit
to continuing to support sfp.
I'm not overly familiar with arm, but from a kernel standpoint you might
be able to enable floating point emulation. That would let you run the
hardfp binaries on the boards without an FPU. It would be a performance
hit for things doing FP heavy computation, but you could continue
supporting those boards that way.
josh
12:09 p.m.
I have a lot of kirkwood, a pi, no armv7, and no $$ atm so Im not anxious to have support
dropped. :) I do understand the dilemma..:) I think kirkwood is about the only popular
armv5tel but there are other 926 chips running around, and the Cortex A5 only has an
optional FPU.
The part of the atomics issues are solved with libatomic which is part of the gcc 4.8, and
there is something available to 4.7 as well but it isn't built in, you have to link it
in. It is essentially a generic atomic functions, for cases where real atomics aren't
available or fully supported and an attempt at helping make them more generically
supported.
I was unable to rebuild gcc from the srpm which stimied a few relevent tests.
I was actually wondering if multi-lib support between the armv5tej and the armv6 might be
possible?? Then you have a hard/soft float distribution for thumb1 and still can do tricks
with jazelle. Then roll with armv7/armv8 as a multilib 64/32.
For me, the kirkwood is faster for dev then the raspi is, and the problem with the raspi
speed isn't all a Hard float issue.
One thing that might be easier that would speed up the builders a bit might be to start
precompiling the headers. The other would be to see if thumb1 is actually decently
supported. I think you will see a bigger boost with thumb instructions then you will with
hardfloat especially
given the io constraints on the raspi.
thumb2 is actually much better supported and it actually makes more sense to test thumb2
on armv7l+.
Does anyone know when the arch started supporting multiple thumb executions per clock?
I =would= like to see a full set of packages compiled on all the supported platforms asap.
Getting the kinks worked out is just going to help the whole process moving forward for
everyone.
----- Original Message -----
From: Josh Boyer <jwboyer(a)gmail.com>
To: Dennis Gilmore <dennis(a)ausil.us>
Cc: arm(a)lists.fedoraproject.org
Sent: Friday, January 25, 2013 12:18 PM
Subject: Re: [fedora-arm] arm software floating point support going forward
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
> Hi all,
>
> I wanted to kick off a discussion, I think that with the work that
> Seneca is doing for armv6hl to support the Raspberry Pi most of the
> need for building sfp has gone away. I would like us to drop support
> for sfp in F19 that means that anyone running a kirkwood based system
> would get supported software updates for approximately 13 months from
> now. with cubie boards and other devices coming around that are cheap
> and more powerful and similar options I think there is little benefit
> to continuing to support sfp.
I'm not overly familiar with arm, but from a kernel standpoint you might
be able to enable floating point emulation. That would let you run the
hardfp binaries on the boards without an FPU. It would be a performance
hit for things doing FP heavy computation, but you could continue
supporting those boards that way.
josh
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
12:10 p.m.
On Fri, 25 Jan 2013, Josh Boyer wrote:
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore
<dennis(a)ausil.us> wrote:
> Hi all,
>
> I wanted to kick off a discussion, I think that with the work that
> Seneca is doing for armv6hl to support the Raspberry Pi most of the
> need for building sfp has gone away. I would like us to drop support
> for sfp in F19 that means that anyone running a kirkwood based system
> would get supported software updates for approximately 13 months from
> now. with cubie boards and other devices coming around that are cheap
> and more powerful and similar options I think there is little benefit
> to continuing to support sfp.
I'm not overly familiar with arm, but from a kernel standpoint you might
be able to enable floating point emulation. That would let you run the
hardfp binaries on the boards without an FPU.
No, you can't.
The only FP emulation the ARM kernel provide is for the antique FPA
instruction set that almost never got implemented in hardware, except
for a few exceptions that Linux never supported anyway.
All modern EABI compliant binaries are using the VFP instruction set,
and the only thing the kernel implements is the processing of
exceptions for them. To have a full VFP emulation support in the
kernel, significant development effort would be needed.
Nicolas
12:15 p.m.
On Fri, Jan 25, 2013 at 1:10 PM, Nicolas Pitre <nico(a)fluxnic.net> wrote:
On Fri, 25 Jan 2013, Josh Boyer wrote:
> On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
> > Hi all,
> >
> > I wanted to kick off a discussion, I think that with the work that
> > Seneca is doing for armv6hl to support the Raspberry Pi most of the
> > need for building sfp has gone away. I would like us to drop support
> > for sfp in F19 that means that anyone running a kirkwood based system
> > would get supported software updates for approximately 13 months from
> > now. with cubie boards and other devices coming around that are cheap
> > and more powerful and similar options I think there is little benefit
> > to continuing to support sfp.
>
> I'm not overly familiar with arm, but from a kernel standpoint you might
> be able to enable floating point emulation. That would let you run the
> hardfp binaries on the boards without an FPU.
No, you can't.
OK.
The only FP emulation the ARM kernel provide is for the antique FPA
instruction set that almost never got implemented in hardware, except
for a few exceptions that Linux never supported anyway.
Ah. See, that would be where I point back to me knowning almost nothing
about ARM ;).
All modern EABI compliant binaries are using the VFP instruction
set,
and the only thing the kernel implements is the processing of
exceptions for them. To have a full VFP emulation support in the
kernel, significant development effort would be needed.
I find this slightly interesting to be honest. In the embedded powerpc
world, math emulation is used as a last ditch effort but it does exist.
I would have thought the proliferation of ARM devices would generate some
amount of interest in getting similar support in-kernel, but apparently
not.
Anyway, I'm not opposed to dropping a kernel variant at all. Makes some
things simpler.
josh
3:48 p.m.
On Fri, 25 Jan 2013, Josh Boyer wrote:
On Fri, Jan 25, 2013 at 1:10 PM, Nicolas Pitre
<nico(a)fluxnic.net> wrote:
> On Fri, 25 Jan 2013, Josh Boyer wrote:
>
>> On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
>> > Hi all,
>> >
>> > I wanted to kick off a discussion, I think that with the work that
>> > Seneca is doing for armv6hl to support the Raspberry Pi most of the
>> > need for building sfp has gone away. I would like us to drop support
>> > for sfp in F19 that means that anyone running a kirkwood based system
>> > would get supported software updates for approximately 13 months from
>> > now. with cubie boards and other devices coming around that are cheap
>> > and more powerful and similar options I think there is little benefit
>> > to continuing to support sfp.
>>
>> I'm not overly familiar with arm, but from a kernel standpoint you might
>> be able to enable floating point emulation. That would let you run the
>> hardfp binaries on the boards without an FPU.
>
> No, you can't.
OK.
> The only FP emulation the ARM kernel provide is for the antique FPA
> instruction set that almost never got implemented in hardware, except
> for a few exceptions that Linux never supported anyway.
Ah. See, that would be where I point back to me knowning almost nothing
about ARM ;).
> All modern EABI compliant binaries are using the VFP instruction set,
> and the only thing the kernel implements is the processing of
> exceptions for them. To have a full VFP emulation support in the
> kernel, significant development effort would be needed.
I find this slightly interesting to be honest. In the embedded powerpc
world, math emulation is used as a last ditch effort but it does exist.
I would have thought the proliferation of ARM devices would generate some
amount of interest in getting similar support in-kernel, but apparently
not.
Thing is: a soft float library in user space is 8 to 25 times faster
than any kernel emulation of machine FP instructions. I know that
as I wrote that soft-float library myself. ;-)
Before EABI, it was common to have user space binaryes compiled for FPA
and those instructions were always emulated by the kernel, since, as I
said, there were no actual FPA hardware that Linux supported.
When EABI was introduced, it was decided to go with the soft-float
library given the ABI was different anyway and performances were much
better than any emulation.
That was before VFP became a reality. With VFP hardware you then had
the ability to still use the same procedure call convention but the
ability to implement the intra procedure code using actual VFP
instructions. That is what most ARMv6+ binary distributions did prior
the HF variant to remain compatible with the soft-float ABI.
But given that hardware VFP is now prevalent, going with full FP even at
the function call level was implemented and deployed.
Nicolas
10:26 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 25 Jan 2013 10:22:23 -0600
Dennis Gilmore <dennis(a)ausil.us> escribió:
Hi all,
I wanted to kick off a discussion, I think that with the work that
Seneca is doing for armv6hl to support the Raspberry Pi most of the
need for building sfp has gone away. I would like us to drop support
for sfp in F19 that means that anyone running a kirkwood based system
would get supported software updates for approximately 13 months from
now. with cubie boards and other devices coming around that are cheap
and more powerful and similar options I think there is little benefit
to continuing to support sfp.
Ive put in a request to get numbers of people using the arm and armhfp
portions of mirrormanager to get some idea of the number of users out
there, though i suspect most arm are raspberry pi and people building
in mock.
since there has been no major objection i will disable building
armv5tel rpms in rawhide before the mass rebuild.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlEHT3AACgkQkSxm47BaWfdmPQCgrZULnBQfG7q+Q9pGqp08sVc0
ohUAoLfMLjzs9ldxxyCBim88zEYKSY/R
=SL8q
-----END PGP SIGNATURE-----
4:13 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Mon, 28 Jan 2013 22:26:19 -0600
Dennis Gilmore <dennis(a)ausil.us> escribió:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 25 Jan 2013 10:22:23 -0600
Dennis Gilmore <dennis(a)ausil.us> escribió:
> Hi all,
>
> I wanted to kick off a discussion, I think that with the work that
> Seneca is doing for armv6hl to support the Raspberry Pi most of the
> need for building sfp has gone away. I would like us to drop support
> for sfp in F19 that means that anyone running a kirkwood based
> system would get supported software updates for approximately 13
> months from now. with cubie boards and other devices coming around
> that are cheap and more powerful and similar options I think there
> is little benefit to continuing to support sfp.
>
> Ive put in a request to get numbers of people using the arm and
> armhfp portions of mirrormanager to get some idea of the number of
> users out there, though i suspect most arm are raspberry pi and
> people building in mock.
since there has been no major objection i will disable building
armv5tel rpms in rawhide before the mass rebuild.
the next rawhide compose will be hfp only
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlEISZEACgkQkSxm47BaWfcMhgCfTXYh6hnV1EVfn6N4WxSbVEo4
qY4AoIWbTfosWMpS8PPGELhZsWcIeCcU
=FvMg
-----END PGP SIGNATURE-----
8:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 29 Jan 2013 16:13:33 -0600
Dennis Gilmore <dennis(a)ausil.us> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Mon, 28 Jan 2013 22:26:19 -0600
Dennis Gilmore <dennis(a)ausil.us> escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El Fri, 25 Jan 2013 10:22:23 -0600
> Dennis Gilmore <dennis(a)ausil.us> escribió:
> > Hi all,
> >
> > I wanted to kick off a discussion, I think that with the work that
> > Seneca is doing for armv6hl to support the Raspberry Pi most of
> > the need for building sfp has gone away. I would like us to drop
> > support for sfp in F19 that means that anyone running a kirkwood
> > based system would get supported software updates for
> > approximately 13 months from now. with cubie boards and other
> > devices coming around that are cheap and more powerful and
> > similar options I think there is little benefit to continuing to
> > support sfp.
> >
> > Ive put in a request to get numbers of people using the arm and
> > armhfp portions of mirrormanager to get some idea of the number of
> > users out there, though i suspect most arm are raspberry pi and
> > people building in mock.
>
> since there has been no major objection i will disable building
> armv5tel rpms in rawhide before the mass rebuild.
the next rawhide compose will be hfp only
now that we have had a hfp only compose ive disabled building armv5tel
rpms in koji for f19
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlEJM9wACgkQkSxm47BaWfdWPQCgupoHyYZ6lQH78Ak31qdiLyFG
6wAAoLM4Gnzx/+yyNkwWgPiYJMhwzR0S
=heWZ
-----END PGP SIGNATURE-----
9:21 a.m.
On Mon, 2013-01-28 at 22:26 -0600, Dennis Gilmore wrote:
El Fri, 25 Jan 2013 10:22:23 -0600
Dennis Gilmore <dennis(a)ausil.us> escribió:
> Hi all,
>
> I wanted to kick off a discussion, I think that with the work that
> Seneca is doing for armv6hl to support the Raspberry Pi most of the
> need for building sfp has gone away. I would like us to drop support
> for sfp in F19 that means that anyone running a kirkwood based system
> would get supported software updates for approximately 13 months from
> now. with cubie boards and other devices coming around that are cheap
> and more powerful and similar options I think there is little benefit
> to continuing to support sfp.
>
> Ive put in a request to get numbers of people using the arm and armhfp
> portions of mirrormanager to get some idea of the number of users out
> there, though i suspect most arm are raspberry pi and people building
> in mock.
since there has been no major objection i will disable building
armv5tel rpms in rawhide before the mass rebuild.
Dennis
I guess it's too late now, but I got a few days behind on my list
emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would
be very disappointed to see support for them being dropped from Fedora.
For me, I still see quite a lifetime in them for what they are doing.
Quentin Armitage
9:30 a.m.
Quentin Armitage píše v Čt 31. 01. 2013 v 15:21 +0000:
On Mon, 2013-01-28 at 22:26 -0600, Dennis Gilmore wrote:
> El Fri, 25 Jan 2013 10:22:23 -0600
> Dennis Gilmore <dennis(a)ausil.us> escribió:
> > Hi all,
> >
> > I wanted to kick off a discussion, I think that with the work that
> > Seneca is doing for armv6hl to support the Raspberry Pi most of the
> > need for building sfp has gone away. I would like us to drop support
> > for sfp in F19 that means that anyone running a kirkwood based system
> > would get supported software updates for approximately 13 months from
> > now. with cubie boards and other devices coming around that are cheap
> > and more powerful and similar options I think there is little benefit
> > to continuing to support sfp.
> >
> > Ive put in a request to get numbers of people using the arm and armhfp
> > portions of mirrormanager to get some idea of the number of users out
> > there, though i suspect most arm are raspberry pi and people building
> > in mock.
>
> since there has been no major objection i will disable building
> armv5tel rpms in rawhide before the mass rebuild.
>
> Dennis
I guess it's too late now, but I got a few days behind on my list
emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would
be very disappointed to see support for them being dropped from Fedora.
For me, I still see quite a lifetime in them for what they are doing.
Fedora provides all tools to run armv5tel as say tertiary architecture,
just needs a volunteer with some hardware.
Dan
9:35 a.m.
Quentin Armitage <quentin(a)armitage.org.uk> writes:
since there has been no major objection i will disable building
armv5tel rpms in rawhide before the mass rebuild.
Dennis
I guess it's too late now, but I got a few days behind on my list emails. I
use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would be very
disappointed to see support for them being dropped from Fedora. For me, I
still see quite a lifetime in them for what they are doing.
I've mentioned multiple times my hope to keep kirkwood support in
Fedora, but alas it feels like the powers that be just don't care about
us *plug users. :( If I want to continue using my plugs I guess I'll
have to learn Debuntu. :(
Quentin Armitage
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord(a)MIT.EDU PGP key available
1:13 p.m.
On 01/31/2013 07:21 AM, Quentin Armitage wrote:
I guess it's too late now, but I got a few days behind on my
list
emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would
be very disappointed to see support for them being dropped from Fedora.
For me, I still see quite a lifetime in them for what they are doing.
Remember the plugs will be supported throughout the F18 lifecycle, so
you still have over a year of support.
Others are welcome to pick up the torch and run an armv5tel koji
server/builds. We're all volunteers on this project, pursuing our
individual interests. If v5 is yours, feel free to chip in.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
4096
days inactive
4102
days old
16 comments
11 participants
participants (11)
-
Brendan Conoboy -
Dan Horák -
Dennis Gilmore -
Derek Atkins -
Gordan Bobic -
Josh Boyer -
Nicolas Pitre -
Peter Robinson -
Quentin Armitage -
Sean Omalley -
Till Maas