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, 3 months
embedded distros
by Gerard Braad
Hello,
The Fedora ports for ARM and MIPS both have a the secondary goal to
enable derivative distributions based on the Fedora package collection
and repository that are more suitably optimized for embedded and
mobile use-cases.
Any efforts we do, could benefit the Mini SIG and vice versa.
Gerard Braad
Note: I am cross-posting this to the the ARM and MIPS mailinglist, but
please discuss further on the Mini list:
https://admin.fedoraproject.org/mailman/listinfo/mini
14 years
ARM Developer package Group?
by Adam Miller
Hello all,
I was wondering if the group would like the idea of having a "ARM
Developer" group available so that we can just do "yum groupinstall
'ARM Developer'" from a fresh new installation of Fedora and have all
the tools we need. Is this something that would be desired? If so,
what all should be put in there?
Just a thought, I imagine we'll have to file a ticket with rel-eng or
FESCo to get it done but I wanted to open the discussion to the group
and see what everyone thought.
-AdamM
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
14 years
Prelink progress
by Andy Green
Hi -
I wrote back in September that prelink was not available, the last days
I studied it more closely and made some progress.
Prelink builds OK but fails some of its tests in the Makefile. But when
I looked at the tests, it seemed that they were failing either due to
problems with the tests themselves or on genuine and well-handled
refusal to prelink stuff.
So I disabled the tests in the spec file, build the package and
prelinked my rootfs, it rejected to prelink some stuff but otherwise
worked, and my boot time decreased by ~1.5s.
When I studied the rejection to prelink, I first realized an important
lib was blacklisted by default, then found this bugzilla about the issue
still unresolved
https://bugzilla.redhat.com/show_bug.cgi?id=504949
After disabling the blacklist for nss, and prelinking the whole rootfs,
there is still a list of "bad guys", these seem that they could be
Fedora packaging / building errors?
/usr/sbin/prelink: /usr/bin/ospcat: Cannot prelink against non-PIC
shared library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/onsgmls: Cannot prelink against non-PIC
shared library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/rarian-sk-migrate: Cannot prelink against
non-PIC shared library /usr/lib/librarian.so.0
/usr/sbin/prelink: /usr/bin/txtr-client-proxy: Cannot prelink against
non-PIC shared library /usr/lib/libxml++-2.6.so.2
Prelinking /usr/bin/ospent
/usr/sbin/prelink: /usr/bin/ospent: Cannot prelink against non-PIC
shared library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/ospam: Cannot prelink against non-PIC shared
library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/rarian-sk-get-cl: Cannot prelink against
non-PIC shared library /usr/lib/librarian.so.0
/usr/sbin/prelink: /usr/bin/osgmlnorm: Cannot prelink against non-PIC
shared library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/lzma: Cannot prelink against non-PIC shared
library /usr/lib/libstdc++.so.6
/usr/sbin/prelink: /usr/bin/openjade: Cannot prelink against non-PIC
shared library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/osx: Cannot prelink against non-PIC shared
library /usr/lib/libosp.so.5
/usr/sbin/prelink: /usr/bin/txtr-reader: Cannot prelink against non-PIC
shared library /usr/lib/libstdc++.so.6
/usr/sbin/prelink: /usr/bin/rarian-sk-preinstall: Cannot prelink against
non-PIC shared library /usr/lib/librarian.so.0
/usr/sbin/prelink: /usr/bin/gcj-dbtool: Cannot prelink against non-PIC
shared library /usr/lib/libgcj.so.10
Any ideas why these libs (they're all from Fedora packages) are not -fPIC?
-Andy
14 years, 1 month
Is there any way to create a repo similar to atrpms.net
by adam
Dear All,
I am just about to compile mythtv for the sheevaplug from
http://atrpms.net/dist/f12/mythtv-0.23/ & was wondering...If I start
with the src rpm'es then eventually I will end up with the RPM's
In the interests of community etc I was wondering if there is
anywhere/site publicly available where I can put the resultant binary
rpm'es so that others won't need to have to compile it themselves.
TIA
Adam
14 years, 1 month
