Category Archives: ARM
The sincerest form of flattery
Intel looks ever more like someone whose birthright is slipping away. While it continues to dominate both its core PC market and the server market it usurped from an earlier generation of distinct top-end hardware, this is no longer where interesting growth is happening. In the mobile space – where power consumption means a tradeoff between battery life and weight that people really notice – it sounds ever more shrill and desperate. Otellini & co: we ARE relevant!!! Rest of world: shrug. Even the best friends are slipping away: long-term partner Microsoft openly double-timing them; a year-long fling with a rudderless Nokia going nowhere exciting.
But are they actively paying tribute to their own nemesis? It sure looks like it! They’re naming their efforts to compete in the lower-power-consumption market from ARM’s family history. First came Atom: Intel’s low-power processor range named after the Acorn computer of the early 1980s. And now Oak Trail, the latest, lowest-power-consumption processor in the Atom range.
To paraphrase Oscar Wilde, to name one product after your competitor might be considered a misfortune. To name two looks like carelessness!
————————–
For the benefit of non-techie or too-young-to-remember readers, ARM, which dominates the mobile processor market, was originally a spinoff from Acorn Computer, so might be considered an Oak. Atom was an early personal computer made by Acorn, superseded by the BBC Micro and the Electron. Those early Acorn computers were powered by processors from Intel’s then-biggest but long-since-vanquished rival Motorola.
TrafficServer on ARM
I’ve returned to my slightly unusual hacking activity to build Apache TrafficServer on the Maemo (ARM linux) platform.
It’s a slow process, partly because of the slow platform (NFS-mounted disc for everything, just the processor from the phone) and the very large C++ code (which g++ builds slowly on any platform), but also crucially because of the number of fixes that only become apparent when the build trips up. The worst cases have been where a header file has to be fixed: there are no explicit dependencies in the Makefiles, so it implies a huge amount of largely-unnecessary recompilation.
When I started on this, zwoop told me it was never going to be much of a performer on ARM, because it relies on 64-bit Intel-only atomics that have to be emulated at a heavy cost on ARM. I found the atomics were not emulated, and their absence caused a link error. Emulation code appears to be written, but evidently the build scripts incorrectly detected maemo as having the Intel atomics. Oops!
Other fixes that have proved necessary:
- char on ARM appears to be unsigned, so I had to substitute bitwise tests for sign tests, and typecast values like EOF in comparisons.
- The build scripts failed to fix up my library path when I used –with-foo configure options. Specifically a –with-tcl option, as maemo’s Tcl package is missing tclconfig (required by trafficserver) so I had had to build a separate Tcl from source.
Not too much really: the atomics are the most complex hack. But I fear this exercise is of purely academic interest, if the atomics prove to be a show-stopper for decent performance on ARM.
Bug me if I drop the ball on documenting this exercise in three bug reports!
ARM in the server
I’ve done a fair bit more hacking on ARM lately. This is entirely for my own satisfaction, but it’s good to see that a great deal of server software ports cleanly to it with very little effort.
In the absence of an ARM-powered desktop (or laptop) box, my dev platform is the pocket-puter, but driving it from the desktop monitor, keyboard and mouse for comfort. Now I’ve added to that a regular desktop disc, rather than do builds in/on solid-state storage. The disc is actually a 2GB file formatted with an XFS filesystem, mounted as a loop device and exported to the phone with NFS. The NFS, being run behind a firewall and for a single client under my control, is optimised for speed over integrity and security, including running it async and with nolock on the Nokia client.
Seeded with gcc/g++, this is now a sustainable development platform on which I can build pretty-much anything at the application level, even where packages are not available. In some ways it’d a little like going back to Linux of yesteryear: a great system but with relatively few out-of-the-box packages. For example, the available Tcl package on maemo is missing Tcl-dev, so I had to build that from source before I could build Apache TrafficServer (that’s a sharp contrast to TrafficServer on OpenSolaris, where porting was non-trivial but didn’t require me to build its prerequisites from source)!
I don’t expect ARM to topple Intel’s crown in the server realm, but I’m sure it’s capable of driving a lot of server applications, and the power saving should make that worthwhile for a lot of users! It should be nicely suited to “cloud” applications based on large numbers of small nodes. And basic ‘net applications like web and mail servers. Why are so few of us working on these? Is this a good niche to be getting into?
The webserver on a ‘phone
Yesterday I successfully built Apache APR and HTTPD (the webserver) on my pocket-‘puter, a Nokia N900, also known as a smartphone.
The prerequisite to that was to install a development environment. I wanted something native running on maemo, and while the tools don’t run entirely smoothly (apt-get fails to find many of the packages), a bit of googling found me ossguy’s page leading to the necessary packages and repositories to set up a working GNU toolchain.
Having installed gcc and a couple of other packages from the repos, building APR, APR-util and HTTPD went mostly smoothly. For the record (and I may update this post when I’ve figured out more about it):
- Configure’s detection of grep and egrep fails, despite both utilities being available in standard places and working fine. This may be an artifact of the GNU-toolchain-derived configure script’s syntax failing with the “ash” shell. As a workaround I removed the broken detection and replaced in each configure script with
GREP=grep
EGREP=egrep - There were a number of assembler warnings. To be investigated.
- APR-UTIL failed the xlate test. This may mean that iconv is not available but APR_HAVE_ICONV is incorrectly detected/set. I recollect a similar issue with OpenSolaris, and I suspect a bug in the configure/build scripts.
- A few extra prerequisites were required, like zlib-dev for mod_deflate.
All in all, remarkably straightforward, and I was much surprised to see only the one failure from the test suite. The webserver is up and running, and in future I expect to treat it the same as any other dev-platform server.
Furthermore, if it’s that easy on Maemo, I’d expect it to be similarly straightforward on other ARM/Linux platforms such as Android.
niq's soapbox 