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...
7 years, 9 months
Fedora 13 ARM RC1 - Breathing new life into EOL
by Paul Whalen
We are pleased to offer a new and perhaps final release of Fedora 13 ARM. If your upgrading from beta3, run a yum update and you will pull in a new fedora-release package that will include the new key for RC1 as well as new repository files. You will need to do some small house keeping in order to use the new repo:
mv /etc/yum.repos.d/fedora.repo.rpmnew /etc/yum.repos.d/fedora.repo
You may also need to run:
yum clean all
The RC1 repository has been rsync’d to the mirrors to improve bandwidth and take some of the load off the ARM Koji hub.
For those who would like to start fresh, the RC1 root filesystem is available at:
http://scotland.proximity.on.ca/fedora-arm/rootfs/f13-rc1/rootfs-f13-rc1-...
Packages are currently building for the f13-updates repository and it should come online next week. It will also be rsync’d to the mirrors and will be updated as packages are built successfully. If you would like to read more about the new tool being used to build updates you can visit Jon Chiappetta’s
blog (http://fossjon.wordpress.com/2011/06/28/finally-getting-to-really-test-st... details.
If you would like to provide feedback on the release, have questions on usage or comments, please feel free to drop by #fedora-arm on Freenode, or to the Fedora ARM Mailing list – arm(a)lists.fedoraproject.org.
-Paul
12 years, 3 months
RPM available in the rootfs
by Jon Masters
Folks,
Thanks to the hard work of many people (including Stefan's contribution
this morning to get some of the final nss bits and RPM in place, and of
course the groundwork put in place by DJ Delorie), we are now very close
to having rpm and rpmbuild. I fixed a problem with digest support
earlier, we're just waiting on fixing the RPM macros/teaching RPM about
armv7hl vs. armv7l, etc. in patches Dennis already has and will send me.
I'm hoping to get the remaining bits in place so that tomorrow's VFAD
can be spent building actual RPMs. We'll need to start by rebuilding
what we have but in real RPM format, then work toward slowly getting a
buildroot that we can use to rebuild everything again, and finally do
one more build to have a full featured build environment. It would be
awesome to get to a point tomorrow where we've got an armv7hl binutils
binary RPM and its deps at least, with anything else being a bonus.
Jon.
12 years, 3 months
Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
by Jon Masters
Hi Folks,
Join us on Friday to celebrate July with another in our series of VFADs!
This is an awesome opportunity to participate in improving support for
ARM processors, and to learn about architecture bootstrap. Last week, we
successfully added a number of new packages to our bootstrap filesystem
image and got closer to having a working F15 environment we can use to
build official RPMs with hard floating point, on ARMv7 systems.
It's never too soon or too late to help, and you can participate at any
time, by following the instructions linked below - no need to wait for
us, just let us know when you've got bits we can pull into the official
rootfs (which is managed in git) we are building to bootstrap the rest.
Don't forget that you can find out a lot more about the Fedora ARM
project, and about getting involved by visiting the wiki:
http://fedoraproject.org/wiki/Architectures/ARM
Which also contains links to canned images you can use to drop onto your
own ARM system and hit the ground running without any installation time.
Awesomeness!
Jon.
--- Fedora ARM hardfp activity days ---
We are hosting another Fedora 15 hardfp Virtual Fedora Activity Day on
Friday, at 14:00UTC (10:00 Eastern Daylight Time). The purpose of this
session is to co-ordinate the bootstrap of F15 hardfp (hardware floating
point). Going forward, the proposal is that these be on Fridays.
You can find a lot more detail here, along with all the pre-reqs/bits:
https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstra...
That page contains links to the general instructions on:
https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME
or group name branch so that we can track who is doing what, and more
easily back out changes if you/we discover a problem with your setup.
12 years, 3 months
Re: [fedora-arm] elfutils build problem with ARM bootstrap
by Jon Masters
On Mon, 2011-06-27 at 13:01 -0700, Roland McGrath wrote:
> The elfutils ar has never actually supported the u option.
> (That's a trivial bug that I'll fix.)
Ah...so I'm not going crazy...well, not any more so :)
> What's unusual is that you are actually running the elfutils ar.
> It's pretty much not used by anyone, so I wouldn't bet too much on
> it having been tested enough to rely on.
I just do a "make install" in the bootstrap script, which I thought
resulted in an "ar" binary getting installed (as opposed to eu-ar). It
seems Fedora confines the list of files installed to:
%{_bindir}/eu-addr2line
%{_bindir}/eu-ar
%{_bindir}/eu-elfcmp
%{_bindir}/eu-elflint
%{_bindir}/eu-findtextrel
%{_bindir}/eu-nm
%{_bindir}/eu-objdump
%{_bindir}/eu-ranlib
%{_bindir}/eu-readelf
%{_bindir}/eu-size
%{_bindir}/eu-strings
%{_bindir}/eu-strip
#%%{_bindir}/eu-ld
%{_bindir}/eu-unstrip
%{_bindir}/eu-make-debug-archive
Can you let me know which of the elfutils actually matter to use for
bootstrap? i.e. if there's a binutils version of the same name for any
given utility, why not just use the binutils version?
Thanks!
Jon.
P.S. Hope life is treating you well :)
12 years, 3 months
tracking of packages that have build failures
by Dan Horák
Hi all secondary architectures,
s390x is probably the most up-to-date secondary architecture in Fedora
and because there are still packages that fail to build I have started a
wiki page [1] to track that issues. It's meant as a temporary storage
before the failure is fully analysed and
- fix is applied to the package or
- proper bug report in Fedora or upstream is created or
- the set of supported architectures is updated.
Usually a short info about the cause of the failure is written here and
interested parties can take packages from this list and try to resolve
the failure. Right now the list is shared mainly between s390x and ppc,
but in my opinion it could be useful also for other arches, like in
sparc for endianity issues same as in ppc/s390x, etc.
And as you probably know it's a never ending fight because what could be
built yesterday can fail today :-(
Dan
[1] https://fedoraproject.org/wiki/Architectures/BuildIssues
12 years, 3 months
Fedora 14 on armv5tel status update
by Peter Robinson
Hi All,
I've been working on getting Fedora 14 moving forward with the
assistance of Dennis.
I've almost got the build root done except for a few notable
exceptions (glibc, python, perl, sqlite, nss I'm looking at you....)
and the things that depend on them.
A lot of the of the failures (python/sqlite/nss) are in the test
suites so they should be relatively easy to fix. I want to try and get
upstream to either fix or disable the offending issue where possible.
The glibc issue is interesting... it seems its a regression from F-13,
we had to apply a patch for F-13 but even with all that in place I
still get some failures. So it seems to be a regression (and we're
seeing it on the F-15 glibc one as well. I'll do some more testing and
follow up with the logs etc so that someone more smart than I am might
be able to comment and assist :-)
All help and feedback welcome :-D
I've setup a tracker bug for various issues here:
https://bugzilla.redhat.com/show_bug.cgi?id=706236
Once I have the last of the buildroot issue cleaned up we'll release
one of the automatic tools onto the dist-f14 packages and see how
quickly we can get F-14 Gold out of the way and move onto the more
interesting things :-D
Cheers,
Peter
12 years, 3 months
elfutils build problem with ARM bootstrap
by Jon Masters
Hi Folks,
Roland: please see the following page for background:
http://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
Stefan was right that "ar" was broken in the F15 bootstrap. In fact what
happened was that the "ar" rebuilt by elfutils fails to recognize the
"u" option. It seems to be something up with argp_parse routines, though
I haven't had chance to poke much. It's a good thing we used the "ar" in
binutils to build, or we'd probably have hit this problem:
https://lists.yoctoproject.org/pipermail/poky/2010-December/001026.html
(which happens if you then try to rebuild elfutils with the bustes one)
Roland: what I need to know here if possible is why elfutils would be
building without support for this option, but otherwise be working ok?
If I edit all of the Makefile.in in the source to replace "cru" with
"cr", I am able to rebuild elfutils with the busted elfutils, but of
course we still don't have the ability to update archives with ar.
For now, I suggest we switch to the binutils minimal "ar" that has been
working just fine and wait on Roland to get us any ideas.
Jon.
12 years, 3 months
