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 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.
2012/4/25 Nicolas Chauvet <kwizart(a)gmail.com>:
> 2012/4/23 Dan Horák <dan(a)danny.cz>:
>> I'm usually skipping such packages as there is a lot of other work on
>> s390, but when I dealt with them I've used either the gcc or C++
>> primitives or the atomic_ops library. The Pixie package seems to be on
>> my list of blocked by atomic ops, there should be more, but I haven't
>> analysed all failures yet.
Been the Pixie maintainer and trying to fix the issue. I can test
anything on either my AC100 running F14 or 'soonish' a Pandaboard with
As Dan told me, there is a need to use a generic gcc intrinsinc code
for atomic_ops from this files:
The current generic function doesn't work and I wasn't able to sort
that out. (even if it look trivial, there is others problem than
adding a missing headers as the error sugguest)
I wonder if It wouldn't worth to grab some equivalent ARM asm to
implement the same functions for __ARM_EABI__.
For the record, Pixie is an image renderer engine and requires massive
CPU load which worth to have optim enabled.
This is also a 'Final component' so it will not be triggered by
something that could run on a armv5 only CPU.
So my question is how can I opt-out armv5tel to force armv7l
compilation instead ?
Thx for your help.
On Thu, Mar 22, 2012 at 02:02:26PM -0600, Orion Poplawski wrote:
> On 03/22/2012 01:30 PM, Brendan Conoboy wrote:
> >On 03/22/2012 11:10 AM, Orion Poplawski wrote:
> >>I started looking at:
> >>VM starts okay in F16 with setsebool -P virt_use_execmem=on
> >>But the image is a Fedora 12 system. Any updated images out there?
> >You should be able to use the F17 alpha 1 image. The pointer is it:
> >We'll have the document updated for this soon. I've set reply-to to the arm
> >list since the responsible parties are all there.
> Sorry, still very green with vm wrangling. How do I take the rootfs
> tarball and make a qemu image I can use with libvirt?
I've not actually tried it for this situation, but virt-make-fs can
turn a tarball into a disk image.
Probably something like this:
virt-make-fs -s 1G -t ext3 -F raw --partition=mbr rootfs.tar disk.img
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
In general pretty good - they work well. However there are a few
problems I encountered:
(1) There's no source for the boot scripts. I think you should put
the source along side the binaries, in /boot/uboot. I ended up using
'strings' and reconstructing them.
(2) The sda boot script works fine, however the mmc boot script fails.
'fatload mmc 0:1 ...' should be 'fatload mmc 1:1 ...' (in both places).
(3) If you have both images installed, then it boots one of them at
random, because it boots from 'root=LABEL=rootfs' which picks one of
the labelled root devices at random.
This is not a completely stupid configuration: you need to do this if
you're booting from a USB key and copying the mmc image to the
internal drive. At some point you'll have a trimslice with both the
sda image and the mmc image. Probably better to use UUIDs, or to have
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
On 04/30/2012 12:56 PM, Josh Boyer wrote:
> On Mon, Apr 30, 2012 at 12:50:56PM -0400, Eric Paris wrote:
>> On Mon, 2012-04-30 at 12:47 -0400, Josh Boyer wrote:
>>> On Sun, Apr 29, 2012 at 02:40:01AM -0400, Jon Masters wrote:
>>> Going to assume you forwarded this here because you want it applied to
>>> the Fedora kernel. Likely F17/rawhide?
>>> I'm guessing we probably want to follow
>>> for a bit to see if there are any more iterations of this?
>>> Since it's CC'd to stable, it should get picked up rather quickly if RMK
>>> applies it.
>> You probably want to follow this thread as it's where an ARM developer
>> actually looked at it :)
> Yep, saw that too. Guess I'll keep my eyes peeled.
Yea, as Russell says, the original code in there for audit was "complete
crap". My fix was just to get rid of obvious register corruption after
wasting a lot of time hunting it down, but I did not extensively test
audit to see that it was actually working since it seemed obvious there
would be other problems, too (you know, given this, who knows what else
is wrong - clearly nobody uses it). Will's version is probably where
we'll go for this issue. I'm going to test his patch later and then see
if audit actually works properly with some further tests - again,
leaning toward turning off audit on ARM anyway until we know there are
no more horrors, given this little shocker.
P.S. Technically OOTO today. I'll test the latest patch tonight and
followup - yes, I did forward assuming you'd want to pull, and next time
I'll try harder to spell out my intent/request, etc.
OLPC has moved from xulrunner to WebKit (yay) and ARMv5 to ARMv7 (yay)
on Fedora 17.
However, we're now facing very crashy behaviour in webkit,
load a gmail inbox and try to scroll to the bottom. It will almost
always crash (segmentation fault) while loading the page, if not it
will crash while you scroll.
The crash also happens in Sugar's Browse activity, also based on webkitgtk3.
gdb is not that helpful:
#0 0x00000024 in ?? ()
#1 0x49f0eaf4 in ?? ()
#2 0x49f0eaf4 in ?? ()
Works fine on our x86 laptops - only ARM is affected.
Recompiling webkitgtk3 with --disable-jit
around the issue.
also explain why gdb doesn't know where the code is coming from.
I've reported this upstream at https://bugs.webkit.org/show_bug.cgi?id=85076
Is anyone interested in helping out figure out this bug? I know there
are several low-level ARM experts on this list.
My plan B, which I'd rather avoid, is disabling the ARM JIT in the
Fedora packages for webkitgtk/webkitgtk3.