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
builder io isue
by Dennis Gilmore
When we were testing build were happening really fast, once we loaded
up the build jobs things have become really slow
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=238672 started
at 1:19 utc and at 5:18 utc four hours later the buildrequires are
still being installed. australia is completely io bound. i think we
need to see how we can spread the io load. ~30 hosts reading and
writing to the 4 spindles just saturates the disk io. i guess options
are find a way to add more spindles. move /var/lib/mock to sdcard, see
if we can get some kind of san that has alot of smaller fast disks. get
some 2.5" usb drives one for each builder. some other idea? is there
anyway we could add 4-8 more disks to australia. the size of the
matters little. gaining more iops by adding more spindles would help.
Just throwing out what im seeing. lets see what ideas we can come up
with. performance is better than before. and seneca has done a great
job and put a lot of hard work into the reorg and im thankful for that.
We just have another bottleneck to address.
12 years, 4 months
builder changes
by Dennis Gilmore
Hi all.
in the sprit of transparency. I have made some changes to the builders
that are currently online
to /etc/sysctl.conf ive added
vm.min_free_kbytes = 65000
vm.swappiness = 0
and ive made sure all builders have a swap file at /swap1
Dennis
12 years, 4 months
Fwd: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
by Peter Robinson
For those that don't follow mainline is there any ARM related things
that we should ensure is in gcc 4.7.0? I think it should be better for
us as there was at least a couple of patches in master over the 4.6
branch that we needed.
I aim to essentially follow the mass rebuild for f17 ARM so we need to
ensure koji is ready, stable and fast :-)
Peter
---------- Forwarded message ----------
From: Jakub Jelinek <jakub(a)redhat.com>
Date: Sat, Dec 31, 2011 at 11:56 AM
Subject: Results of a test mass rebuild of rawhide/x86_64 with
gcc-4.7.0-0.1.fc17
To: devel(a)lists.fedoraproject.org
Hi!
As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed
a test mass rebuild of rawhide (December 23th package list) using
gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the
list packages that fail for non-gcc related reasons.
Out of the 11270 packages I've built, 10056 packages built fine with
gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with
gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis.
I've analyzed some of the remaining failures and tried to categorize it
a little bit. There were 3 internal compiler errors seen during the
whole mass rebuild, http://gcc.gnu.org/PR5169{2,4,5} are currently
filed and slightly analyzed, but not fixed yet.
CCing Benjamin if he'd be interested to write
http://gcc.gnu.org/gcc-4.7/porting_to.html again this time.
The common reasons for build failures were (I'm attaching srpm lists for
these categories):
http://gcc.gnu.org/PR49745 119 failures
<iostream>, <string> and other STL headers that previously
included <unistd.h> as an implementation detail (to get some
feature macros for gthr*.h purposes) no longer do so (it was
a C++ standard violation), to fix this up just add
#include <unistd.h> early in the sources (or headers) that need it.
http://gcc.gnu.org/PR24163 60 failures
http://gcc.gnu.org/PR29131 28 failures
C++ lookup fixes, the C++ FE no longer performs an extra unqualified
lookup that it (incorrectly) performed in the past. In some cases the
diagnostics includes hints how to fix the bugs, for PR24163 the
diagnostics looks like:
error: 'something' was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
note: declarations in dependent base 'someclass<somearg>' are
not found by unqualified lookup
note: use 'this->something' instead
and for PR29131 diagnostics looks like:
error: 'something' was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
note: 'template<class T1, class T2> sometype something(T1&,
const T2&)' declared here, later in the translation unit
checking for stdbool.h that conforms to C99... no 2 failures
but affects
other 150+ packages
apparently autoconf 2.60 through autoconf 2.67 contains an invalid
check in its stdbool.h checking macro:
# if defined __xlc__ || defined __GNUC__
/* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
reported by James Lemley on 2005-10-05; see
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
This test is not quite right, since xlc is allowed to
reject this program, as the initializer for xlcbug is
not one of the forms that C requires support for.
However, doing the test right would require a runtime
test, and that would make cross-compilation harder.
Let us hope that IBM fixes the xlc bug, and also adds
support for this kind of constant expression. In the
meantime, this test will reject xlc, which is OK, since
our stdbool.h substitute should suffice. We also test
this with GCC, where it should work, to detect more
quickly whether someone messes up the test in the
future. */
char digs[] = "0123456789";
int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4]
? 1 : -1);
# endif
As written, the test is not quite right and a conforming C compiler
is not required to accept it and starting with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
GCC rejects it (and similarly from what I understood from autoconf
2.68 notes recent xlc rejects it as well). autoconf 2.68 dropped
this incorrect check, but apparently many packages include their
own configure scripts without regenerating them. Wonder what is the
best thing to do here, ask package maintainers to grep for this
int xlcbug = ...; in their packages and sedding that to
int xlcbug = 0;, or dropping that || defined __GNUC__ above the
invalid test, or asking where possible to regenerate configure with
autoconf 2.68, perhaps some rpm-build script to do the sedding?
Most of the 150+ packages just refused to use the system <stdbool.h>
because of this and did something else (either provided their own
stdbool.h alternative, falled back to using int instead of bool,
...), the 2 failures were just cases where this was a fatal failure.
https://svn.boost.org/trac/boost/ticket/6165 26 failures
Apparently boost uses some libstdc++-v3 internal macros to determine
if gcc has been configured with or without thread support, in GCC 4.7
these internal macros changed and boost thinks GCC 4.7.0 no longer
supports threads (e.g. in libstdc++ headers). The fix here will be
just to fix up boost package we include.
gcc driver became more picky about
bogus options during linking 14 failures
GCC 4.6 and earlier apparently didn't complain about completely
invalid options on gcc/g++/gfortran etc. command lines, if
nothing was compiled, but only linking was performed.
E.g. gcc -Wl -o foo foo.o -mflat_namespace
would work just fine, even when -Wl needs to have some option
to pass to the linker after it and -mflat_namespace isn't supported
at all. Garbage options just need to be removed from the command
line or replaced by something that is actually supported.
http://gcc.gnu.org/PR2288 8 failures
For C++, GCC 4.6 and earlier incorrectly put the two
declarations in different scopes in cases like:
for (int i = 0; i < 10; i++)
{
int i = 2;
}
While that is valid C99 (where there is a separate scope
with the for declared vars and { int i = 2; } is another scope
inside it), in C++ this is invalid, the int i = 0; declaration
goes into the same scope as the body of the for cycle (similarly
for if/switch). To fix this, either rename one of the decls,
or if you really meant to have the same name and want to have
them in different scopes, add another pair of {}s around the body.
With
for (int i = 0; i < 10; i++)
{{
int i = 2;
}}
the inner {} is already a nested scope.
user defined literal support 3 failures
When compiling C++ with -std={c++11,c++0x,gnu++11,gnu++0x} GCC 4.7.0
unlike older versions supports user defined literals, which are
incompatible with some valid ISO C++03 code.
In particular, whitespace is now needed after a string literal
before something that could be a valid user defined literal.
Say const char *p = "foobar"__TIME__; is valid C++03, the __TIME__
macro expands to some string literal and is concatenated with the
other one. In C++11 __TIME__ isn't expanded, instead operator ""
__TIME__ is being looked up. This applies to any string literal
followed without whitespace by some macro. Just add some whitespace
between the string literal and the macro name.
-Werror 12 failures
As usually, packages compiled with -Werror sometimes fail because
newer GCC versions emit slightly different warnings (could be
correct warnings, newly introduced warnings, could be even false
positives, but with -Werror you need to be prepared to workaround
them).
libgcj 6 failures
gcc-4.7.0-0.1.fc17 contained a packaging bug for libgcj, the
libgcj.so symlink incorrectly pointed to libgcj.so.12 instead
of libgcj.so.13. Will fix this for -0.2.fc17, to this category
I've also included package failures where non-indirect-dispatch
gcj built packages failed to build due to their dependencies
not finding libgcj.so.12 dependency. Those will just need to
be rebuilt.
unanalyzed 91 failures
Ran out of time, haven't analyzed the remaining ones (other
category), once gcc-4.7.0-0.*.fc17 hits the buildroots,
please try to analyze these. Could be gcc bugs, but could
very well be package bugs. E.g. in glibc (which built fine,
just failed a couple of tests that previously succeeded),
I've discovered it was a glibc bug:
http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html
Jakub
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
12 years, 4 months
Fedora ARM F-15 Branched report: 20111131 changes
by Fedora compose checker
Compose started at Sat Dec 31 13:49:24 UTC 2011
Loaded plugins: langpacks, presto, refresh-packagekit
Could not setup repo at url file:///mnt/koji/mash/branched-20111131/15/source/SRPMS: Cannot retrieve repository metadata (repomd.xml) for repository: new1. Please verify its path and try again
Compose finshed at Sat Dec 31 14:52:13 UTC 2011
12 years, 4 months
