I would like to introduce myself to the group. I have recently
received an IGEPv2 board , which is based on the Beagle Board, but
with wifi, bluetooth, ethernet, and more RAM. I'm still at the "wow,
it's tiny and it runs Linux" stage. I should get a bit more time over
the next month and Christmas to play around properly with it.
I'm new to embedded development, but neither new to Linux nor ARM
(writing my first ARM assembly some 15 years ago). However, for the
past 6 years I've not even built a Linux kernel, preferring to use the
default kernel in Fedora for simplicity :)
Firstly, a thank you to those involved in Fedora ARM for getting it to
this stage. If I get the time, I'd really like to contribute some
(probably small) effort to help get Fedora ARM working well on the
IGEPv2 and Beagle Board. As I progress, I'd like to know what I can
do to help.
In the meantime, I have some questions. Apologies in advance if these
1) There are various different kernels from different sources. I'm
used to there being a small set of "right" kernels (that is, Fedora's
idea of "right") for x86. I fully appreciate that different ARM-based
boards are quite different in capabilities (like different instruction
a) Is there likely to be some standardised vanilla Fedora ARM kernel
source? (Or is that simply the source RPM available for Fedora?)
Then patches /could/ be offered for the more common systems (e.g.
Beagle Board & clones, SheevaPlug).
b) Would it then make sense to offer these as pre-built RPMs for common systems?
c) Is there any guidance on which version is good to use as a base?
I've seen quite different kernel versions being used (from 2.6.27 to
2) I understand a little bit about the different calling conventions,
FP differences (e.g. soft FPU versus VFP), and instruction set
differences (v5 versus v7).
a) Can the kernel can be safely built with a different instruction set
targeted? (I know there are different optimisation options passed to
GCC. Apologies if this seems a bit newbie-ish.)
b) For FP-heavy programs (e.g. ogg encoding), is it possible to build
the packages with VFP/NEON but still get them to work in a soft FPU
system? I'd imagine any call to an external library would have to
somehow be defined to use a different calling standard.
3) There seem to be some missing dependencies in the packages in the
current Fedora ARM repository. For example, emacs is requiring
libotf, which doesn't seem to be there in the repository. And
likewise with the xorg-x11-font* packages needing ttmkdir. I'm
confused as to how the RPM could have been successfully built without
it. What am I missing?
4) I see there has been some discussion over unaligned data access.
(Oh, I remember that from the ARM2 days.) It seems as if the
Cortex-A8 cores allow unaligned data access when set up to do so .
Does this, in any way, help with the compatibility of packages
5) I've managed to get various source packages missing from the Fedora
ARM repositories to compile successfully (natively). I guess there is
a reason why there are not in the repos right now -- is that reason
down to time and priorities, or is there some blocking bugs with many
of these packages?
I look forward to being able to contribute something back into Fedora!
I've seen the log from  and I'm disappointed, to say the least. We
made an agreement about this several weeks ago  in a conference
call. Various of the people on the call claimed to be Red Hat / Fedora
ARM and toolchain folks who were both interested in working out a
reasonable answer to the linker path debate and empowered to implement
whatever was agreed. We had a productive discussion and quickly came
to an amicable agreement.
Since then, distros have done the work necessary to use the linker
path that was agreed, making changes in gcc and glibc packages. Some
people went with the initial patches that were proposed for the sake
of urgency, e.g. Ubuntu built using these initial patches for their
12.04 release. Given the all-party agreement on the meat of the
problem (the linker path itself), the finer details of the final
patches didn't matter so much. Others (Fedora) wanted to wait for the
patches to be accepted upstream before accepting them. That's also
understandable and reasonable. However, those patches have been
upstream for several weeks now and it seems nobody has cared enough to
pull them into Fedora yet.
To dispel a few misundestandings in the log:
* Ubuntu have *already* shipped the linker path changes in 12.04,
their latest LTS release
* Debian and openSUSE are well on the way to releasing with these
* The change is *not* just a symlink. There are *3* changes needed:
+ move/link the linker so that binaries built against the (agreed)
standard linker path will work (so that binaries will work on
+ change gcc's configuration to use the new (agreed) standard path
by default, so that binaries built *on* your system will work
+ tweak glibc so that it will accept both the old and new soname
for the dynamic linker, so that both old and new programs will
work (saving the need for a complete rebuild of the distro before
*Every* major distro working on ARM has implemented what was agreed by
all of us in the conf call. Except Fedora. At this point, the message
*seems* to be that Fedora developers just do not care about working
with the rest of the community, and that's a real shame. Please, let's
work together to get this fixed.
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
I know it was discussed a while ago how the USB storage on PandaBoards
was slow, not sure what the resolution was but saw this article on LWN
that looks like our problem there for those that might not have seen
the post elsewhere and are interested.
I downloaded the Fedora-17-arm-console.tar.xz rootfs and put it on my
sheevaplug. Everything was fine except named wouldn't start, was
getting a timeout error from systemd.
Jun 30 11:52:54 tau systemd: PID file /run/named/named.pid not readable (yet?) after start.
Jun 30 11:53:19 tau systemd: named.service operation timed out. Terminating.
Jun 30 11:53:19 tau systemd: Unit named.service entered failed state.
Turns out that the problem was due to /var/run being a directory and
not a symlink to /run (as in F16) i.e
from the rootfs tar
drwxr-xr-x root/root 0 2012-06-18 02:32 var/run/
drwxr-xr-x root/root 0 2012-04-30 15:12 var/run/NetworkManager/
-rw-rw-r-- root/utmp 0 2012-06-17 21:56 var/run/utmp
drwxr-xr-x root/root 0 2012-05-02 10:38 var/run/wpa_supplicant/
drwxr-xr-x root/root 0 2012-02-09 01:25 var/run/sepermit/
drwxr-xr-x root/root 0 2012-02-09 01:25 var/run/faillock/
drwxr-xr-x root/root 0 2012-02-09 01:24 var/run/console/
drwxr-xr-x root/root 0 2012-02-02 17:03 var/run/ppp/
drwxr-xr-x root/root 0 2012-05-02 09:02 var/run/setrans/
drwxrwxr-x root/root 0 2012-03-23 19:31 var/run/netreport/
And named was putting its pid file under /var/run/named/named.pid and
systemd was looking for it in /run/named/named.pid
Once I moved all the /var/run stuff to /run and made /var/run a symlink
ro /run, i.e
lrwxrwxrwx. 1 root root 6 Nov 20 2011 /var/run -> ../run
named now starts fine under systemd.
Also, (a minor thing) /run is a tmpfs mount, i.e
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
so having the following in the rootfs
drwxr-xr-x root/root 0 2012-02-29 23:18 run/blkid/
drwxr-xr-x root/root 0 2012-02-29 23:19 run/mount/
-rw-r--r-- root/root 0 2012-02-29 23:19 run/mount/utab
drwxr-xr-x root/root 0 2012-02-11 05:46 run/lock/
drwxr-xr-x root/root 0 2012-02-02 17:03 run/lock/ppp/
isn't much use.