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'm contacting people on all of the ARM linux distribution lists to
find out if anyone is interested in bringing about the creation of a
decent, useful and useable ARM-based Laptop. i've been researching
CPUs and how to go about this with a minimum of risk and cost,
learning from the experiences of the openpandora for example. all of
the enquiries that i've made, for about a year, all point towards a
minimum spec of at least a 1ghz CPU, 1gb of RAM and a 12in screen
(below those specs is too little, and above them is too costly). does
such a machine exist? in one word: no. there are plenty of machines
with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the
AlwaysInnovating Touchbook) - i wish them every success in their niche
markets that are catered for by 1024x600 screens.
for everyone else, who wants to see full documents and full web pages
*without* having to press page-up, page-down, there literally is not a
single ARM-based (or MIPS-based) product in existence, commercially
available, anywhere in the world, despite a lot of talk from ARM, and
also from the major ARM licensees, and despite the production cost of
ARM-based and MIPS-based laptops being lower than that of an
equivalent intel-based system.
so the question i have, for the people on this list is: given that
nobody else is taking any initiative, would _you_ like to be part of a
project that takes the initiative to create a low-cost, high-end
ARM-based laptop? like the OpenPandora, except... done with far less
risk and a lot less cost. one absolute key part in reducing risk and
cost is to utilise existing casework from a no-brand OEM laptop. all
that's then required is to create the motherboard to fit. more info
a rough guide i've received from a chinese embedded systems designer
is that a design using a Samsung S5PV210 will be about $USD 10,000,
and a design using a TI DM3730 or DM3725 will be about $20,000 (TI's
CPUs are a bit more complex, and the DM37xx series is newer than
Samsung's S5 range)... but that's *it*. that's all it costs, to
create the motherboard for fitting into an existing 12in laptop
chassis. excluding a DVD or Hard Drive, the BOM (Bill of Materials)
will come to somewhere around $150, which translates loosely into $240
to $300 after tax, customs, shipping etc. etc.
i'm still investigating ways to get that price down even further, and
i'm really really interested to hear from people who may know of other
CPUs. i've just heard today about the ZMS-08 for example, and
creativelabs have a SoM (system-on-module) which sounds like a perfect
fit: the only bug-bear being the proprietary libraries and
creativelab's fear over being swamped by developer wannabes asking for
help on how to program one of the most complex Cell Processor Units in
existence outside of IBM's and other obscure labs. the proprietary
libraries aren't so much the problem as the lack of documentation on
the Cell Processor.
so - please do discuss amongst yourselves, or feel free to contact me
directly. i'm maintaining a list of links to all the other forums
this is going out on, at the bottom of http://lkcl.net/laptop.html -
if you would like to recommend an alternative CPU please do review
and/or edit http://libreplanet.org/wiki/Group:Hardware/Processors
first (either the page itself or the discussion page).
I'm looking into getting an ARM system as small home-server. Of course
I'd like to run Fedora on it, but unfortunately it seems that current
Fedora releases are not completely ready for this yet.
I'd like to help with this, and as a start I am trying to get a fully
functioning VM up and running. Obviously there are issues to overcome
with this too. Many thanks for documenting the issues in the wiki!
Before I decide to buy myself a Pandaboard or similar, I'd like to get
some more experience with Fedora on ARM. My first personal project
will be getting libvirt work with ARM out of the box. I hope that this
attracts some more interested parties and lowers the barrier for
While I am checking the details of qemu and libvirt, I am wondering if
there is a kernel available that has virtio support. If not, I will
need to compile my own kernel, which feels a little silly.
https://arm.koji.fedoraproject.org does only seem to have one kernel
package available, and that is kernel-headers which I hardly can use
for booting. I am wondering if there are any scratch-builds available
that have a functioning vmlinz.
Furthermore I'd like to know what the best way is to follow the status
of the current ARM builds, and where to find out where help is most
We now have an ARM trac instance on FedoraHosted at
This is intended to provide:
- ticket tracking for ARM related issues
- a git repo for scripts and configurations related to ARM
That sounds like a good option - that page gives me a 404 though. Has
it moved somewhere else? All the google links point there as well.
On Sun, Jan 23, 2011 at 10:20 AM, Derek Atkins <derek(a)ihtfp.com> wrote:
> On Sun, January 23, 2011 12:00 am, Matt Hirsch wrote:
>> I've been using the Fedora 12 arm port on a sheevaplug for a few
>> months now, and its worked out great! Thanks for making the port
>> I'd like to use the plug as a print server with a USB printer, and I
>> noticed that the usblp driver seems to be missing. Was this driver
>> not included because of problems on arm, or should I be fine
>> recompiling? I'm a little hesitant to blindly go build the entire arm
>> toolchain, since I know it can be a little tricky to get working. Are
>> there plans to include this driver in future kernels?
> I installed the kernel from http://sheeva.with-linux.com/sheeva/ but also
> included the kernel modules in my root device and usblp works great for me
> on my Sheeva!
>> arm mailing list
To those who follows the developments (and, in particular, the recent CES 2011), the trend towards personal MIDs and tablet PCs is not just promising but logical. Quite a few major vendors, such as Dell (with Streak and so-called 'M02M'), RIM, Samsung, Motorola and Sharp (with Galapagos) revealed their plans to deliver ARM-based touch screen computing devices to consumers worldwide. Along with ready-to-use solution providers, Qualcomm showed-off its dual-core Snapdragon CPU, there has been news on Tegra of NVIDIA. According to analytics, the year of 2011 is to be the rise of MIDs and that of biting a nice piece of desktop and laptop niche.
I have a question. What does it mean for Fedora?
Misha Shnurapet, Fedora Project Contributor
shnurapet AT fedoraproject.org, GPG: 00217306
I've been using the Fedora 12 arm port on a sheevaplug for a few
months now, and its worked out great! Thanks for making the port
I'd like to use the plug as a print server with a USB printer, and I
noticed that the usblp driver seems to be missing. Was this driver
not included because of problems on arm, or should I be fine
recompiling? I'm a little hesitant to blindly go build the entire arm
toolchain, since I know it can be a little tricky to get working. Are
there plans to include this driver in future kernels?
I have a question on policies of how and whether Fedora-ARM patches are
rolled back into rawhide. The reason I ask is because I see overlap
between the required ARM specific patches between F11 and F12. What is
the policy for rolling these patches back into upstream and (more
importantly in case upstream is slow/reluctant to accept them) rawhide?
Also, what is the policy on new packages? Specifically, I found myself
in need of openssl098k compatibility package (need to run some binaries
from F11). This is pretty trivial to come up with (change the package
name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and
re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory
instead of openssl-0.9.8k directory), but what I wanted to ask if
whether there is some kind of a policy for including things like this in
the main distro. It is likely that this would be useful to other people
who are less willing/able to roll their own packages.
On Thu, Jan 13, 2011 at 12:03 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
> Replying off list since you did the same.
> Peter Robinson wrote:
>> On Thu, Jan 13, 2011 at 11:38 AM, Gordan Bobic <gordan(a)bobich.net> wrote:
>>> Peter Robinson wrote:
>>>> On Thu, Jan 13, 2011 at 10:22 AM, Gordan Bobic <gordan(a)bobich.net>
>>>>> I have a question on policies of how and whether Fedora-ARM patches are
>>>>> rolled back into rawhide. The reason I ask is because I see overlap
>>>>> between the required ARM specific patches between F11 and F12. What is
>>>>> the policy for rolling these patches back into upstream and (more
>>>>> importantly in case upstream is slow/reluctant to accept them) rawhide?
>>>> In a lot of cases the people dealing with the issues have the ability
>>>> to commit the fixes themselves so as to be able to push them directly
>>>> upstream where necessary.
>>> Is there a formal procedure for that? My concern is that this process
>>> doesn't seem to work out in a timely and positive fashion in a
>>> significant number of cases (otherwise we wouldn't have that big a
>>> required patch overlap between Fedora releases on ARM).
>> Not particularly, it depends on the package. In some cases its a
>> simple spec fix, in other cases there's issues with the compilation of
>> the code on non x86 architectures. F-11 and F-12 is also EOL and in a
>> lot of cases the fixes aren't necessary in later releases so again its
>> a matter of review.
>> The timely part of the process is more a resource issue, there's just
>> not that many people and those that are working on it are generally
>> doing either part time or in their own spare time.
>>>>> Also, what is the policy on new packages? Specifically, I found myself
>>>>> in need of openssl098k compatibility package (need to run some binaries
>>>>> from F11). This is pretty trivial to come up with (change the package
>>>>> name from openssl-0.9.8k to openssl098k-0.9.8k in the spec file and
>>>>> re-tar the openssl tar ball to extract to openssl098k-0.9.8k directory
>>>>> instead of openssl-0.9.8k directory), but what I wanted to ask if
>>>>> whether there is some kind of a policy for including things like this
>>>>> the main distro. It is likely that this would be useful to other people
>>>>> who are less willing/able to roll their own packages.
>>>> The policy on new packages is that they have to be in upstream Fedora.
>>> How does one get a package into upstream Fedora?
>> In most core cases there's already compatibility packages for things
>> like openssl but it varies. Is the package that depends on older
>> openssl it proprietary and can't be recompiled.
> Of course it can in theory, but that tends to lead to dependency hell
> somewhere along the way, especially when the package is updated in a new
> version, and the updated package cannot be used.
> Specifically - on the Toshiba AC100 the only kernel that works with built-in
> keyboard and touchpad is 2.6.29. Later versions haven't had this
> functionality ported forward yet.
I have an AC100 as well that I've just got booting a base F-13 image
but using the 2.6.29 kernel too. I'm going to have a go at getting X
etc running on the weekend.
> Thus, the only kernel module for the Tegra driver that can be used is also
> the same one.
> The Nvidia Tegra driver that is old enough to have a compatible interface
> with the kernel driver only has Xorg ABI 5, which means it won't work on
> Fedora versions later than F11.
> So, I have to have Xorg and associated drivers from F11 in order to get
> accelerated graphics working on this machine.
What X driver do you use for accel X?
> Xorg binary links against libssl.so.8/libcrypto.so.8, which means it
> requires openssl 0.9.8k, so the simplest solution is binaries from F11 for
> Xorg with the openssl098k compatibility package.
Yea, I don't think you'll get that into Fedora mainline primarily
because openssl inherently has security issues.
> While I'm sure the old Xorg could be compiled up for F13, building it would
> probably lead to dependency hell on a Fedora 2 versions newer. Using the old
> binaries seems a lot less intrusive at a glance.
Can you link to where you get the X drivers etc from. I'm going to be
looking at this more closely. With luck the problem of older kernels
should disappear for most of the issues before long as the CE industry
is moving towards standardising on 2.6.35.x for their kernel so nvidia
I suspect will be already in process of upgrading to this as its
what's needed for Honeycomb tablets and the like. As to when the
source is released though is anyones guess.