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!
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.
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/126.96.36.199_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...
quick update as I know things are waiting on this..
gcc-4.6.1 bootstrap built ok (with java as usual, without cloog due to
then built libtool-2.4-6.fc15 which goes along with it
then built cloog
So far so good.
Now rebuilding the real, unmodified gcc-4.6.1 from f15 mainline.
Should be done in 2-3 days.
Then we will be good to continue with building the rest of the toolchain.
Based on an internal mirror of the various repositories (i.e. it might
be slightly out of date), I wrote a script to compare the SRPMs
(diff'ing the contents) generated during stage4 with SRPMs from other
sources (mostly, F15 official ones, but also from SRPMs still in the
builder queues). Color coded with diffs and stats:
99 SRPMs are of the .0.armN variety (only 5 I couldn't find the
upstream to diff against)
3 SRPMs in stage 4 have the same NVR as GA/updates BUT DIFFER IN
CONTENT (glibc and gdesklets vs GA, crash has changelog diffs vs
5 SRPMs match rawhide
11 SRPMs show up in the builder queues ("others") but not upstream
0 SRPMs that show up in the builder queues differ in content
30 SRPMs I couldn't find outside stage4 (might be from an older
4704 SRPMs match GA or updates (name and content match)
Note: the HTML file is about 1 MB
Hi people, before all sorry for my bad english, I am latinoamerican
Ambassador, especifically in Venezuelan, I have a smartphone Huawei, Model
UM840. Actually is smartphone leader in Movilnet Carrier.
My idea is: Run Fedora in um840 to promote Fedora in my country.
um840 use a ARM11 Family processor, Qualcomm 7200A at 528Mhz with 198mb RAM.
The phone have Android OS (2.1).
if Android is based in Linux Kernel, then I think in port Fedora Linux to
but I have two problems.
1) I don't know a bootloader to dual boot (Android + Fedora)
2) I don't know How to port Fedora 12 Arm in readable binary image for
Again, sorry for my bad english & thanks.
Kellerman Rivero (kelito)
I've been trying to contribute to F15 efforts but have been a bit lost
as to what needs doing and what direction things are going in.
Dennis and Chris kindly explained the plan so I've tried to document this here:
Comments/additions welcome of course.
I have requested that the platform "arm" be created in Bugzilla after
discussing this with David last week. We can use it as a catch-all to
reduce the confusion as some users don't know armv7 from arm9 or arm11!
We can of course add others, but I like "arm" to be in there.