Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson
Hi all,
I would like to introduce myself to the group. I have recently
received an IGEPv2 board [1], 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
seem simple.
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
set variants).
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.6.31).
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 [2].
Does this, in any way, help with the compatibility of packages
targetting Cortex-A8?
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!
Kind regards,
Matthew
[1] http://www.igep-platform.com/index.php?option=com_content&view=article&id...
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beih...
8 years, 4 months
Slow USB storage on A9 processors
by Peter Robinson
Hey All,
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.
https://lwn.net/Articles/457145/
Peter
11 years, 10 months
Raspberry Pi and Eclipse
by Gordan Bobic
Acording to the documentation on raspberrypi.org, it would seem that
Raspberry Pi are dropping Ubuntu in favour of Fedora because Ubuntu is
dropping support for ARMv5/ARMv6 (yay!).
Also, according to the Raspberry Pi wiki, they expect that Eclipse will
work. That doesn't appear to be the case at the moment. Has anybody
managed to get Eclipse to build on ARM recently? Or has Eclipse ARM port
been given up on?
Gordan
12 years
Linaro toolchains and Fedora
by Jon Masters
Hi Michael,
I hope you are doing well. It was good to see you again recently :)
We would like to increase the relationship between Fedora ARM and
Linaro. Although we do not plan to ship the Linaro toolchain as our
primary on-target, etc. I do believe there would be a lot of value in
getting your work available as a simple yum repo or RPM that can be
installed on both an x86_64 Fedora host as a cross-compiler, or on the
target. A simple prefix can distinguish these as Linaro tools.
Can you let me/us know what you think would be required to see this
happen? I hope we can brainstorm about this and other ways to better
collaborate between our respective efforts.
Thanks,
Jon.
12 years, 5 months
Possible glibc bug manifesting only on SMP ARMv7 systems
by Gordan Bobic
Guys,
After chasing my tail for ages thinking I had a hardware issue on an
AC100, it looks like the random segfaults and "glibc detected a
corrupted doubly linked list" errors might actually be SMP and/or ARMv7
related.
Errors:
- random segfaults
- glibc detected a corrupted doubly linked list
Distro: Fedora 13
Platforms that work flawlessly (24/7 compiling for weeks):
- Marvell Kirkwood (1x SheevaPlug, 1x DreamPlug).
Platforms that cause repeatable segfaults (same rootfs, same operation):
- Tegra2 (tested using Toshiba AC100 and Compulab TrimSlice)
- OMAP 4xxx (tested on a PandaBoard)
I'm going to dig into this deeper (boot the machine with nosmp or
tasksetting everything to run on the same core), but in the meantime I
would like to ask if there is a bug in any of the following:
- glibc
- gcc
- binutils
that might cause them to misbehave either on:
- ARMv7 (armv5tel packages on armv7l kernel)
or
- SMP ARM systems
(or both)
I'm going to compile up a clean kernel (without all the hacks I tried on
the AC100 to try to troubleshoot the issue) and try building the
packages in a clean F13 mock just to do a definitive confirmation pass,
but if anyone is aware of any such issues (e.g. due to locking
primitives being different on ARMv7) that have been fixed in
glibc/gcc/binutils recently, I would appreciate any info you may have on
the subject.
Ubuntu doesn't appear to suffer from this issue, but they use a much
newer gcc and a different glibc than what is in F13.
Gordan
12 years, 5 months
Fedora 15 Koji Que Script
by Jon Chiappetta
#!/bin/bash
koji list-tagged dist-f15 > /tmp/k
export l=`find /tmp/f15srpms -type f | grep -i '\.src\.rpm' | wc -l`
export x=1
while true
do
ak list-tagged dist-f15 > /tmp/t
while true
do
ak list-tasks --mine --quiet | grep '^[0-9]' | grep -Ei ' (open|free) .* build' > /tmp/n
#echo "got tasks..." ; cat /tmp/n | wc -l ; echo
if [ `cat /tmp/n | wc -l` -ge 10 ]
then
break
fi
p=`find /tmp/f15srpms -type f | grep -i '\.src\.rpm' | head -n "$x" | tail -n 1`
q=`basename "$p" | sed -e 's/[^0-9A-Za-z]/./g' -e 's/\.src\.rpm//g'`
#echo "checking pkg [$p] [$q]..." ; echo
c=`cat /tmp/n /tmp/t | grep -i "$q"`
let x="($x % $l) + 1"
if [ "$c" != "" ]
then
continue
fi
c=`cat /tmp/k | grep -i "$q"`
if [ "$c" == "" ]
then
continue
fi
echo "queing [$p] skipped [$x]"
ak build dist-f15 "$p" --nowait
let n="$n + 1"
done
sleep 60
done
As you can see the above is not commented but ask me if any parts are unclear.
The script basically:
- checks how many tasks are que'd
- if it hasn't already been built yet in our F15
- if the pkg being que'd exists in the normal F15
12 years, 5 months
Koji status update
by Jon Masters
Folks,
My take on current progress is that we have a lot of packages with bits still needing to head upstream, and we have a number of package deltas between v5 and v7, but the core set of packages we actually need to get a minimal build done is about there. Minus:
* gcc - making sure the bitfields patches are in place for v5
* glibc - delta needs attention
I'm not so concerned about lorax and anaconda at this stage, and I don't think we have critical reps on python3. In reading through the package lists again tonight on DJ's graphs, I can't help but think we could partially import enough packages to get Koji running almost immediately tomorrow, then pull in the rest as we get that resolved. Assuming that is the case, we should focus on gcc and glibc reconciliation and get this going asap.
Please reply to this mail with your input. Let's have a status sync up on IRC later.
Jon.
12 years, 5 months
