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!
It was brought to my attention that the F18 Alpha lacked a Kirkwood
image, which we had for F17. We have been creating images for F18 using
livemedia-creator (anaconda and lorax), where the F17 images were
manually created using a custom script.
The process we use is described on the wiki:
All the builders we have used for creating the F18 images are F17
armv7hl (hard-fp) systems. I personally have no experience with the
Kirkwood devices, so I don't know what is needed to set up the image or
configure the bootloader.
We would appreciate volunteers running F17 on Kirkwood devices to help
in creating an F18 image for those devices. The only development
involved would be customizing the kickstart file to 1) include any
special packages required for the device, and 2) set up any bootloader
specific files/scripts needed for the device. The remainder of the
effort would be to build and test the image. The hardware requirements
include an ARMv5 device running F17-GA or later with access to external
storage (requires space for the packages being installed and the
resulting image) and swap (requires >1GB total memory).
We have created v7hl images using a Trim Slice (1GB memory plus 500MB
swap) with external (USB) hard drive, so something similar would
I am willing to provide assistance and answer questions about using the
tools and modifying the kickstart config file, but I have no ARMv5
hardware on which to build or test these images.
I'm running the latest F18 nightly snapshot that I can find (17 Sept)
fully updated via yum, on a Dreamplug.
When the system boots, it reports the following:
> Oct 21 16:53:12 asenath dbus-daemon: dbus: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
> Oct 21 16:53:12 asenath dbus: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
> Oct 21 16:53:12 asenath systemd: Starting Authorization Manager...
> Oct 21 16:53:12 asenath systemd: polkit.service: main process exited, code=killed, status=4
> Oct 21 16:53:12 asenath systemd: Failed to start Authorization Manager.
> Oct 21 16:53:12 asenath systemd: Unit polkit.service entered failed state.
> Oct 21 16:53:37 asenath dbus-daemon: dbus: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
> Oct 21 16:53:37 asenath dbus: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
When I manually run /usr/lib/polkit-1/polkitd it immediately reports
Running polkitd under gdb, it reports:
> Program received signal SIGILL, Illegal instruction.
> 0xb699c450 in _GLOBAL__sub_I_jsarray.cpp () from /lib/libmozjs185.so.1.0
Looking at the build log of js on Koji for armv5tel, all the c++ and gcc
command lines have the option -march=armv7-a after the option
-march=armv5te, so presumably the js package for armv5tel is actually
being built for armv7.
The problem appears to be in the configure.in script where for any arm
architecture, it sets MOZ_ARM_ARCH to armv7-a:
> dnl Setup default CPU arch for arm target
> AC_MSG_WARN([target cpu is ($target_cpu)])
> case "$target_cpu" in
Attached is a patch that sets MOZ_ARM_ARCH to armv5te if $target_cpu is
I have build the modified js package and Authorisation Manager now
Should I report this anywhere else, or is this email sufficient for this
problem to be resolved.
Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday Oct 31st) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
Current items on the agenda:
1) Fedora 18 ARM Alpha release
2) F18/19 build status - problem packages?
3) Koji Hub - speed issues, moving to Phoenix prior to PA push?
4) Kirkwood images - is anyone interested in assisting with their creation/testing?
4) Your topic here
If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting.