arm December 2011

arm@lists.fedoraproject.org

23 participants
92 discussions

Fedora ARM 12 on IGEPv2 (Beagle Board clone)
by Matthew Wilson 01 Jan '16

01 Jan '16

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=4… [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344j/Beihgi…

11 15

Slow USB storage on A9 processors
by Peter Robinson 12 Jul '12

12 Jul '12

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

9 18

Raspberry Pi and Eclipse
by Gordan Bobic 18 Apr '12

18 Apr '12

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

4 8

builder io isue
by Dennis Gilmore 03 Jan '12

03 Jan '12

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.

6 18

OpenJDK F15 RPMs
by Andrew Haley 03 Jan '12

03 Jan '12

New ones at http://aph.fedorapeople.org java-1.6.0-openjdk-1.6.0.0-67.1.11pre.fc15.armv7hl I'm looking at branching ready for a new F15 release next week. Andrew.

2 6

builder changes
by Dennis Gilmore 01 Jan '12

01 Jan '12

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

1 1

Koji - RPM naming
by Donald Gullett 31 Dec '11

31 Dec '11

3 7

Tegra2 OC-ing on Toshiba AC100
by Gordan Bobic 31 Dec '11

31 Dec '11

I expect this may be of interest to some people on the lists: http://www.altechnative.net/?p=332 It covers the hardware mod to improve the cooling, and includes kernel patches for both unmodified 1200MHz and modified 1456MHz operation. Gordan

1 0

Fwd: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
by Peter Robinson 31 Dec '11

31 Dec '11

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

1 0

Fedora ARM F-15 Branched report: 20111131 changes
by Fedora compose checker 31 Dec '11

31 Dec '11

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm December 2011