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
On Fri, 25 Jan 2013 10:22:23 -0600, Dennis Gilmore dennis@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
On Fri, Jan 25, 2013 at 4:37 PM, Gordan Bobic gordan@bobich.net wrote:
On Fri, 25 Jan 2013 10:22:23 -0600, Dennis Gilmore dennis@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.
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.
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore dennis@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
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@gmail.com To: Dennis Gilmore dennis@ausil.us Cc: arm@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Fri, 25 Jan 2013, Josh Boyer wrote:
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore dennis@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
On Fri, Jan 25, 2013 at 1:10 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Fri, 25 Jan 2013, Josh Boyer wrote:
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore dennis@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
On Fri, 25 Jan 2013, Josh Boyer wrote:
On Fri, Jan 25, 2013 at 1:10 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Fri, 25 Jan 2013, Josh Boyer wrote:
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore dennis@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 25 Jan 2013 10:22:23 -0600 Dennis Gilmore dennis@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 SIGNED MESSAGE----- Hash: SHA1
El Mon, 28 Jan 2013 22:26:19 -0600 Dennis Gilmore dennis@ausil.us escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 25 Jan 2013 10:22:23 -0600 Dennis Gilmore dennis@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 SIGNED MESSAGE----- Hash: SHA1
On Tue, 29 Jan 2013 16:13:33 -0600 Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Mon, 28 Jan 2013 22:26:19 -0600 Dennis Gilmore dennis@ausil.us escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 25 Jan 2013 10:22:23 -0600 Dennis Gilmore dennis@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
On Mon, 2013-01-28 at 22:26 -0600, Dennis Gilmore wrote:
El Fri, 25 Jan 2013 10:22:23 -0600 Dennis Gilmore dennis@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
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@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
Quentin Armitage quentin@armitage.org.uk writes:
since there has been no major objection i will disable building armv5tel rpms in rawhide before the mass rebuild. DennisI 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
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 -
Dan Horák -
Dennis Gilmore -
Derek Atkins -
Gordan Bobic -
Josh Boyer -
Nicolas Pitre -
Peter Robinson -
Quentin Armitage -
Sean Omalley -
Till Maas