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!
Fedora 13 ARM users can now update to use a new repository composed on March 23rd. This new compose adds additional software and includes software groups.
The Beta2 has been signed with a new key. If you are currently running the Beta1 you will need to install the new key which can be done by entering:
rpm -Uvh http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-03-23/f13-arm/ar...
And replace the fedora.repo file:
mv /etc/yum.repos.d/fedora.repo.rpmnew /etc/yum.repos.d/fedora.repo
The Fedora 13 ARM Beta2 compose can be found at :
A new root filesystem is available here. The password for the root account remains “fedoraarm”.
We are asking users of Fedora ARM for some feedback. Is there something missing? Is the software included so far working as expected? Any other suggestions? Please forward feedback to the mailing list
On 29 March 2011 07:15, Jon Masters <jcm(a)redhat.com> wrote:
> On Sat, 2011-03-26 at 21:10 +0000, Matthew Wilson wrote:
>> It's probably worth gathering some data on h/w and experiences as the
>> beta progresses. Any objections to my creating a wiki page to track
>> and summarise this?
> That sounds like a great idea! I'm running Fedora ARM on a bunch of
> BeagleBoards, and some PandaBoards at the moment. I have a DreamPlug on
> the way, and a SheevaPlug that may get re-used, but hopefully not before
> I've convinced myself that ARMv7 is a good base ;)
> My most fun bit of ARM hardware right now is (still) by collection of
> empeg car stereos, which alas won't likely run Fedora any time soon, but
> provide hours of entertainment nonetheless.
I've created a page on the wiki:
It's rather bare now -- please feel free to add some brief details of
the ARM device(s) you use.
I'm looking into building the java stack for ARM. Unfortunately
something is broken when building from SCM.
A command like this seems to start building:
$ arm-koji build --scratch dist-f13
Unfortunately the src.rpm can not be created :-( It bails out with
something like this:
DEBUG util.py:280: Executing command: ['fedpkg', 'sources']
DEBUG util.py:256: % Total % Received % Xferd Average Speed
Time Time Time Current
DEBUG util.py:256: Dload Upload
Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
DEBUG util.py:256: curl: (22) The requested URL returned error: 404
DEBUG util.py:256: Could not download sources: Could not download
Command '['curl', '-H', 'Pragma:', '-O', '-R', '-S', '--fail',
returned non-zero exit status 22
DEBUG util.py:319: Child returncode was: 1
(that comes from the root.log at
ran on cdot-panda-7-2)
It seems that 'fedpkg sources' does not pull the sources from the
right URL (http://cvs.fedoraproject.org/repo/ and further does not
exist anymore). When I execute 'fedpkg sources' on my local
f14.x84_64, everything works fine and I can upload the srpm for a
scratch-build. I guess fedpkg needs an update, either in the mock
repository, or on some builders, or ....
On Tue, Mar 22, 2011 at 9:59 AM, haberldx002 <haberldx002(a)gmail.com> wrote:
> Today I try to install Fedora 12 ARM on my Beagleboard xM, I follow the
> guide in
> https://fedoraproject.org/wiki/Architectures/ARM/BeagleBoardxMSDCard step
> by step. Everythings looks OK.
> But when I boot the board, it still boot into the orginal angstrom, the
> boot.scr likes not working. Could you please help me to let it work? Thanks.
> Best Regards,
I'm forwarding this message to the fedora ARM mailing list, as it's better
to ask there than to contact me directly.
Are you using a recent version of u-boot.bin? Have you manually changed any
of the u-boot environment variables at any point?
I didn't write the section of the tutorial concerning the boot.scr file.
I'm not too familiar with how u-boot works, but I can say that the process
worked for me on the two fresh out-of-the-box beagleboard xms i've tried it
I came across an X.org driver for OMAP  and as packaged  this
driver to prepare for my own testing. Building works fine, but I have
no possibility to test this driver at the moment as I do not have a
monitor to connect to my BeagleBoard.
If there is interest from others, I'll put this package up for review
and inclusion in a future release. Any feedback or test-results much
Please could someone point me to / summarise the process for secondary
arch-specific bugs? I'll raise issues on bugzilla if appropriate, but
I wanted to check if there's something specific for Fedora ARM when
the issue doesn't occur on i386 / x86_64.
(The specific issue is with Firefox: Ubuntu have seen this one too
, but the fix of playing with -O2 / -O doesn't have any effect on
F13 -- unsurprisingly.)
Thanks for you great work, Fedora arm rootfs alpha worked well on
toshiba ac100, then I was able to change repo and receive updates from
latest beta 2. One issue I've seen is the following:
[Errno 14] PYCURL ERROR 6 - ""
Trying other mirror.
Error Downloading Packages:
fake-kernel-provides-1.0.0-0.fc12.armv5tel: failed to retrieve
fake-kernel-provides-1.0.0-0.fc12.armv5tel.rpm from fedora-arm-koji
error was [Errno 14] PYCURL ERROR 6 - ""
URL is indeed quite strange... What's the problem with it?
In case this is relevant to anyone - dietlibc versions prior to
dietlibc-0.33-0.1600.20110311.fc16 are broken on ARM.
dietlibc-0.33-0.1600.20110311.fc16 is the first version that builds
cleanly and works in my use-case (util-vserver).
What is the procedure for getting this into the F13 ARM yum repository
(since the F13 version won't work)? Is there a procedure by which
rawhide packages get backported to older Fedora versions in cases like this?