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...

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/nas7820http://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...

Folks,
We are hosting another one of our regular Fedora 15 hardfp Virtual
Fedora Activity Day today Friday July 15th, at 14:00UTC (10:00 Eastern
Daylight Time). The purpose of this session is to co-ordinate the
bootstrap of F15 hardfp (hardware floating point).
Last week, we succeeded in reaching a point where we had yum running
natively, and after that rapidly went from just under 100 native binary
RPMs built to 793 right now! We still do not have all of the
dependencies for mock, but we hope to be there soon. We need your help,
if you have the time, hardware, and interest in doing so. Together, we
can reach a point of running mock, then rebuild all of the packages we
have so far natively within a mock, and ultimately have a Koji buildroot
sufficient to officially rebuild everything within the standard Fedora
ARM Koji infrastructure.
You can find a lot more detail here about the stages involved in bringup
(we are at stage 3), along with all the pre-reqs/bits:
https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstra...
For general bootstrapping series information:
https://fedoraproject.org/wiki/Architectures/ARM/Fedora15_HardFP_Bootstrap
Be sure you follow the instructions to use an armv7hl-YOUR_FAS_USERNAME
or group name branch on the Fedora ARM git repo so that we can track who
is doing what, and more easily back out changes if you/we discover a
problem with your setup.
Jon.

Compiling the packages is not a problem as i am compiling a load of f14 and f15 packages now.
Chris Tyler <chris(a)tylers.info> wrote:
>On Sun, 2011-07-31 at 01:32 -0400, Donald Gullett wrote:
>> Can anyone point me in the direction of information on building a centos rootfs?
>
>You'd have to compile a substantial portion of the CentOS package
>collection for ARM, then create a rootfs based on that.
>
>> How was the fedora rootfs setup derived? Was it a posted redhat
>> document or procedure or an existing fedora installed system?
>
>It's a hackish script that runs against the ARM package repo. A
>kickstart-based solution will get written in due course, I'm sure.
>
>-Chris
>
>_______________________________________________
>arm mailing list
>arm(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/arm
>

Dennis,
I suspect I just need a few hours doing something else (like sleeping), but I hit a small bump configuring mock.
I can see that you use several repos - including on i386 for group deps (cool). However, my mock refuses to recognize the Scotland armv7hl repo. I will look at it in a few hours, should be easy to fix but just annoying. If you have something I don't, like a patch to mock, let me know.
Jon.
--
Sent from my phone - message formatted and/or shortened accordingly.

Can anyone point me in the direction of information on building a centos rootfs?
How was the fedora rootfs setup derived? Was it a posted redhat document or procedure or an existing fedora installed system?