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!
Here are updates I just got working of Lennert and David's patches
against current rawhide gcc and binutils:
which generate updated binutils and gcc cross packages. The old ones
are fine except that they're no longer able to build current kernels
They're tested to generate working cross compiler packages on x86_64
host; the compilers generate a working kernel.org kernel on iMX31 and
can link a test app with printf() OK, since I just need them for kernel
compile duties I didn't go any further with cross userspace.
You can use the patches like this:
1) Grab the source RPMs you want to build against
2) cd into your rpmbuild/SOURCES dir and use
rpm2cpio <source rpm> | cpio -id
to unpack, then mv *.spec ../SPECS
3) patch the binuntils.spec and gcc.spec files with the diffs; they
should apply cleanly at least with exactly the rawhide sources above
4) rpmbuild -ba --define "binutils_target armv5tel-redhat-linux-gnueabi"
5) rpm -i
6) rpmbuild -ba --define="cross_target armv5tel-redhat-linux-gnueabi"
7) as root: cd rpmbuild/RPMS/x86_64 ; rpm -Uvf
8) That's it!
So I've had a number of conversations with Dennis Gilmore and folks from
other ARM disro ports about v7 support, and particularly with respect to
hardware math. (In addition, one of the Seneca students is currently
investigating v5 vs. v7 support in an attempt to figure out how much of
the Fedora universe needs to be recompiled for optimal benefit).
Regarding hardfp, though, things are quite unclear. My understanding of
soft/softfp/hardfp was initially wrong. As I understand it now:
- soft does all the math in software. Function values are passed in CPU
registers where appropriate.
- softfp enables the use of FPU instructions, but continues to pass
function arguments in CPU registers. This mode enables hardware
acceleration of math and interoperability with soft, at the cost of a
CPU->FPU register move in some cases.
- hardfp enables the use of FPU instructions, and function values are
passed in FPU registers where appropriate. This mode is incompatible
with soft and softfp, and cannot be used on CPUs that have an FPU.
According to gcc (docs + error messages), it is also incompatible with
CPUs that use a "vfp" math unit, such as OMAP3xxx CPUs (BeagleBoard) and
(I think) the CPU used in the XO1.75. I'm unclear on which hardware math
units it is compatible with.
In terms of hardware support, I think we definitely want to continue to
support armv5tel with software floating-point, since that's what is used
on many current Marvell CPUs, including those used in the
hardfp would break compatibility with all of the existing binary
packages, and hardfp can't be compiled by gcc for any of the CPUs I have
got my hands on so far.
Thus, I recommend that we aim at armv7l softfp to support as an arch
I've added a (rudimentary, really ugly) status page to the arm koji web
site. The URL is:
This page provides access to the log files from the current
build-previous and/or koji-shadow runs, and Paul Whalen added a link to
the last koji-compare run.
I hope to spruce this page up with some graphs, run stats, and other
information in the weeks ahead.
I just received my SheevaPlug shipment yesterday, and today I've been
trying (and failing) to install Fedora 12 onto it. I'm trying to set up
the plug to boot off nand. Unfortunately the instructions on the wiki
are pretty sparse. I'd consider myself a Fedora expert, but I'm
definitely new to ARM and embedded systems (modulo some time I spent
with a TuxScreen system about a decade ago).
I've downloaded the f12 root filesystem and modified it as per the wiki.
I also downloaded the 18.104.22.168 kernels from
http://sheeva.with-linux.com/sheeva/22.214.171.124/ (as per the wiki), but I
have no idea if these are the "right" packages to use. I only chose
this because it's the version of the kernel my F12 laptop is running).
Then I downloaded the sheevaplug installer (again, as per the
fedora arm wiki), but of course it didn't work on my fedora-12 64
system; the problem was that runme.php needed "<?php" instead of just
"<?" in order to get php to run... and even when running in an su
environment, it still thought I wasn't root.
After trying to comprehend the sheevaplug-installer readme, googling to
figure out where to find the uboot-custom.txt, and then finally getting
the installer running, then I get the dreaded "No valid NAND flash
**** Burning uboot and environment variables ... This will take few minutes ...
Open On-Chip Debugger 0.4.0 (2010-02-22-22:59)
Licensed under GNU GPL v2
For bug reports, read
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
dcc downloads are enabled
Error: No valid NAND flash driver found (0)
Available NAND flash controller drivers:
**** openocd FAILED
**** Is the mini USB cable connected?
Luckily my sheeva is still running its original config. uboot is
working (albeit with the default version):
** MARVELL BOARD: SHEEVA PLUG LE
U-Boot 1.1.4 (Jul 14 2009 - 06:46:57) Marvell version: 3.4.16
So... can someone help me wipe out the debian installation and install
fedora-12? I think there are enough hits on the web to reflash my
uImage, but I can't for the life of me figure out how to flash the
rootfs.tar.gz into mtd2.
Any help would be greatly appreciated!
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord(a)MIT.EDU PGP key available
Hi,all, I have downloaded fedora 12 rootfs for arm.But I can't use it run on my board which is freescale im5 series.Did anybody can tell me how can I do?I really need you help,thanks!
what are the status about building glibc in fedora arm ?
Can we have fedora > 12 in ARM arch ?
Itamar Reis Peixoto
msn, google talk: itamar(a)ispbrasil.com.br
+55 11 4063 5033 (FIXO SP)
+55 34 9158 9329 (TIM)
+55 34 8806 3989 (OI)
+55 34 3221 8599 (FIXO MG)
I've just completed a first draft of directions to install the Fedora 12
rootfs on a BeagleBoard-xM.
I've used this process to load the Fedora 12 rootfs onto two BeagleBoard-xM
boards so far. If you find any mistakes or unclear sections, or know of a
better way to do things, feel free to edit the page and correct it. I'll be
refining the guide over the next few days as well.
I want to write .hex files to LPC2148 based board  with the help of
lpc21isp utility on Linux using serial-to-usb cable.
The crystal frequency is 12Mhz for this board and I chose 9600 ( and
38400 ) baud rate.
# ./lpc21isp -hex led.hex /dev/ttyUSB0 9600 12000
lpc21isp version 1.63
converted to binary format...
image size : 3556
Synchronizing (ESC to
no answer on '?'
I tried it several times but it doesn't seem to work.
Does anyone have prior experience with this problem?
Any pointers will be appreciated.