I would like to introduce myself to the group. I have recently
received an IGEPv2 board , 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
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
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) 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 .
Does this, in any way, help with the compatibility of packages
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!
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.
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:
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
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/188.8.131.52_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...)
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"
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...
Following on from the founding of the cross-distro ARM mailing list,
I'd like to propose an ARM summit at this year's Linux Plumbers
conference . I'm hoping for a slot on Thursday evening, but this
remains to be confirmed at this point.
We had some lively discussion about the state of ARM Linux distros at
the Linaro Connect  event in Cambridge last week. It rapidly became
clear that some of the topics we discussed deserve a wider audience,
so we're suggesting a meetup at Plumbers for that bigger
discussion. The initial proposed agenda is:
* ARM hard-float
+ What is it and why does it matter?
+ How can distributions keep compatible (i.e. gcc triplet to
describe the port)?
* Adding support for ARM as an architecture to the Linux Standard
+ Does it matter?
+ What's needed?
* FHS - multi-arch coming soon, how do we proceed?
* 3D support on ARM platforms
+ Open GL vs. GLES - which is appropriate?
but I'm sure that other people will think of more issues they'd like
to discuss. :-)
If you wish to attend, please reply to the cross-distro list and let
us know to expect you. Make sure you're registered to attend Plumbers
Conf, and get your travel and accommodation organised ASAP.
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
I was looking at some of the package build failures and saw that the
package gettext is failing due to test failures. Looking on the web I
see that others have indicated that the test that fails may be related
to the gnulib used for m4:
"This is failing with EINVAL instead of ENOENT, which is contrary
to POSIX. However, this kernel bug has already been papered over
in gnulib, which means that it is merely a matter of updating m4
to use newer gnulib to make this test failure go away."
It looks like the "fix"/workaround (if it is indeed correct) may have
come after we built m4 for stage3.
I'm not that familiar with the stage3 builds, and what may or may not
have been done to get them to build for ARM, so if someone familiar with
it would not mind looking into this, I would appreciate it.
We are hosting another one of our regular Fedora 15 hardfp Virtual
Fedora Activity Day today Friday August 26th 2011, at 14:00UTC (10:00
Eastern Daylight Time). The purpose of this session is to co-ordinate
the continued bootstrap of F15 hardfp (hardware floating point).
Previously, we performed initial bootstrap (stage1), then proceeded to
get RPM working natively within an ARMv7 hardfp environment (stage2),
then got yum and mock working (stage3). We are now in what we are
calling "stage4" in which we are rebuilding the world of packages using
mock, but are not yet using Koji to do so - that will be stage5, the
final stage before we are able to say that we have completed bringup.
We need helping building packages within a mock environment for F15. To
do this, we have made your life as a (potential) volunteer somewhat more
straightforward through the creation of a standard image that you can
install onto an ARMv7 compatible board (tested on Panda, we believe this
should also work on Beagle, and can be made to run on Tegra-2 boards
like Trimslice with a replacement kernel - ask us for assistance). Once
you have done this, the resulting system will contain a simple script
that you can use to randomly retrieve a package that needs building and
have it build without you having to even issue a single mock command :)
To participate, visit the following link:
Follow the instructions contained within the readme file to extract the
"uboot", "boot", and "root" archives onto an SD Card for your device.
These instructions will destroy whatever is already installed. If you
are familiar with using chroots, you can also retrieve the "root" image
and chroot into it if you would prefer (after bind mounting /proc, /dev,
etc.). We generally prefer not using chroots at this stage however.
Once you have followed the setup instructions:
0). Configure /etc/sysconfig/network
and /etc/sysconfig/network-scripts/ifcfg-eth* according to your setup.
The ones in that image statically assign "tenaya.bos.jonmasters.org".
1). Login to your board as root (password is "fedora"). Change the
password if you would like to do so.
2). Become the "builder" user. You can either "su - builder" or you can
"passwd builder", and then login remotely/on the console.
3). Optional, but recommended, use "screen -S builder" or similar to
start a screen session that you can leave running.
4). Run the simple building script: ./arm-rebuild.sh
5). Monitor the arm mailing list. It is likely that a newer version of
the builder script will be posted later today or before Monday. When
that happens, we may change the SSH keys used in the build image, which
would have the effect of forcing everyone to update. The purpose of that
being to prevent any existing builders running the older script version.
Instructions will be posted for updating a couple files will be posted.
Please join us on IRC: #fedora-arm on irc.freenode.org.
Further documentation will be provided on the Fedora ARM wiki today,
however this email should provide sufficient setup information now.
russell, good to hear from you.
can i recommend, that although this is a really wide set of
cross-posting on a discussion that underpins pretty much everything
(except gnu/hurd and minix) because it's linux kernel, that, just as
steve kindly advised, we keep this to e.g.
cross-distro(a)lists.linaro.org? i'll be doing that from now on [after
this] perhaps including arm-netbooks as well, but will be taking off
all the distros.
so - folks, let's be clear: please move this discussion to
cross-distro(a)lists.linaro.org, and, if it's worthwhile discussing in
person, please do contact steve, so he can keep the slot open at the
Plumbers 2011 summit.
On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux
> On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
>> As such refactoring consolidated larger and larger chunks of kernel
>> code, new designs would gravitate towards those consolidated
>> implementations because they would be the dominant references.
> Don't bet on it. That's not how it works (unfortunately.)
> Just look at the many serial port inventions dreamt up by SoC designers -
> everyone is different from each other. Now consider: why didn't they use
> a well established standard 16550A or later design?
*sigh* because they wanted to save power. or pins. or... just be
> This "need to be different" is so heavily embedded in the mindset of the
> hardware people that I doubt "providing consolidated implementations"
> will make the blind bit of difference.
i think... russell... after they are told, repeatedly, "no, you can't
have that pile of junk in the mainline linux kernel, Get With The
Programme", you'd think that, cumulatively if they end up having to
maintain a 6mb patch full of such shit, they _might_ get with the
and if they don't, well.... who honestly cares? if they don't, it's
not *your* problem, is it? _they_ pay their employees to continue to
main a pile of junk, instead of spongeing off of _your_ time (and
linus's, and everyone else's in the Free Software Community).
> I doubt that hardware people
> coming up with these abominations even care one bit about what's in
> the kernel.
then don't f******g make it _your_ problem, or anyone else's, upstream!! :)
this is the core of the proposal that i have been advocating: if it's
"selfish", i.e. as bill and many many others clearly agree with "if
the bang-per-buck ratio is on the low side" then keep it *out* the
mainline linux kernel...
... and that really is the end of the matter.
the sensible people that i've been talking to about this are truly
puzzled as to why the principles of "cooperation and collaboration"
behind free software are just being... completely ignored, in
something as vital as The Linux Kernel, and they feel that it's really
blindingly obvious that the "bang-per-buck" ratio of patches to
mainline linux kernel need to go up.
so the core of the proposal that is the proposed
"selfish-vs-cooperation patch policy" is quite simple: if the patch
has _some_ evidence of collaboration, cooperation, refactoring,
sharing - *anything* that increases the bang-per-buck ratio with
respect to the core fundamental principles of Free Software - it goes
to the next phase [which is technical evaluation etc. etc.].
otherwise, it's absolutely out, regardless of its technical
correctness, and that's the end of it.
the linux kernel mainline source tree should *not* be a
dumping-ground for a bunch of selfish self-centred pathological
profit-mongering corporations whose employees end up apologising in
sheer embarrassment as they submit time-pressured absolutely shit
non-cooperative and impossible-to-maintain code.
you're not the only one, russell, who is pissed off at having to tidy
up SoC vendors' patches. there's another ARM-Linux guy, forget his
name, specialises in samsung: two years ago he said that he was
getting fed up with receiving yet another pile of rushed junk... and
that's *just* him, specialising in samsung ARM SoCs!
we're just stunned that you, the recipient of _multiple_ SoC vendors
piles of shite, have tolerated this for so long!
anyway - i've endeavoured to put together some examples, in case
that's not clear: i admit it's quite hard to create clear examples,
and would greatly appreciate help doing so. i've had some very much
appreciated help from one of the openwrt developers (thanks!)
clarifying by creating another example that's similar to one which
this should be _fun_, guys. it shouldn't be a chore. if you're not
enjoying it, and not being paid, tell the people who are clearly
taking the piss to f*** off!
but - i also would like to underscore this with another idea: "lead
by example" (which is why i've kept the large cross-distro list) we -
the free software community - are seeing tons of nice lovely android
tablets, tons of nice lovely expensive bits of big iron and/or x86
laptops, and only in very small areas (OpenRD Ultimate, GuruPlug,
Pandaboard, IMX53QSB, Origen) are our needs for actual hardware which
_we_ want (and i'm *not* being presumptious here - i'm inviting people
to *say* what they want) just aren't being met.
who wants a bloody 800x600 VIA VunnnderMedia ARM9 350mhz tablet, to
do linux kernel and gnu/linux distribution development on, _anyway_???
and who the hell wants only 512mb of RAM (iMX51). and who in their
right fucking mind dreamed up that 1024x600 LCD panel size?
so here's what i propose:
we, The Free Software Community, want Our Figureheads (linus, bruce,
alan, russell) to call us to arms (so to speak), to band together a la
KickStarter http://kickstarter.org (or other), so that we can create
the hardware platform(s) that *we* want, and, in the process, can take
the opportunity to sort out the Linux Kernel mainline tree in the
process (learning by doing, doing by leading, leading by example etc.
apart from anything - and this goes to you, linus and russell - i
think that you would be much happier taking a break from doing git
patch conflict management, _actually_ getting down and dirty with some
real device driver writing, and i think you'd be much happier doing
that knowing that the device you were writing those kernel drivers for
was something that actual real free software developers really really
now, as i said above: i don't _dare_ to presume that i know what
actual real free software developers want, in terms of hardware, but
there's a small sampling on the debian-arm mailing list... let me drop
you roughly in the middle of it, here:
http://lists.debian.org/debian-arm/2011/08/msg00045.html mostly that
was focussed around those little engineering boards (panda, IMX53QSB,
origen etc.) but my aim here is to get people to think:
what hardware, which is fully free-software-compliant, that you would
buy and recommend to others, that could also be attractive in
mass-volume, do _you_ want to see, that would be useful to _you_?
i'm getting fed up of seeing stuff come out of factories that's
completely useless. or gpl-violating. and/or requires
as a free software developer, what hardware do YOU want?
answers on this one to arm-netbooks(a)lists.phcomp.co.uk (subscription
required, please remember)
and, lastly - linus, russell, alan, bruce: there are people out there
who would really appreciate if you could take up this call. not just
me. we'd like to see you using your skills, and actually be happy and
enjoy doing nitty-gritty linux kernel development, to the benefit of
the free software community, instead of turning into patch