LWN.net Logo

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Eric Lai takes a look at a palm-sized Linux server. "It comes installed with Plat'Home's own embedded SSD/Linux distribution by default, though customers can also request others such as Debian, Ubuntu, Fedora, Java SE for Embedded and NetBSD."
(Log in to post comments)

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 2, 2009 18:15 UTC (Fri) by drag (subscriber, #31333) [Link]

I was taking a look at OpenRD personally.

open-rd.org

7 USB ports. USB client. Serial. VGA. Dual gigabit ethernet. SD card. eSata. 1.2ghz Marvell ARM processor, 512MB RAM, 512MB flash.

$150 without enclosure, 250 with.

Very very cool stuff.

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 2, 2009 19:32 UTC (Fri) by branden (subscriber, #7029) [Link]

Their site appears to be timing out. :(

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 2, 2009 19:48 UTC (Fri) by flewellyn (subscriber, #5047) [Link]

I had no such issues. Might be local network trouble in your area or something.

Had a look at the specs of that OpenRD thing. It does indeed look very nifty. Probably not much use without an attached eSATA drive, other than as maybe a router/firewall; they recommend using the onboard 512mb NAND flash drive only as a boot device, or maybe boot/root, which means you'd need external disk to do anything that required file I/O. Not a very onerous requirement, though, disk is cheap these days.

Could be a very nice little server, as long as you don't need too much CPU.

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 3, 2009 2:20 UTC (Sat) by drag (subscriber, #31333) [Link]

It should be on par in performance to a 800mhz P3 or a Atom processor; just as long as you don't need any floating point performance which is software-only.

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 2, 2009 18:58 UTC (Fri) by NightMonkey (subscriber, #23051) [Link]

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 2, 2009 23:02 UTC (Fri) by russell (subscriber, #10458) [Link]

Still think the Sheevaplug looks more interesting at about $100US

http://en.wikipedia.org/wiki/SheevaPlug

The OpenBlockS 600 is a Linux server that fits in your palm (ComputerWorld)

Posted Oct 3, 2009 1:36 UTC (Sat) by drag (subscriber, #31333) [Link]

Openrd is about the same thing, just with a lot more I/O options. Both are cool.

The biggest problem with ARM is its lack of system architecture

Posted Oct 3, 2009 19:18 UTC (Sat) by zaitcev (guest, #761) [Link]

If you buy an Atom or Geode barebones, it's guaranteed to boot a normal Fedora or Ubuntu. If you buy ARM, you're a hostage of vendor support. If that fails (which is the default), you're all alone in the bizarre maze of incompatible bootloaders and out-of-tree patches which quickly become obsolete. Until ARM comes up with a full computer instead of just a CPU, it's no contender in Linux server space. Instead, the vicious cycle of "make a product, patch something to boot on it, ship it, forget about it immediately" will continue forever, with publications hyping up the next wonderful widget and the platform going nowhere.

The biggest problem with ARM is its lack of system architecture

Posted Oct 4, 2009 6:04 UTC (Sun) by tzafrir (subscriber, #11501) [Link]

That depends which board.

The above-mentioned SheevaPlug and OpenRD are quite well supported. I have my plug running Debian Stable with merely a newer kernel (which is what you would expect from new hardware).

The Company behind OpenBricks seem to have had the same product for quite a few years now (and anyway, it's a PowerPC and not an ARM).

So if you have a board that is well supported in upstream kernel and does not require a very specific kernel, you can bet it will remain supported for quite a while (as long as it has enough users).

The biggest problem with ARM is its lack of system architecture

Posted Oct 4, 2009 17:26 UTC (Sun) by zooko (subscriber, #2589) [Link]

I don't know, I see lots of successful installs of normal distributions on ARM systems, including OpenMoko, Beagleboard, PogoPlug, and QNAP TS-109 NAS.

The biggest problem with ARM is its lack of system architecture

Posted Oct 5, 2009 1:15 UTC (Mon) by drag (subscriber, #31333) [Link]

Yes.

With the ARM system the bootloader is as critical as the kernel.

There is no BIOS or standard addresses for locating hardware. It is up to the bootloader to 'bring the hardware up' from a unknown state to a working state.

This means your doing things like:

* Set CPU voltage
* Set CPU speed
* Configure MMU
* Configure memory banks
* Configure onboard flash

etc. etc.

That's right.. at boot-up the system is not even able to use main memory. It just starts executing code at a certain address. Usually you require some hand-created assembly at 0x0 on the onboard flash and that is were you start to bootstrap the system.

Of course this is a plus and a negative. The plus is that you have no bios to deal with. The minus is that each board needs to have a specially configured bootloader and if the vendor supplies a closed source bootloader then this can be a very difficult situation for end users to deal with.

---------------------------

I don't know about the OpenRD or any board specifically.

But for a example this is how things work if you want to have FULL control over the hardware and be able to replace all the firmware on the device.

If you want to have 'full freedom' over a ARM board you need:

1. You need to have JTAG access, or the onboard flash is removable and you have a compatible programmer.

This is not as scary or expensive as it may seem. The difficult part is often locating the JTAG pins on the hardware. If the manufacturer is friendly then this shouldn't be a problem.

A jtag programmer can be a sophisticated and pretty expensive things. For the ARM everything is more-or-less standardized and you do not need a 3-30k programmer like you do for the PowerPC platform.

A reliable jtag programmer can be as cheap as taking a parrallal port and stuffing a 100 ohm resister 4 wires... on the 3 output pins and 1 input pins. Wikipedia has enough information to figure this out... Since this is 'unbuffered' design then you have to have very short cables (under six inches) to avoid voltage problems. The OpenWRT wiki on information how to make these things.. I use this cheap design quite successfully. I also have a more expensive USB jtag interface, but both work quite well.. the difference is that the USB stuff is a bit faster.

http://wiki.openwrt.org/oldwiki/openwrtdocs/customizing/h...

ARM standard jtag has 20 pins. A older standard has 14 pin connections. Most of those pins are luxury items... the only pins you need to care about are:
* TMS --- state logic
* TDI --- input
* TDO --- output
* Ground

My USB device requires VCC to keep things balanced. (typically 3.3v)

This sounds more scary then it really is.

If the manufacturer did it's job then programs like OpenOCD or Urjtag should already have example configurations and programming support so you don't have to do anything.

This is what is necesary if you want to get into programming things and keeping things completely open. Because it gives you the ability to recover from a bad bootloader and perform boot-up debugging and whatnot.

2. Linux drivers in the vanilla kernel, or at least a patchset.

3. Open source bootloader support, preferably in u-boot or redboot.

Now Redboot is from Redhat. I don't know much about it personally. But the interesting part is that it's based on a open source embedded real-time "operating system" called eCos.

U-boot I am more familiar with and it was originally designed for embedded PowerPC stuff, but now supports multiple architecture.

Now like I said if you have proper open source support then you have the source code for both the kernel and for the bootloader.

With U-boot this is a paraphrased example of how to build a loader and kernel:

A. Install a cross-platform toolkit. Debian makes this easy due to the emdebian project, but there are lots of them from all over the place. The deal to remember is that different ARM platforms have different ISA compatibility. Depending on the CPU it may support a different set of ARM instructions or have hardware floating point or MMX or whatever. The Debian armel is software-fpu and uses the 'enhanced abi' which should work on most newer ARM stuff quite well.

> echo "deb http://www.emdebian.org/debian/ lenny main" > /etc/apt/sources.list.d/emdebian.list

> apt-get update

> apt-get install libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

> export ARCH=arm
for the kernel sources makefiles to use

> export CROSS_COMPILE=arm-linux-gnueabi-

the commands for cross compiler stuff from emdebian are things like arm-linux-gnueabi-gcc, arm-linux-gnueabi-objdump, etc etc. Makefiles should support this, ideally.

> <use git to grab u-boot and patch things how you need it for your board>

> <use git to grab kernel sources and patch things how you need it>

> cd u-boot-<version>

> make mrproper

> make boardname_config

> make

> cd ..

> export PATH=$PATH:/path/to/u-boot/tools/
# this is fhe kernel makefile to use u-boot to automatically build the image for your flash

> cd linux-<version>

> make mrproper

> make boardname_dconfig

> make menuconfig
if you want to customize it

> make uImage

And that should be that. If your board is properly supported and the manufacturer has done its job then you should get a uimage.bin file.

This file is the bootloader+linux kernel properly memory aligned and all that happy stuff.

Then you can use your jtag programmer to dump that down onto the onboard flash.

Like with urjtag (with good support for your platform)

> jtag
launch jtag command from urjtag

> cable DLC5 parallel 0x378
configure jtag cable

> detect
smartly detect platform

> init pxa27x
initialize a system bus

> print
print configuration information

> detectflash 0x0
attempt to detect flash mapped to address 0x0. This is platform/board specific

> flashmem 0x0 uimage.bin
start programming starting at address 0x0.

======================

And that is about it. All of the above is VERY specific to each board and each platform. Most of the time jtag access is actually undesirable.. it's slow and troublesome and common bootloaders have the ability to upgrade the bootloader and configuration stuff themselves. You only want to use jtag if you want to have 100% control over what is on the flash and to recover bricked hardware.

As you see things are much more complex then just running a grub install script to copy the first stage bootloader to the beginning of the MBR....

So depending on the quality of the manufacturer and how friendly they are things can range from MUCH MUCH more open then a PC platform to a shitload more difficult and closed then a PC platform.

The biggest thing to remember is that everything is board-specific. It's CPU-specific to be sure, but there is no standardization and things are different from board to board and need board-specific kernel configurations and bootloader configurations. Things need to be properly memory aligned and all that happy stuff.

I don't understand it all.

------------------------------

Oh, and for people desiring a completely open platform your best bet is looking for a custom ARM board. You get the benefits of high-volumes chips and devices like for x86, but the cost of developing the board and stuff is cheaper, tools are cheap and easy to create/find, no bios to deal with, no legacy Windows-compatibility requirements or dictated "standards" like ACPI to deal with.

For the price of a sports car you should be able to contract a experienced board design and manufacturing company to produce the board you want based on a chipset reference platform with full source code and schematics for everything and the per-unit costs should be competitive with higher quality PC stuff.

The biggest problem with ARM is its lack of system architecture

Posted Oct 5, 2009 1:18 UTC (Mon) by drag (subscriber, #31333) [Link]

Oh and I haven't looked at the OMAP Beagleboard, Gumstix, or Marvel's sheeva reference systems (the sheevaplug and openrd) to see just exactly how 'open' they are. But having the bootloader code and low-level initialization stuff means that you have much more control over it then what is normally possible with a x86 system.

Bigger PITA, to be sure.. but nothing is free, right?

The biggest problem with ARM is its lack of system architecture

Posted Oct 5, 2009 13:47 UTC (Mon) by SimonKagstrom (subscriber, #49801) [Link]

All you need for JTAG access on OpenRD is actually a USB cable, so it's very hackable and nice in that regard (I believe the same goes for sheevaplug). U-boot is also started from RAM (loaded by a boot ROM from NAND, serial port, ...), which is very nice when hacking on U-boot - no need to reflash it to NAND each time you make some change.

I can therefore definately recommend the Marvell Kirkwood-based boards, and pretty much full support for them should be upstream in both U-boot and Linux very soon now (and already is for Sheevaplug).

The biggest problem with ARM is its lack of system architecture

Posted Oct 6, 2009 8:05 UTC (Tue) by oak (guest, #2786) [Link]

Great comment, thanks!

> The biggest thing to remember is that everything is board-specific.
...
> I don't understand it all.

ARM does only IP and the companies licensing it compete pretty fiercely.
The ways in which these licensees differentiate are features and price,
not board compatibility. As the target is more HW oriented customers with
high volumes, price means also doing away with extra stuff.

However, I think this is going to change in the higher embedded space
where CPUs have now more power than desktop PCs 10 years ago...

Intel is starting its descent onto that, now on its own terms (Atom and
future x86 legacy compatible designs) after the failed XScale attempt.
ARM is starting to try compete with SMP and other ways to increase
performance without sacrificing power efficiency too much.

If Intel doesn't get its power management on reasonable level or ARM
doesn't get its SMP stuff working & supported properly, we know which one
is more likely to win. If both succeed in these, I think ARM's only
chance in this space is very good Linux support and better compatibility
between different ARM boards.

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds