Hi Folks, Apologies in advance if this is a FAQ. But I can't seem to find concrete answers to what seem like relatively common questions.
The problem we have is the need to build current Fedora SRPMs for armel and possibly armhf. We have an embedded product using an ARM926EJ-S core and another using a Cortex-A9. Constraints dictate the RPMs to be built under in-house control and we're trying to understand the path of least resistance and greatest reusability as Fedora ARM moves forward.
- So the first fundamental question is to what degree current Fedora SRPM content supports cross platform builds on an x86_64 host? This would be our first preference though it isn't clear to what extent the core project infrastructure supports this, if at all.
- Beyond cross builds infrastructure support is the question of what degree SRPMs themselves support cross platform builds. This being an embedded platform, runtime needs are minimal (no graphics, no heavy scripting languages, applications, etc.. So we're not faced with building a conventional workstation class RPM userland content.
- My impression however is while some off-shoot efforts of Fedora ARM do build cross platform, the main project release builds native on an ARM host. Moreover on bare metal ARM vs. an ARM VM for efficiency. Is this correct? If so what are our options for a build host Fedora ARM distribution at the present? Eg is a 32-bit ARM distro install required or will a 64-bit ARM install (eg: v8) be able to build SRPMs for armel and armhf? The latter seems to be approaching a cross platform build, depending upon what is available in a 64-bit Fedora ARM install now, and in the near future.
That's probably enough for now, answers to the above should help us quickly narrow down the problem space we're grappling with.
Many thanks,
-john
On Sat, Jul 15, 2017 at 2:51 PM, fedora_arm fedora_arm@third-harmonic.com wrote:
Hi Folks, Apologies in advance if this is a FAQ. But I can't seem to find concrete answers to what seem like relatively common questions.
The problem we have is the need to build current Fedora SRPMs for armel and possibly armhf. We have an embedded product using an ARM926EJ-S core and another using a Cortex-A9. Constraints dictate the RPMs to be built under in-house control and we're trying to understand the path of least resistance and greatest reusability as Fedora ARM moves forward.
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
- So the first fundamental question is to what degree current Fedora SRPM content supports cross platform builds on an x86_64 host? This would be our first preference though it isn't clear to what extent the core project infrastructure supports this, if at all.
No, we don't support cross compiling anything except the kernel. There's lots of complexity in dealing with cross compiling and there's code that's run during the builds that needs to run on the actual architecture that's not actually compiling.
- Beyond cross builds infrastructure support is the question of what degree SRPMs themselves support cross platform builds. This being an embedded platform, runtime needs are minimal (no graphics, no heavy scripting languages, applications, etc.. So we're not faced with building a conventional workstation class RPM userland content.
I don't understand what you mean by that statement/question.
- My impression however is while some off-shoot efforts of Fedora ARM do build cross platform, the main project release builds native on an ARM host. Moreover on bare metal ARM vs. an ARM VM for efficiency. Is this correct? If so what are our options for a build host Fedora ARM distribution at the present? Eg is a 32-bit ARM distro
The Fedora infrastructure runs 32 bit VMs as builders running on 64 bit hardware.
install required or will a 64-bit ARM install (eg: v8) be able to build SRPMs for armel and armhf? The latter seems to be approaching a cross platform build, depending upon what is available in a 64-bit Fedora ARM install now, and in the near future.
aarch64 is quite a bit different to ARMv7 in terms of instructions so we don't support a multilib style env like x86_64/i686 does.
On 07/15/2017 06:17 PM, Peter Robinson wrote:
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
Not what I was hoping. But lack of an armel build isn't a long term issue. Do any contemporary Fedora ARM derivatives exist which may still maintain armel build infrastructure?
No, we don't support cross compiling anything except the kernel. There's lots of complexity in dealing with cross compiling and there's code that's run during the builds that needs to run on the actual architecture that's not actually compiling.
My information admittedly is dated. When i was involved a number of years ago, effort was being expended to support Fedora SRPM cross build by Marvell and others IIRC. Appears moot now.
- Beyond cross builds infrastructure support is the question of what degree SRPMs themselves support cross platform builds. This being an embedded platform, runtime needs are minimal (no graphics, no heavy scripting languages, applications, etc.. So we're not faced with building a conventional workstation class RPM userland content.
I don't understand what you mean by that statement/question.
I was assuming cross build of SRPMs may still be supported but probably wasn't as complete as the case of a native build. That wouldn't likely have been an issue for this embedded use case and the core userland runtime is most of what is required. Again moot.
The Fedora infrastructure runs 32 bit VMs as builders running on 64 bit hardware.
64-bit ARM or x86_64 host hardware? If ARM is that leveraging kvm to accelerate the 32-bit VM?
aarch64 is quite a bit different to ARMv7 in terms of instructions so we don't support a multilib style env like x86_64/i686 does.
So the model is a strict self-hosted native build where the host's distro and toolchain is exactly that of the target, correct?
Thanks,
-john
On Sat, Jul 15, 2017 at 9:26 PM, fedora_arm fedora_arm@third-harmonic.com wrote:
On 07/15/2017 06:17 PM, Peter Robinson wrote:
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
Not what I was hoping. But lack of an armel build isn't a long term issue. Do any contemporary Fedora ARM derivatives exist which may still maintain armel build infrastructure?
Yes. Pignus does: https://pignus.computer/
The current released image is Fedora 23 based, I believe. But their Koji instance has been tracking current Fedora releases for some time: http://koji.pignus.computer/koji/
On Sun, Jul 16, 2017 at 3:15 AM, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jul 15, 2017 at 9:26 PM, fedora_arm fedora_arm@third-harmonic.com wrote:
On 07/15/2017 06:17 PM, Peter Robinson wrote:
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
Not what I was hoping. But lack of an armel build isn't a long term issue. Do any contemporary Fedora ARM derivatives exist which may still maintain armel build infrastructure?
Yes. Pignus does: https://pignus.computer/
The current released image is Fedora 23 based, I believe. But their Koji instance has been tracking current Fedora releases for some time: http://koji.pignus.computer/koji/
Pignus is ARMv6 HFP, it's not armel and hence won't support ARM926EJ-S.
On Sun, Jul 16, 2017 at 2:26 AM, fedora_arm fedora_arm@third-harmonic.com wrote:
On 07/15/2017 06:17 PM, Peter Robinson wrote:
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
Not what I was hoping. But lack of an armel build isn't a long term issue. Do any contemporary Fedora ARM derivatives exist which may still maintain armel build infrastructure?
None I'm aware of, there's been a number of attempts for ARMv6 to support original RPi/Pi Zero but even they're mostly dead.
No, we don't support cross compiling anything except the kernel. There's lots of complexity in dealing with cross compiling and there's code that's run during the builds that needs to run on the actual architecture that's not actually compiling.
My information admittedly is dated. When i was involved a number of years ago, effort was being expended to support Fedora SRPM cross build by Marvell and others IIRC. Appears moot now.
I've been involved in Fedora ARM for over 7 years, lead the build effort since F-14 and we've never cross compiled except pre rpm phase when boot strapping very core central bits of booting Linux for a new arch IE armhfp or aarch64.
- Beyond cross builds infrastructure support is the question of what degree SRPMs themselves support cross platform builds. This being an embedded platform, runtime needs are minimal (no graphics, no heavy scripting languages, applications, etc.. So we're not faced with building a conventional workstation class RPM userland content.
I don't understand what you mean by that statement/question.
I was assuming cross build of SRPMs may still be supported but probably wasn't as complete as the case of a native build. That wouldn't likely have been an issue for this embedded use case and the core userland runtime is most of what is required. Again moot.
Well a SRPM is essentially noarch or agnostic so it doesn't matter what arch you create it on it's consumable across all arches hence I still don't understand what the question is.
The Fedora infrastructure runs 32 bit VMs as builders running on 64 bit hardware.
64-bit ARM or x86_64 host hardware? If ARM is that leveraging kvm to accelerate the 32-bit VM?
aarch64 as accelerated VMs using kvm. Not all aarch64 hardware supports that.
aarch64 is quite a bit different to ARMv7 in terms of instructions so we don't support a multilib style env like x86_64/i686 does.
So the model is a strict self-hosted native build where the host's distro and toolchain is exactly that of the target, correct?
Correct.
On 07/16/2017 02:42 AM, Peter Robinson wrote:
On Sun, Jul 16, 2017 at 2:26 AM, fedora_arm fedora_arm@third-harmonic.com wrote:
On 07/15/2017 06:17 PM, Peter Robinson wrote:
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
Not what I was hoping. But lack of an armel build isn't a long term issue. Do any contemporary Fedora ARM derivatives exist which may still maintain armel build infrastructure?
None I'm aware of, there's been a number of attempts for ARMv6 to support original RPi/Pi Zero but even they're mostly dead.
Well this isn't exactly surprising for a server/workstation class distribution to drop active support & soak for what has become an obsolete/obsoleting embedded architecture.
The sole reason in pursuing the possibility is Fedora distro SRPM content being a strong preference as a distro intake choice for this customer. The armel product is essentially in maintenance mode and worst case would be to create a one-off build solution. The practicality of that approach is what I'm trying to understand.
I've been involved in Fedora ARM for over 7 years, lead the build effort since F-14 and we've never cross compiled except pre rpm phase when boot strapping very core central bits of booting Linux for a new arch IE armhfp or aarch64.
This was around 2008 and a conversation I was trying to instigate with Marvell during my tour of duty at RH. Admittedly no more than a cave painting artifact at this point.
Well a SRPM is essentially noarch or agnostic so it doesn't matter what arch you create it on it's consumable across all arches hence I still don't understand what the question is.
Sorry I wasn't clear. It wasn't a question but a general statement of requirements, to give some context of the effort. Back in the 2008 timeframe the concern was comprehensive cross build support for all SRPM content, which given the embedded platform under discussion isn't required.
The Fedora infrastructure runs 32 bit VMs as builders running on 64 bit hardware.
64-bit ARM or x86_64 host hardware? If ARM is that leveraging kvm to accelerate the 32-bit VM?
aarch64 as accelerated VMs using kvm. Not all aarch64 hardware supports that.
Does this relate only to VHE support? Or are other CPU attributes required to support a 32-bit accelerated guest beyond aarch32 support on a aarch64 host? Understood this is an ARM or kvm/ARM question but as long as I'm bending this collective ear..
Bottom line is setting aside the significant need to bootstrap a Fedora armel distro in the first place, would a practical build vehicle even exist in terms of a kvm accelerated ARMv5 guest on aarch64.
Agreed, I don't like the sound of where this is headed either. But if there is a non-negotiable roadblock in the path, it is best identified in advance.
And thanks, this information is quite useful.
-john
On Sun, Jul 16, 2017 at 12:40 PM, fedora_arm fedora_arm@third-harmonic.com wrote:
On 07/16/2017 02:42 AM, Peter Robinson wrote:
On Sun, Jul 16, 2017 at 2:26 AM, fedora_arm fedora_arm@third-harmonic.com wrote:
On 07/15/2017 06:17 PM, Peter Robinson wrote:
Fedora hasn't supported anything less than ARMv7 (armhfp) since Fedora 18.
Not what I was hoping. But lack of an armel build isn't a long term issue. Do any contemporary Fedora ARM derivatives exist which may still maintain armel build infrastructure?
None I'm aware of, there's been a number of attempts for ARMv6 to support original RPi/Pi Zero but even they're mostly dead.
Well this isn't exactly surprising for a server/workstation class distribution to drop active support & soak for what has become an obsolete/obsoleting embedded architecture.
The sole reason in pursuing the possibility is Fedora distro SRPM content being a strong preference as a distro intake choice for this customer. The armel product is essentially in maintenance mode and worst case would be to create a one-off build solution. The practicality of that approach is what I'm trying to understand.
The only armel/armsfp RPM-based distribution I know of is Mageia (since Pignus is apparently not one). Their Mageia 6 release has an armv5tl flavor in addition to the standard armv7hl flavor.
I think that armsfp is basically dead in most distributions, in part due to the abundance of armhfp hardware replacing the old armsfp stuff.