[fedora-arm] arm software floating point support going forward
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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
On Fri, Jan 25, 2013 at 4:37 PM, Gordan Bobic gor...@bobich.net wrote: On Fri, 25 Jan 2013 10:22:23 -0600, Dennis Gilmore den...@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. ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
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. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
On Fri, Jan 25, 2013 at 11:22 AM, Dennis Gilmore den...@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
Re: [fedora-arm] arm software floating point support going forward
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 jwbo...@gmail.com To: Dennis Gilmore den...@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 den...@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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
