Bug 666284

Summary:	ARM Hardware Options List
Product:	[Community] Bugzilla	Reporter:	Gordan Bobic <gordan>
Component:	Bugzilla General	Assignee:	Simon Green <sgreen>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	tools-bugs <tools-bugs>
Severity:	medium	Docs Contact:
Priority:	low
Version:	devel	CC:	dmarlin, ebaak, jfearn, lsmid, rpacheco, syeghiay, tcallawa
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	arm9
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-24 21:15:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gordan Bobic 2010-12-30 00:46:08 UTC

Description of problem:
Currently there are 4 ARM options listed. All of them are technically wrong. The only supported ARM architecture (and it's only Fedora that has any ARM support at the moment) at the moment is armv5tel, with armv7l being planned in the future. Thus, the following:

arm7
arm9
strongarm
xscale

should be replaced with armv5tel. armv7l option should be added as and when it actually happens.

Comment 1 D. Marlin 2011-11-29 21:47:47 UTC

While the current four ARM options are not technically incorrect (they were used at one time), they are probably obsolete, and definitely not applicable to current ARM platforms.

The is now a more generic "arm" platform option to use for the more 'modern' ARM platforms such as armv5tel, armv7l, armv7hl, etc.  This option was only recently added (late September 2011), but I think it addresses this bug.

Comment 2 Gordan Bobic 2011-11-29 22:12:23 UTC

Since there are at least two ARM levels being targeted by Fedora (armv5tel and armv7hl), at least these two should be distinct options to allow easy differentiation between them (they are not ABI compatible).

Further, armv6l and armv7l might also be useful to have because a few key packages (e.g. glibc, openssl) could be compiled for this target while the rest of the distribution can still be armv5tel (soft-float).

Thus, I would argue a single generic "arm" platform option is not an adequate solution.

Comment 3 Jeff Fearn 🐞 2012-05-30 04:43:40 UTC

As part of the recent Bugzilla 4.2 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time.

If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically.

Thanks, the Bugzilla team.

Comment 4 Jeff Fearn 🐞 2012-05-30 04:44:21 UTC

As part of the recent Bugzilla 2.4 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time.

If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically.

Thanks, the Bugzilla team.

Comment 5 Jeff Fearn 🐞 2012-07-19 05:25:00 UTC

As noted previously, the Bugzilla Team is cleaning up a large number of outstanding issues that have bit rotted. This bug is being closed as there has been no response to that notification.

If you believe this bug is still important please reopen this bug in the NEW status and PM will consider it.

Comment 6 Gordan Bobic 2012-07-19 07:45:59 UTC

This arguably still needs fixing, especially with ARM becoming a primary architecture with two particular ARM ABIs targetted (armv5tel and armv7hf).

Comment 8 Tom "spot" Callaway 2012-10-09 18:24:40 UTC

Here's my take:

arm (applies to anything in the arm universe)
armv5tel (armv5 soft-float)
armv7hf (armv7 hard-float)

I suspect we will end up with an armv6 hard float because of the popularity of Raspberry Pi, but we can wait until that happens to add the target.

Comment 9 Simon Green 2012-10-11 02:35:26 UTC

(In reply to comment #8)
> Here's my take:
> 
> arm (applies to anything in the arm universe)
> armv5tel (armv5 soft-float)
> armv7hf (armv7 hard-float)
> 
> I suspect we will end up with an armv6 hard float because of the popularity
> of Raspberry Pi, but we can wait until that happens to add the target.

Therefore, in your opinion, should we add armv5tel and armv7hf to the list of platforms?

Comment 10 D. Marlin 2012-10-11 16:35:30 UTC

Just for clarification:

  armv5tel (armv5 soft-float)
  armv7l   (armv7 soft-float)
  armv7hl  (armv7 hard-float)

as mentioned before, there is also a possibility of:

  armv6hl  (armv6 hard-float)

For rpm (and yum) there are two ABIs used:

  arm      (ARM soft-float)
  armhfp   (ARM hard float)

so maybe we only need to add 'armhfp' for all ARM hard-float, and keep 'arm' for all ARM soft-float?

Comment 11 Gordan Bobic 2012-10-13 08:59:50 UTC

Considering what is ever likely to form official distributions, I think the following need to be added:

armv5tel
armv7hl

and everything else ARM related removed, in the interest of clarity.

Also as far as rpm/yum goes, I thought they also followed the armv5tel/armv7hl, at least according to the configuration files in /usr/lib/rpm/.

Comment 12 D. Marlin 2012-10-13 17:20:46 UTC

Perhaps I worded this poorly.  What I should have said is that there are only two "base archs" for ARM, one for all soft-float, and one for all hard-float:

  arm      (ARM soft-float)
  armhfp   (ARM hard float)

Please check the yum repositories to see what I mean, i.e.,

  http://dl.fedoraproject.org/pub/fedora-secondary/releases/17/Everything/

So I think it would be more appropriate to use the two "base archs" rather than include every possible architecture variant, (i.e., from /usr/lib/rpm/macros):

  %arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7hnl

and possibly 'armv6hl' (if used by the Raspberry Pi).