ARM CPU support (It actually works, with some minor source tweaks)

[Mike Kasprzak]

Allright, admittedly this a bit crazy on my part, but here we are.

Some background: I stumbled across a web host Scaleway that makes and rents inexpensive ARM based dedicated servers (£3/mo each). Really, they're a pretty amazing bargain (Quad Core, 2 GB RAM, 50 GB SSD), but seeing how most software is written for Intel CPUs, it's hard to know what will work on them.

After a bit of work, and surprisingly few source changes, I was able to get the latest beta of OpenLiteSpeed (1.4.11) running on one of these cheap ARM servers with Ubuntu. Everything except PHP, which turns out is an x86 binary that's bundled with OpenLiteSpeed (oops). I'm in the process of building PHP manually (I stole the litespeed php install script from a working install). So far it looks encouraging, but it's taking a long time to build (not sure if Make's job mode (-j number_of_threads) is being used or not).

To get OpenLiteSpeed working on ARM I had to modify 2 files: "configure.am" and "include/lsr/ls_atomic.h"

In "configure.am", there's a section that checks if the CPU is an x86_64 chip, and sets the architecture to i686 (i.e. -march=i686). I merely changed two mentions of i686 to armv7 (i.e. -march=armv7). Ideally, the code should include new checks for ARM architectures, or the GCC docs say you can just use 'native' (assuming it's Linux). You'll also want to define USE_GCC_ATOMIC.

With that change, I had to rebuild the configure scripts before running configure (i.e. with autoconf and libtool installed, automake --add-missing; autoreconf).

In "include/lsr/ls_atomic.h", I forced it to use the USE_GCC_ATOMIC path by uncommenting the convenient "#define USE_GCC_ATOMIC" that was sitting there. Then after that, I modified 3 instances of "#if defined( __i386__ )" to also include the ARM architecture. Two of them were part of the ls_atom_xptr_t union, and the other was inside the USE_GCC_ATOMIC block.

#if defined( __i386__ ) || defined( __arm__ )

And that's actually it. Make it (make -j 4), install it (sudo make install), set the admin password, start the service, and you're laughing.

Well, laughing with everything but PHP working (needed by the control panel).

Anyway, that's my notes. It would be nice to see this officially added to the source code. I suspect you could get OpenLiteSpeed running on a Raspberry Pi in much the same way, though a quick Googling suggests that the older Pi's have an ARMv6 CPU (with a VFP2 FPU) and not an ARMv7.

Regards,

Mike Kasprzak

[Mike Kasprzak]

Okay, since it finally finished, I just wanted to share that I was able to successfully build and install PHP (PHP 7 RC 4). And after tweaking the config files, I was able to run the example PHP page and the Control Panel just fine. All on a web-server featuring an ARM CPU. :)

[Kevin Fwu]

Hi Mike,

Wow!  Nice work there!  Do you have a patch of your changes?  We'll look to add that in for the upcoming version if we can squeeze it in in time.

That said, we have a bunch of changes coming in for 1.4.12, so there may be a few conflicts with the ARM architecture that we are unaware of.  

We are definitely willing to add the new lines in to try it out though!

Cheers,

Kevin

[Mike Kasprzak]

Ha, all right fine, I've put together patch for the just released version 1.4.12 (see attachment).

I did testing on other ARM devices today. I tried out 3 boards in addition my remote Scaleway server (ARMv7): An old original Raspberry Pi (ARMv6), a Beaglebone Black (ARMv7), and a Parallella Microserver (ARMv7). I don't have a Raspberry Pi 2, but those have ARMv7 CPUs, and *should* work fine.

Generally speaking, it's only really worth supporting ARMv7 and eventually ARMv8 (64bit ARM), but I did include original Raspberry Pi support (ARMv6, Hard Float, VFP) since they are so widely available.

Requirements:

- Device with an ARMv7 CPU (or Raspberry Pi's ARMv6)

- GCC 4.8+ (i.e. Ubuntu 14+, Debian 8+ (Jessie), Raspbian Jessie+)

This will not work with Debian Wheezy (7.x), Ubuntu 12, or their derivatives (Raspbian Wheezy), as these ship with older 4.6 series GCC's. The GCC Atomics for ARM weren't complete in earlier versions of GCC.

Other Notes:

- PHP pages like Example/html/phpinfo.php and the Server Config on Port 7080 will fail, as OpenLiteSpeed ships with an x86 binary. If you build a native PHP, and update your configuration, it will work.

- When applying the patch, you'll need to rebuild the configure scripts. Something like "aclocal && automake --add-missing && autoconf". And of course, you'll need autoconf and libtool packages to do this.

Raspberry Pi Notes (old Raspberry Pi, not the Pi 2):

- Be prepared to wait a long time for it to finish. Maybe an hour.

- Follow typical Debian install instructions on the Raspberry Pi.

- "sudo service lsws start" may not work, but after a reboot the server should be running on port 8088.

I think that covers about everything.

[oyang]

Really  good  news.

But  I had  tried  online  arm  server  before,,  it  very very weak.

[Mike Kasprzak]

That's why I really only suggest running a server with an ARMv7 chip in it. I have an old Synology NAS with an ARMv5, 128 MB of RAM, that I used to run a DokuWiki and Apache on. Oh man, it was outrageously slow. Barely usably by 1 user (me). The ARMs of today are nice because not only are they more comparable with low end Intel's, they come with many cores, for very little cost. There's a reason (nearly) all phones run ARM chips. Even NVidia's latest Tegra chip the K1 is faster than the last generation of game consoles. ARMs have improved dramatically the past several years. If you're running VPSs, ARM servers are in the same ballpark. So IMO that's interesting. :)

[Mike Kasprzak]

And one piece of advice on ARM: "make -j X" is your friend. ARM Chips aren't necessarily as fast as Intel's, but you make up for it with more cores. Any time you have to compile something on an ARM, especially when it's an autoconf build (./configure; make; sudo make install), be sure to include a -j with your "make" to specify how many threads/jobs to create, because otherwise GNU Make will compile using only a single thread.

[David]

Hi Mike,

Thanks for your great news and your patch.
I already applied your patch for the next release and hope at that time you will find it more easier.
But right now, it is not easy to create such a test environment to test ARM and I did not do a test of it.

Thanks.
David

--
You received this message because you are subscribed to the Google Groups "OpenLiteSpeed Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlitespeed-deve...@googlegroups.com.
To post to this group, send email to openlitespee...@googlegroups.com.
Visit this group at http://groups.google.com/group/openlitespeed-development.
For more options, visit https://groups.google.com/d/optout.

[Mike Kasprzak]

Cool. Thanks for letting me know.

The easiest way to try it out would be to spin up a €3 server at scaleway.com, and install Ubuntu 14 or Debian 8 on it. I'm not a Centos/Fedora user, so I wouldn't know what minimum to recommend there. The key is that it should be an OS that ships with a modern GCC (i.e. 4.8+). You can do a 'gcc -v' to check your version.

The less easy would be to get your hands on a Raspberry Pi 2, and an 8 GB+ MicroSD card. Grab the latest Raspbian from the Raspberry Pi website (based on Debian Jessie, Wheezy will not work). Write that to your memory card, pop it in to the Pi, and you're good. Again, I'm recommending the Raspberry Pi 2. The older Pi is very slow.

And don't forget to use "make -j 4" instead of just "make" in your "configure;make;sudo make install" routine (assuming it's a quad-core ARM chip). That will save a lot of time.