[fedora-arm] Pogoplug Pro/OXNAS

Callum Lerwick seg at haxxed.com
Sat Jul 9 21:58:37 UTC 2011

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
/etc/sysconfig/modules/oxnas-gmac.modules :

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

More information about the arm mailing list