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, 11 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, 4 months
Pogoplug Pro/OXNAS
by Callum Lerwick
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...
12 years
F15 armv5tel update
by Chris Tyler
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
12 years, 1 month
Another repository verification check that would be useful
by Daniel Drake
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
12 years, 1 month
ARM F-14 Branched report: 20111031 changes
by Fedora compose checker
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
12 years, 1 month
The Fedora Project, Red Hat and ARM
by Jon Masters
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.
12 years, 1 month
Re: [fedora-arm] Fedora 16
by Jon Masters
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
12 years, 1 month
Some broken packages in armv5 moji
by Daniel Drake
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...
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
12 years, 1 month
