arm October 2011

arm@lists.fedoraproject.org

30 participants
51 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

Pogoplug Pro/OXNAS
by Callum Lerwick 24 Nov '11

24 Nov '11

Hi. I've been looking for a way to get a very power efficient, but still full featured Fedora server for a while, and the recent influx of "plug computers" finally provides the answer. Long story short, I ended up snagging a Pogoplug Pro on sale at Micro Center for $50, before I learned that the Pro is NOT derived from the Kirkwood reference design, but is a completely different architecture called OXNAS from Oxford Semiconductor/PLX. As far as my googling can tell, the recent "black" generation of Pogoplug hardware seems to be the only product in the world using the OXNAS 820 SoC right now. It looks like the WD MyBook uses/used an earlier OXNAS 810 chipset. http://www.plxtech.com/products/consumer/nas7820 http://www.linuxfordevices.com/c/a/News/PLX-Technology-NAS-7800/ It is also "cost reduced" from earlier Pogoplugs, having only 128mb RAM and 128mb of flash. Its a bit slower at 700mhz but is somewhat compensated for by being dual-core. On the up side, there is in fact a SATA port hidden inside the Pogoplug Pro. It also has some interesting features like TCP offload and supposedly an encryption engine. (but I haven't seen any sign of support for the encryption engine in the Cloud Engines source so far) There's also a mini-PCIe slot containing the Pro's wireless card. Anyway, I managed to get Fedora 13 beta3 running on it by first installing PlugApps on it, then I just swapped in a Fedora root FS: http://archlinuxarm.org/platforms/armv6/pogoplug-provideov3 Make sure to copy /lib/modules and /usr/local over from the PlugApps FS. The network driver is compiled as a module, and it will not auto load. Especially if you don't have a serial console set up, before booting you'll need to pop in a script at /etc/sysconfig/modules/oxnas-gmac.modules : #!/bin/sh exec /sbin/modprobe gmac >/dev/null 2>&1 Make sure it is chmod 755 Also the driver wants firmware for the TCP offload, and seems to have a bug where it will just lock up the system if it can't find it. You'll find it at /lib/modules/2.6.31.6_SMP_820/gmac_copro_firmware , just move it to /lib/firmware/ and you should have working ethernet. There's some weirdness with the MAC address, the driver just sets it to a hardwired default of "00:30:E0:00:00:00" as there does not seem to be in-kernel infrastructure to read uboot variables. The PlugApps install script writes the MAC into /usr/local/mac_addr and the network scripts change it before bringing the interface up. I don't understand why they don't just read it directly from NVRAM using /usr/local/cloudengines/bin/blparam . But currently my Pogoplug Pro is just using the default MAC. Setting the MAC properly should be a simple matter of scripting... Unfortunately the PlugApps kernel is very minimal. It does not have any NFS server support enabled, and for some reason ext4 is compiled as a module, so your root FS has to be ext2 or ext3. I managed to successfully compile the Cloud Engines kernel source and write it to flash just past the original PlugApps kernel, so the original PlugApps kernel and even the stock Pogoplug OS can still be booted in a pinch using the uboot console. (But I may have overwritten a backup Pogoplug kernel...) http://www.pogoplug.com/developers-open-source.html If you do not have a serial console set up, do NOT mess with the flash! If you screw up the boot sequence, there is no way to un-brick these things without one. There is NO "reset nvram to defaults" button. I'd really like to run btrfs on this, but the stock kernel is 2.6.31, and my research indicates you want at least 2.6.33 for stable btrfs. Also, support for the wireless card was merged in 2.6.34. I have successfully upgraded the kernel through the incredibly awkward and time consuming (but educational) method of applying the Cloud Engines changes to 2.6.31 in a git branch, then rebasing 2.6.32 on top of it. So my Pogoplug Pro has been running 2.6.32 for the last few months with no problem. I'll see about pushing forward further once I have some time to kill. (Pretty much takes a full day for my old secondary laptop to chew through the whole rebase...) So now I have my Pogoplug Pro working nicely as a Samba server for my windows machines, and a NFS4 server for my Fedora machines. I originally wanted to run a MythTV backend on it, but that may be pushing it a bit with only 128mb RAM. Not to mention the fun of getting MythTV compiled for Fedora arm in the first place...

2 1

F15 armv5tel update
by Chris Tyler 08 Nov '11

08 Nov '11

So Moji has burned through all of the armv5tel builds at least once[0]; we have 4092 successful builds and 915 error builds at this point. Jon and Paul are pulling in some lovingly hand-crafted builds done on the weekend (thanks tinker915 and Henrick) and working through the error'd builds -- any help is appreciated if you have some free cycles. I think we're about ready to... - compare the armv5tel and armv7hl package sets again - solve any discrepancies - double-check that patches have been upstreamed ...and then do the koji external repo setup. -Chris [0] http://moji.proximity.on.ca/moji

6 16

qt-4.7.4-3.fc15.armv5tel for moji
by Daniel Drake 02 Nov '11

02 Nov '11

Hi, qt failed to build both times in moji due to running out of memory on the selected builder. So I built it on one of OLPC's systems with 3GB: http://dev.laptop.org/~dsd/for-f15-arm/qt-4.7.4-3.fc15.tar Importing this should hopefully fix a significant number of builds. Daniel

4 3

Another repository verification check that would be useful
by Daniel Drake 02 Nov '11

02 Nov '11

perl-Coro built in armv7hl stage3 but failed in stage4, and hence is only present in stage3. Packages like filelight then were then built successfully into stage4 pulling on perl-Coro from stage3. armv5tel build efforts have cloned stage4's RPM set, but not stage3. So we currently are not attempting to build perl-Coro (since no SRPM appears in stage4), and packages which depend on this (like filelight) are failing at the first hurdle. It would be really useful if someone could look into the perl-Coro failure, and it would be even more useful if someone could write a script that identifies packages that were built in stage3 but not in stage4. Thanks, Daniel

2 3

ARM F-14 Branched report: 20111031 changes
by Fedora compose checker 31 Oct '11

31 Oct '11

Compose started at Mon Oct 31 19:42:45 UTC 2011 Loaded plugins: langpacks, presto, refresh-packagekit New package: libassuan1-1.0.5-5.fc14 GnuPG IPC library v1 Updated Packages: dirmngr-1.1.0-1.fc14 -------------------- * Tue Aug 10 2010 Rex Dieter <rdieter(a)fedoraproject.org> - 1.1.0-1 - dirmngr-1.1.0 hdf5-1.8.5-1.fc14 ----------------- * Mon Jun 21 2010 Orion Poplawski <orion(a)cora.nwra.com> 1.8.5-1 - Update to 1.8.5 - Drop patches fixed upstream libksba-1.0.8-1.fc14 -------------------- * Fri Jul 23 2010 Rex Dieter <rdieter(a)fedoraproject.org> - 1.0.8-1 - libksba-1.0.8 mutt-1.5.21-1.fc14 ------------------ * Tue Sep 21 2010 Miroslav Lichvar <mlichvar(a)redhat.com> 5:1.5.21-1 - update to 1.5.21 - link with gpg-error when building with gpgme support (#621626) nco-4.0.4-1.fc14 ---------------- * Fri Oct 01 2010 - Orion Poplawski <orion(a)cora.nwra.com> - 4.0.4-1 - Update to 4.0.4 tokyocabinet-1.4.46-1.fc14 -------------------------- * Fri Aug 06 2010 Deji Akingunola <dakingun(a)gmail.com> - 1.4.46-1 - Update to 1.4.46 Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 6

1 0

The Fedora Project, Red Hat and ARM
by Jon Masters 30 Oct '11

30 Oct '11

At its annual TechCon event in Santa Clara today, ARM announced ARMv8, its new 64-bit version of the ARM Architecture. The Fedora ARM community is excited to learn more about the new architecture, and we look forward to supporting ARMv8 in a future release of Fedora. As the 8th iteration of the ARM Architecture, ARMv8 (also known as AArch v8) brings new opportunities to Fedora running on increasingly more powerful ARM machines. At the same time, it retains compatibility at the application level with existing 32-bit ARM software, which is already being built on Fedora 15. Supporting a new architecture takes some time and we have a lot of work ahead of us -- both at the distribution level (bootstrapping, similar to the work recently undertaken for Fedora 15 on ARMv7) and at the wider community level (cross-distribution and industry standardization). All this is in the future – it will take several years before ARMv8 computers can be purchased. In the interim, we've got a lot of work to do to support the existing 32-bit technology in Fedora 15 and beyond. Now is an exciting time to get involved with the Fedora ARM project! To join us, please visit our wiki page, http://fedoraproject.org/wiki/Architectures/ARM and contribute on IRC: #fedora-arm (Freenode). -- Jon. FAQ: Q: Please clarify some of the terms used to describe 64-bit ARM. A: The name of the new architecture is ARMv8, also known generically as AArch v8. The new Instruction Set Architecture (ISA) is known as A64, and the existing 32-bit ISA will be known as A32 (and T32 for the Thumb instruction set). 64-bit execution mode is known as AArch 64; 32-bit execution mode (ARMv7 compatible) is known as AArch 32. It is proposed that we adopt armv8 as the official architecture name within the Fedora ARM project. Q: When will Fedora support 64-bit ARM processors? A: There is no support currently available in Fedora for the A64 ISA in the core toolchain, kernel, and other distribution-level components required to build ARMv8 packages. Once the necessary support is available in the upstream projects that Fedora relies upon, we plan to support ARMv8 in Fedora. Q: What does this mean for Fedora 15 and soon, for Fedora 16? A: At the moment, nothing has changed. Historically, ARM announces new architecture improvements years before hardware supporting those improvements is available. ARM doesn’t build processors; instead, they license their architecture and processor designs to others. Therefore, it will be some time before 64-bit ARM systems can be purchased, and it will be a while before Fedora runs on those systems. Q: Since Red Hat Enterprise Linux is largely based on Fedora, will Red Hat support ARMv8 in a forthcoming product release? A: There is much work to do in ARMv8 before it would be considered suitable for Red Hat Enterprise Linux customers. Currently, Red Hat’s ARMv8 investments are focused on Fedora, utilizing Fedora’s rapid development cycle to drive and mature these types of emerging technologies. As the ARMv8 technology develops, Red Hat will work to determine ARMv8’s applicability to be a supported architecture within Red Hat Enterprise Linux.

2 1

Re: [fedora-arm] Fedora 16
by Jon Masters 29 Oct '11

29 Oct '11

Plan was to release a good enough F15 but absolutely to do some kind of release (just cap when we will move on to keep momentum - a couple more weeks and we need to be focused on rawhide). It's F16 we are wanting to skip in order to focus on rawhide by the new year. -- Sent from my phone - message formatted and/or shortened accordingly. -----Original Message----- From: Peter Robinson [pbrobinson(a)gmail.com] Received: Tuesday, 25 Oct 2011, 11:17 To: Chris Tyler [chris(a)tylers.info] CC: Fedora ARM secondary architecture list [arm(a)lists.fedoraproject.org] Subject: Re: [fedora-arm] Fedora 16 On Tue, Oct 25, 2011 at 6:09 PM, Chris Tyler <chris(a)tylers.info> wrote: > On Tue, 2011-10-25 at 17:49 +0100, Peter Robinson wrote: >> So what's the status of this? Are we using the F-15 as the external >> repo base for building F-17? When is it going to happen? My >> understanding is we have enough of both arches built that we can start >> this rolling. It would be good to see some public movement on this now >> and to get this rolling rather than delaying further. > > No one's delaying, but there is a sequence to this that we shouldn't > short-circuit: > > * Sync up the armv5tel and armv7hl pre-koji package sets <= We are here > * Do final F15 build in Koji It was my understanding from dgilmore's proposal above that we were going to skip F-15 and just go straight to F-17. Ultimately whether we do a final F-15 or F-17 it doesn't really matter, the current build tool chain for them both is derived from gcc 4.6.1 > * Release F15 (& start F15-updates builds) > * Finalize koji changes for rawhide (rpm, rpmbuild, yum, koji, armv7hl > rootfs) > * Do necessary prebuilds for rawhide (build-previous or other) > * Build for rawhide, shadow PA as closely as possible > * Branch F17 when PA does > > At the end of this process we'll be building for at least three releases > (F15updates, F17, rawhide) across two archs - 6 builds total. Why? I thought the above process was with the idea of just using the F-15 work that was done as a base to go straight to F-17 and forget the rest. Clearly people need to start documenting the exact process for all to see. Peter _______________________________________________ arm mailing list arm(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm

4 3

Some broken packages in armv5 moji
by Daniel Drake 27 Oct '11

27 Oct '11

Hi, Please delete all of these packages from armv5tel moji: ikiwiki-0:3.20110328-1.fc15.noarch mailgraph-0:1.14-9.fc15.noarch mr-0:1.02-1.fc15.noarch perl-App-Asciio-0:1.02.71-8.fc15.noarch perl-App-CLI-0:0.07-10.fc15.noarch perl-CGI-Application-Plugin-Session-0:1.03-7.fc15.noarch perl-CGI-Untaint-email-0:0.03-11.fc15.noarch perl-Class-Inner-0:0.200001-3.fc15.noarch perl-Crypt-SSLeay-0:0.58-4.fc15.armv5tel perl-Crypt-Twofish-0:2.14-4.fc15.armv5tel perl-DBIx-SearchBuilder-0:1.59-2.fc15.noarch perl-Data-FormValidator-Constraints-DateTime-0:1.11-3.fc15.noarch perl-Date-Pcalc-0:1.2-11.fc15.noarch perl-File-ExtAttr-0:1.09-7.fc15.armv5tel perl-Graph-0:0.91-7.fc15.noarch perl-Image-Xpm-0:1.09-15.fc15.noarch perl-Math-Calc-Units-0:1.07-3.fc15.noarch perl-Math-MatrixReal-0:2.05-7.fc15.noarch perl-MooseX-CascadeClearing-0:0.04-1.fc15.noarch perl-MooseX-SemiAffordanceAccessor-0:0.08-4.fc15.noarch perl-Nagios-Plugin-0:0.35-3.fc15.noarch perl-POE-Test-Loops-0:1.035-3.fc15.noarch perl-Pod-PseudoPod-0:0.16-6.fc15.noarch perl-Socket6-0:0.23-6.fc15.armv5tel perl-Test-Aggregate-0:0.364-1.fc15.noarch perl-Test-File-Contents-0:0.05-8.fc15.noarch perl-Tk-Text-SuperText-0:0.9.4-4.fc15.noarch perl-qooxdoo-compat-0:0.7.3-9.fc15.noarch They were built against an old perl with perl(:MODULE_COMPAT_5.10.1) and cause other builds to break now we have a new perl e.g. http://moji.proximity.on.ca/fedora-arm/f15v5.0/repo/mock.spamass-milter-0.3… After those packages get fixed it might be worth running a grep for "Requires: perl(:MODULE_COMPAT_5.10.1)" in build failure logs and requeuing affected packages. Thanks, Daniel

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm October 2011