| Summary: | Target platform needs to be armv7hl, not armv7l for F20 ARM | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Clive Messer <clive> |
| Component: | akmods | Assignee: | Richard <hobbes1069> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | clive.m.messer, kwizart |
| Priority: | P5 | ||
| Version: | 20 | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
| Attachments: |
Patch for akmods. armv7l -> armv7hnl
Patch for akmodsbuild. armv7l -> armv7hnl |
||
Created attachment 1250 [details]
Patch for akmodsbuild. armv7l -> armv7hnl
Sorry, I mean armv7l -> armv7hl, not armv7l -> armv7hnl! Patches are correct. Hi Clive, thx for your interest in RPM Fusion ARM Yep I think this is a similar problem than https://bugzilla.redhat.com/show_bug.cgi?id=1033786, where it's hard to to discover which kernel/userspace we are on. The problem is that we were right when using armv7l from f18 softfp secondary. And the current hardfp kernel rpm is wrong in reporting itself as armv7hl given that there is not floating point within the kernel. Also I expect the issue will rise with pidora kernel reported as armv6hl. (where uname -m would report armv6l there). Might need to ask for advices... That's fine. I just wanted to mention it in case you didn't know that there was an issue here. I probably should have introduced myself. I package (and maintain the repo) for the Community Squeeze project. www.communitysqueeze.org We will be releasing our F20 based image very shortly. Our repo depends on your repo. I needed to provide a USB DAC driver that is not in mainline 3.6.*. Thus my reason for using akmods. Anyway, it's not a problem, I have "kludged" the issue for our F20 arm builds with my if target=armv7l, then target=armv7hl and pushed an updated akmods package to our CS repo. I do understand that there is a bigger picture here, and it possibly does need a proper fix rather than a quick kludge, my logic being that if I report it to upstream, at least they are aware of it, if they weren't already. Thank you for your time. I am going through old bugs to see if they can be closed. Is there still something to be done here? Merged in devel (f21) But I wonder if it won't be better to have
if [[ "${target}" == "armv7l" ]]; then
target="$(rpm -E %{_target_cpu})"
fi
Not sure you want to do that! With Neon support, "rpm -E %{_target_cpu}" will return "armv7hnl". We always want it to be just "armv7hl".
(In reply to comment #7) > Not sure you want to do that! With Neon support, "rpm -E %{_target_cpu}" will > return "armv7hnl". We always want it to be just "armv7hl". This is not the case on f20 with a wandboard (that support neon) But As I said earlier, this will be wrong with previous armv7l (soft-float) kernel. Anyway target_cpu will not solve anything there as it will be armv5tel.( and this architecture is deprecated anyway). Still if someone hit that issue, patch will be welcomed. Other topic, I may start the arm rebuild of f21 at some point before RPM Fusion GA, so It will allow fixing ARM specifics bugs. Have your made any experiment there ? |
Created attachment 1249 [details] Patch for akmods. armv7l -> armv7hnl Hi, I've packaged a USB driver using akmods. One thing I noticed, 'uname -m' is returning armv7l on F20 ARM. Needs to be armv7hl, as that is what the kernel is built with on Fedora ARM platform, otherwise install of kmod fails. eg. 09 Jan 05:10:08 akmods: Building RPM using the command '/bin/akmodsbuild --targe t armv7l --kernels 3.12.6-300.fc20.armv7hl /usr/src/akmods/mytekusb2-kmod.latest ' 09 Jan 05:10:29 akmods: Installing newly built rpms package kmod-mytekusb2-3.12.6-300.fc20.armv7hl-1.0-0.1.20140103git9d54bc9.fc20.armv7l is intended for a different architecture I've attached patches for akmods and akmodsbuild.