[SERVER-1811] ARM support Created: 19/Sep/10  Updated: 09/Aug/18  Resolved: 23/Aug/16

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: 3.3.11

Type: Improvement Priority: Major - P3
Reporter: Jonne Hass Assignee: Brian McCarthy
Resolution: Fixed Votes: 93
Labels: None

Debian Squeeze, 2.6.32-5-kirkwood, Sheevaplug, ARMv5

Attachments: File armdoubles.diff     File mongi.diff     File mongoarm.diff    
Issue Links:
depends on SERVER-19502 Generate ARM64 configurations for Spi... Closed
depends on SERVER-14852 Create endian- and alignment-agnostic... Closed
depends on SERVER-14853 Port networking library to AAE read/w... Closed
depends on WT-2013 Add support for ARM64 memory barriers... Closed
is depended on by SERVER-10294 Server not starting Closed
is documented by DOCS-9567 Docs for SERVER-1811: ARM support Closed
is duplicated by SERVER-14619 Cannot build on armv6l architecture (... Closed
is duplicated by SERVER-18166 Running Mongodb on Yocto (arm v7) Closed
related to SERVER-12065 "unknown platform" error when buildin... Closed
is related to SERVER-12283 Use gcc atomic builtins if available ... Closed
is related to SERVER-23555 Add aarch64 Enterprise and Community ... Closed
Backwards Compatibility: Fully Compatible
Epic Link: ARM64 Support
Sprint: Build 17 (07/15/16), Build 18 (08/05/16), Build 2016-08-26


Since the upcoming social network Diaspora* uses mongodb as backend it would be nice to have it running on little home servers such as the Sheevaplug. As such servers are often based on ARM-architecture mongodb needs support for this.

Comment by artisan kloschi [ 12/Oct/10 ]

I second this request. Would be great to use mongoDB on all that arm based mini plattforms, as sheeva, dockstar .. whatever kirkwood

Comment by joshg [ 16/Oct/10 ]

I too can express great interest in getting this feature added. I've tried installing mongoDB on my armv7 powered N900, would be great to get it working.

Comment by re pat [ 16/Oct/10 ]

I'd like to second that as well. I had a look at the code and got it compiled until it comes to atomic integers: http://repat.de/2010/10/diaspora-on-dockstar-with-debian-lenny/

Comment by joshg [ 16/Oct/10 ]

re pat: excellent work documenting all that! I see there's some steps you've taken to trick the compiler, I must give this a try myself. I too, however, have outlined steps I've taken in an attempt to install Disapora on my N900! Link: http://talk.maemo.org/showthread.php?t=63889

Comment by Eliot Horowitz [ 16/Oct/10 ]

Unfortunately compiling is only a small portion of the issue.
The bigger problem is endianness - which is fixable, just a fair amount of work.

Comment by re pat [ 25/Oct/10 ]

The way I understood the sourcecode you could either use ARM ASM Code(for i386 etc) OR(#else if) the bit of code which is only available in gcc >=4.4.0.
I don't really know but I just..randomly guess that "endianness" has something to do with the ASM Code? If this gcc is an ARM specific version, shouldn't that feature be automatic? Like I said, I don't know much about it, correct me if I'm wrong, I just don't want to spend time on reinstalling Squeeze on my dockstar for nothing, but I'd give it a try

Comment by Eliot Horowitz [ 25/Oct/10 ]

Making that compile is a very small pieces of the work to be done.
So its not worth doing that without doing the subsequent massive undertaking

Comment by Philippe May [ 04/Mar/11 ]

I second that. ARM devices are getting very popular everywhere. I'm planning to switch a Python project (Hanji: http://hanji.info/) targeting mobile devices to mongo where it would fit perfectly well, but this is a real stopper and if it's not moving i'll have to drop this idea. So really no one can investigate this issue? I'm using Maemo/N900, Android and Meego are targets too.

Comment by Thomas Krause [ 07/Mar/11 ]


Did you compile with 4.4 or a lower version?


// this is in GCC >= 4.1
AtomicUInt AtomicUInt::operator++()

{ return __sync_add_and_fetch(&x, 1); }


code in bson/util/atomic_int.h should actually compile if using gcc 4.4 without any change to the elif macro. The only ARM-powered device I have currently access to is my Android-Smartphone. Maybe I can give it a try. ARM is said to be little endian per default so it might work.

If there is any more assembler code in mongodb I should be aware of?

Comment by Philippe May [ 07/Mar/11 ]

Interesting. For the N900 the standard gcc is 4.2.1, bad luck. Will try to get or rebuild gcc >= 4.4 .

Comment by Thomas Krause [ 08/Mar/11 ]

Here is a quick status report of my current findings for compiling it under ARM (just in case someone else want's to give it a try as well):

I was able to set up a Debian wheezy installation with qemu emulating a versatile developing board using the instructions at http://geekboy.fr/geek/installing-debian-squeeze-arm-with-qemu-on-a-mac/

I tried compilation on the emulated machine and installed all necessary packages, but since it was incredible slow I now use a cross compile environment based on the default Ubuntu ARM GCC 4.4 cross compiler and scratchbox2 (I had to apply http://maemo.gitorious.org/scratchbox2/scratchbox2/commit/e1ab7c2b9e2be2fc831ea11a3c7a45b71df14028 otherwise the Ubuntu ARM cross compiler does not work properly with scratchbox2, I also copied everything from /usr and /lib from the emulated machine into the cross compile root).

Debian Wheezy has GCC 4.4 which claims support for builtin atomic functions under ARM in their changelog.

Unfortunately both compilers (the Debian native one and the Ubuntu cross) did not define _GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 even if they should have the corresponding system functions. I bypassed this by specifying 'scons -cxx="-D_GCC_HAVE_SYNC_COMPARE_AND_SWAP_4" mongod' as build command.

Currently the mongo-daemon is compiling in my scratchbox2-enviroment and I hope I can report some positive results later.

Comment by dmytty [ 13/Mar/11 ]

A comment was made elsewhere that mangodb should consider involvement with Linaro ( http://www.linario.org/ ). I agree strongly with this suggestion. Mangodb could well become the 'go-to' solution for embedded devices - particularly in the industrial area.

Linaro is the strongly supported team (70+ now, soon 100 full time developers) which is creating a software ecosystem for the ARM market. All of the Linaro software will run on devices such as the Pandaboard with up to date OS's such as Ubuntu 11.04 (currently supporting 10.10).

Projects such as Linario show the rapid growth in the ARM market.

After doing a survey of NoSQL, I was very disappointed to see that MangoDB was not supported on devices such as the pandaboard. In every other respect MangoDB seems perfect - in particular, it has the ad-hoc query support that Redis does not have. I had assumed that C++ mean no problems porting to ARM, and that it was already available, but....

The potential for NoSQL in the embedded space is huge. Matched with Pandaboard + Python, MangoDB would allow for some crazy fast prototyping for low cost (<$200), compact (<mini-ITX), low-power (<5 watt) devices.

How about NoSQL = NoDesktop (Not Only Desktop)? Hope this happens soon...

Comment by janis [ 01/Apr/11 ]

I second that.

i would like to run it on qnap or synology

Comment by dmytty [ 22/Jun/11 ]

Arm v7+ is bi-endian. Should MongoDB be distributed only for newer Arm versions?

Some notes:

Little-endian operating systems:
Linux on x86, x86-64, MIPSEL, Alpha, Itanium, S+core, MN103, CRIS, Blackfin, MicroblazeEL, ARM, M32REL, TILE, SH, XtensaEL and UniCore32
Mac OS X on x86, x86-64
OpenVMS on VAX, Alpha and Itanium
Solaris on x86, x86-64, PowerPC
Tru64 UNIX on Alpha
Windows on x86, x86-64, Alpha, PowerPC, MIPS and Itanium

Big-endian operating systems:
AmigaOS on PowerPC and 680x0
HP-UX on Itanium and PA-RISC
Linux on MIPS, SPARC, PA-RISC, POWER, PowerPC, 680x0, ESA/390, z/Architecture, H8, FR-V, AVR32, Microblaze, ARMEB, M32R, SHEB and Xtensa.
Mac OS on PowerPC and 680x0
Mac OS X on PowerPC
MVS and DOS/VSE on ESA/390, and z/VSE and z/OS on z/Architecture
Solaris on SPARC

Her's some compiler option notes:

Highlights of the compiler option include the following flags:
Generate code for a processor running in little-endian mode. This is the default for all standard configurations.
Generate code for a processor running in big-endian mode; the default is to compile code for a little-endian processor.
This option only applies when generating code for big-endian processors. Generate code for a little-endian word order but a big-endian byte order. That is, a byte order of the form `32107654'. Note: this option should only be used if you require compatibility with code for big-endian ARM processors generated by versions of the compiler prior to 2.8.
This specifies the name of the target ARM processor. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. Permissible names are: `arm2', `arm250', `arm3', `arm6', `arm60', `arm600', `arm610', `arm620', `arm7', `arm7m', `arm7d', `arm7dm', `arm7di', `arm7dmi', `arm70', `arm700', `arm700i', `arm710', `arm710c', `arm7100', `arm7500', `arm7500fe', `arm7tdmi', `arm7tdmi-s', `arm8', `strongarm', `strongarm110', `strongarm1100', `arm8', `arm810', `arm9', `arm9e', `arm920', `arm920t', `arm922t', `arm946e-s', `arm966e-s', `arm968e-s', `arm926ej-s', `arm940t', `arm9tdmi', `arm10tdmi', `arm1020t', `arm1026ej-s', `arm10e', `arm1020e', `arm1022e', `arm1136j-s', `arm1136jf-s', `mpcore', `mpcorenovfp', `arm1176jz-s', `arm1176jzf-s', `xscale', `iwmmxt', `ep9312'.
This option is very similar to the -mcpu= option, except that instead of specifying the actual target processor type, and hence restricting which instructions can be used, it specifies that GCC should tune the performance of the code as if the target were of the type specified in this option, but still choosing the instructions that it will generate based on the cpu specified by a -mcpu= option. For some ARM implementations better performance can be obtained by using this option.
This specifies the name of the target ARM architecture. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. This option can be used in conjunction with or instead of the -mcpu= option. Permissible names are: `armv2', `armv2a', `armv3', `armv3m', `armv4', `armv4t', `armv5', `armv5t', `armv5te', `armv6', `armv6j', `iwmmxt', `ep9312'.

It seems that TI OMAP processors using the ARM core are little endian. As such, a Symbian, Meego, or Linux build on N900, N9, N8, should be relatively simple. The same holds true for Android or iOS builds on nearly all of the hardware.

Comment by Eliot Horowitz [ 25/Jun/11 ]

Would be great if someone could try on a bi-endian arm box?=

Comment by Dwight Merriman [ 08/Jul/11 ]

couple notes:

Comment by Per Ola Ingvarsson [ 13/Aug/11 ]

It would be nice if someone with real ARM hardware could try this out:

git clone https://github.com/skrabban/mongo-nonx86 +v1.8

Should compile out of the box on debian/armel and detect that armv5 needs special care with the alignment of data. Passes the tests in ./test on qemu, but qemu doesn't implement the alignment traps. Otoh, it also runs on sparc wich is very picky in that aspect.

Comment by Karim Lalani [ 20/Aug/11 ]

@Per Ola Ingvarsson: It works. Tested on Debian Squeeze on Pogoplug which has armv5tel Thanks

Comment by Wilson Júnior [ 23/Aug/11 ]

someone managed to compile for the android?

Comment by Dwight Merriman [ 12/Sep/11 ]

if atomic int is a problem just use a mutex instead. i will try to add that to AtomicUInt class sometime but a lot of other work in queue unfortunately!

something like (pseudocode):

mongo::mutex atomicMutex("atomic");

void inc() {
scoped_lock lk(atomicMutex);

Comment by Per Ola Ingvarsson [ 15/Sep/11 ]

@Dwight Merriman Atomic int is not a problem, it is just the #ifdef that doesn't work. See mongo-nonx86 for a SCons based test.

Changing the test is enough to compile, but differences in char signedness will cause other problems when running. The ones I have found have been fixed in mongo-nonx86.

Comment by Brian Hutchinson [ 23/Feb/12 ]

Hi, I'd like to understand the issues of building MongoDB for ARM. More specifically .... ARM Cortex A8 with gcc 4.6. I guess I don't fully understand the status of MongoDB on ARM.

Comment by Eliot Horowitz [ 23/Feb/12 ]

Its currently not officially supported.

Some bi-endian systems work today, but we don't have good test beds for those.

If people know of configs that are interesting, we would be interested in adding some more build machines.

Comment by Brian Hutchinson [ 23/Feb/12 ]

Well I think this is interesting .... of TI's BeagleBoard variant, there are almost 60K boards floating around now (ARM Cortex A8) and the new BeagleBone (also Cortex A8) is already up to 20K! This doesn't include Panda, Raspberry Pi (the first 10K batch will be released in a week or two) and all the other nice ARM boards out there that could be running MongoDB and exposing it in the embedded space

Comment by AJ ONeal [ 01/Mar/12 ]

I would be willing to send a raspberry pi to you for testing if you need the hardware.

I think raspberry pi will very quickly become the most popular of all the dev boards (unless it's a total flop).

Comment by Jani Monoses [ 01/Mar/12 ]

With this patch the BSON tests called on starting either mongo or mongod pass. They SIGBUS otherwise on ARMv7/Ubuntu due to unaligned access to floating point values.

The explicit signed char fixes another crash later on - char is signed by default on ARM.

I still need to see why the smoketests fail.

Comment by soywiz [ 12/Mar/12 ]

This could be useful:

On my TonidoPlug:

[root@TonidoPlug ~]# gcc -dM -E - < /dev/null | grep ARM
#define _ARMEL_ 1
#define _ARM_ARCH_5T_ 1
#define __ARM_PCS 1
#define _ARM_EABI_ 1

Comment by soywiz [ 12/Mar/12 ]

(Not tested yet). But a patch for the atomic increment could be something like this:

// gcc -dM -E - < /dev/null | grep ARM
// http://lwn.net/Articles/314561/
#elif defined(__ARMEL__) || defined(__ARM_ARCH_5T__) || defined(__ARM_PCS) || defined(__ARM_EABI__)
#define arm_atomic_add_inline(ptr, val) \
     ({ register unsigned int *__ptr asm("r2") = (ptr); \
        register unsigned int __result asm("r1"); \
        asm volatile ( \
            "1: @ atomic_add\n\t" \
            "ldr     r0, [r2]\n\t" \
            "mov     r3, #0xffff0fff\n\t" \
            "add     lr, pc, #4\n\t" \
            "add     r1, r0, %2\n\t" \
            "add     pc, r3, #(0xffff0fc0 - 0xffff0fff)\n\t" \
            "bcc     1b" \
            : "=&r" (__result) \
            : "r" (__ptr), "rIL" (val) \
            : "r0","r3","ip","lr","cc","memory" ); \
        __result; })
    inline void AtomicUInt::zero() { x = 0; } // TODO: this isn't thread safe
    // from boost 1.39 interprocess/detail/atomic.hpp
    inline unsigned atomic_int_helper(volatile unsigned *x, int val) {
        int r = arm_atomic_add_inline(x, val) - val;
        return r;
    AtomicUInt AtomicUInt::operator++() {
        return atomic_int_helper(&x, 1)+1;
    AtomicUInt AtomicUInt::operator++(int) {
        return atomic_int_helper(&x, 1);
    AtomicUInt AtomicUInt::operator--() {
        return atomic_int_helper(&x, -1)-1;
    AtomicUInt AtomicUInt::operator--(int) {
        return atomic_int_helper(&x, -1);
#  error "unsupported compiler or platform"

Comment by soywiz [ 12/Mar/12 ]

I'm not sure why is this happening, but it spits the "unsupported compiler or platform" on tonido-plug arch linux even when it has GCC 4.6.2. I have tried and it has the __sync_fetch_and_add and __sync_add_and_fetch macros.

So maybe it could be replaced to:
#elif defined(_GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) || (defined(sync_add_and_fetch) && defined(_sync_fetch_and_add))


And about the previous patch, this is the right one:

#elif defined(__ARMEL__) || defined(__ARM_ARCH_5T__) || defined(__ARM_PCS) || defined(__ARM_EABI__)
#define arm_atomic_add_inline(ptr, val) \
     ({ register unsigned int *__ptr asm("r2") = (ptr); \
        register unsigned int __result asm("r1"); \
        asm volatile ( \
            "1: @ atomic_add\n\t" \
            "ldr     r0, [r2]\n\t" \
            "mov     r3, #0xffff0fff\n\t" \
            "add     lr, pc, #4\n\t" \
            "add     r1, r0, %2\n\t" \
            "add     pc, r3, #(0xffff0fc0 - 0xffff0fff)\n\t" \
            "bcc     1b" \
            : "=&r" (__result) \
            : "r" (__ptr), "rIL" (val) \
            : "r0","r3","ip","lr","cc","memory" ); \
        __result; })
    inline void AtomicUInt::zero() { x = 0; } // TODO: this isn't thread safe
	#define atomic_int_helper(ptr, val) \
		(arm_atomic_add_inline(ptr, (val)) - (val))
	AtomicUInt AtomicUInt::operator++() {
        return atomic_int_helper((unsigned *)&x, 1)+1;
    AtomicUInt AtomicUInt::operator++(int) {
        return atomic_int_helper((unsigned *)&x, 1);
    AtomicUInt AtomicUInt::operator--() {
        return atomic_int_helper((unsigned *)&x, -1)-1;
    AtomicUInt AtomicUInt::operator--(int) {
        return atomic_int_helper((unsigned *)&x, -1);
#  error "unsupported compiler or platform"

Comment by Brian Hutchinson [ 28/Mar/12 ]

So are you saying that Mongo will run OK compiled for ARMv5 but not ARMv7? The Cortex A8 is binary compatible with both so while not optimal, running with ARMv5 is better than nothing!



Comment by Andy Schwerin [ 28/Mar/12 ]

For the time being, Mongo on the ARM should be considered unsupported and experimental.

Comment by Jani Monoses [ 30/Mar/12 ]

Using this unpolished patch I got the smoketests passing on ARMv7/Ubuntu

1) Intel asm code in spinlocks implementation: do the glibs and gcc atomics not generate optimal code in this case so that the extra pause is needed? Worst case this can be ifdeffed out under _X86_

2)Alignment traps on ARM when accessing doubles: a lot of ugly code to use packed struct instead of direct doubles. I did not even attempt to figure out what a cleaner solution should be, the mongo devs surely have suggestions.

3) The counters which if atomic ints are also generating alignment traps on ARM. There should be a cleaner solution as mentioned here
but I have yet to get around to doing that.

This patch is against the current master branch (2.1)

Comment by Jani Monoses [ 30/Mar/12 ]

BTW, are the pthread splinlocks better than the ones using gcc atomics, as they seem to be picked with higher prio?

Comment by Per Ola Ingvarsson [ 03/Apr/12 ]

Here is a patch to properly detect fetch and add in scons:

diff --git a/SConstruct b/SConstruct
index cb25b64..2db1329 100644
--- a/SConstruct
+++ b/SConstruct
@@ -749,8 +749,24 @@ env.Append( CPPPATH=['$EXTRACPPPATH'],
 # --- check system ---
+def CheckFetchAndAdd( context ):
+    context.Message( 'Checking for __sync_fetch_and_add ...' )
+    res = context.TryLink( """
+          int main()
+          {
+            int x;
+            __sync_fetch_and_add(&x, 1);
+            __sync_add_and_fetch(&x, 1);
+            return 0;
+          }
+""", ".cc" )
+    context.Result( res )
+    return res
 def doConfigure(myenv):
-    conf = Configure(myenv)
+    conf = Configure(myenv, custom_tests = {
+        'CheckFetchAndAdd' : CheckFetchAndAdd,
+        } )
     if 'CheckCXX' in dir( conf ):
         if  not conf.CheckCXX():
@@ -795,6 +811,10 @@ def doConfigure(myenv):
         if not conf.CheckLib("execinfo"):
+    # Look for __sync_add_and_fetch and __sync_fetch_and_add
+    if conf.CheckFetchAndAdd():
+        env.Append( CPPDEFINES = ["HAVE_SYNC_FETCH_AND_ADD"] )
     # 'tcmalloc' needs to be the last library linked. Please, add new libraries before
     # point.
     if has_option("tcmalloc") or has_option("heapcheck"):
diff --git a/src/mongo/bson/util/atomic_int.h b/src/mongo/bson/util/atomic_int.h
index d3c2bb7..70abb78 100644
--- a/src/mongo/bson/util/atomic_int.h
+++ b/src/mongo/bson/util/atomic_int.h
@@ -62,7 +62,7 @@ namespace mongo {
         InterlockedAdd((volatile long *)&x,by);
 # endif
-#elif defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4)
+#elif defined(HAVE_SYNC_FETCH_AND_ADD)
     // this is in GCC >= 4.1
     inline void AtomicUInt::zero() { x = 0; } // TODO: this isn't thread safe - maybe
     AtomicUInt AtomicUInt::operator++() {

Comment by Brian Hutchinson [ 03/Apr/12 ]

OK, I gave up on my idea to cross compile MongoDB for ARM. Sounds like most are native building it so I setup a BeagleBoard xM with headless Ubuntu and have all the required packages installed to start building mongo. Which repo should I clone to have the best success of seeing something run on the ARM? I don't care at this point if it is ARMv5 or ARMv7, I just want to see something run.



Comment by Per Ola Ingvarsson [ 04/Apr/12 ]

@Brian Hutchinson

git clone https://github.com/skrabban/mongo-nonx86 +v1.8

It is version 1.8-someting, but is reported to work.

Comment by Jani Monoses [ 04/Apr/12 ]

I have just uploaded mongo 2.0.4 with ARM support in Ubuntu precise, you can use that on the beagleboard.

Comment by Jani Monoses [ 04/Apr/12 ]

Patch updated against current master, where the atomic counters issue is solved now.

Comment by Jani Monoses [ 06/Apr/12 ]

current master should build and run on armv7/linux at least.

Comment by Jani Monoses [ 11/Apr/12 ]

Would it make sense to backport the 3 git commits that fix ARM support to the 2.0 branch?

Comment by Eric Milkie [ 11/Apr/12 ]

As a rule, we only backport as necessary to fix bugs. Since mongo ARM is experimental, using a development version should be no detriment.

Comment by Jonathan Baldwin [ 16/Apr/12 ]

Does the "mongo-nonx86" project on github actually compile and run on ARM chipsets? I have a plug server with Debian on it that I need to run Mongo on...will it work if I pull v1.8 and compile directly onto the plug?

Comment by Per Ola Ingvarsson [ 17/Apr/12 ]

@Jonathan Baldwin
It will on debian at least, but xulrunner must not be 2.x.

Comment by Kev [ 12/Jun/12 ]

You may want to add the raspberry pi to the environment. Also the debian guys seem to have a working port. How about e.g. ArchLinuxArm?

Comment by Mauricio S Otta [ 14/Jun/12 ]

include me wanting these with my 4 pogo plugs and ArchLinux ARM

Comment by Timothy Turner [ 01/Aug/12 ]

So, has Mongodb 2.x been successfully installed on ARMv5? In my case I am using Raspberry Pi. I added the patch to atomic_int.h and have passed that error however it failed at another point. I am using ArchLinuxArm and I don't mind switching to debian if that is working.


Comment by Timothy Turner [ 19/Aug/12 ]

I was able to to get mongo v2.1.1 installed on the Raspberry Pi Using the help listed here form soywiz. I am working on getting a more stable version installed on the pi v2.0.7. I have been working with Arch Linux Arm. The issues with 2.0.7 have been with boost. Also, I attempted to install v2.2.0 however there was to much inline asm to covert from x86 to arm. I don't know enough about assembly to convert for different architecture types. For ARMv5 in Arch Linux Arm with boost 1.5.0 and mongodb v2.1.1 it was a matter of converting all instances if UTC_TIME to UTC_TIME_ for boost and adding another line of code in to atomic_int.h for asm memory barrier for AtomicUInt::SET function.


Comment by Nipun Batra [ 03/Dec/12 ]

I ran out of space while building MongoDB https://github.com/skrabban/mongo-nonx86 on Plug Computer (Ionics Stratus), which has only 512 MB flash. Can i build it on some other system specifying target as ARM for Plug Computer and then just transfer that to the Plug Computer?

Comment by Matt Thompson [ 08/Apr/13 ]

I've successfully patched MongoDB 2.4.1 with V8 for armv7l (Cortex A15) on a Chromebook running Ubuntu 13.04. I have not done extensive testing nor checked the correctness of the quick patches to the platform specific atomic operations.

git clone -b v2.4.1 https://github.com/wtfuzz/mongo-arm

A binary package is available from: https://s3.amazonaws.com/wtfuzz/mongo-arm/mongodb-linux-armv7l-2.4.1.tgz

Comment by plustek [ 15/Apr/13 ]

@Matt Thompson, when cross compiling the MongoDB 2.4.1 with V8 for armv7-a cortex-a9, I have encountered following problem:

Assembler Message:
selected processor does not support `dmb'

have you encountered any similar issue?


Comment by Yuri Trukhin [ 07/May/13 ]

very need arm version, works in raspberry pi

Comment by HLFH [ 20/Jul/13 ]

Why do you use MongoDB if they don't have ARM support ? Boycott

Comment by Daniel Ward [ 15/Oct/13 ]

This is definitely something I'd like to see introduced.

Comment by Yigit Sapli [ 24/Oct/13 ]

Has anyone tried building and running on Odroids, specifically on odroid-u2's?

Comment by Matthew R Chase [ 20/Nov/13 ]

It's way past time to support ARM.

get on the ball already.

Comment by Pawel Sledzikowski [ 21/Jan/14 ]

@Matt Thompson,

Many thanks for your binary package of MongoDB for arm7l architecture. I'm confirming it appears to be working for me although I haven't done any reasonable testing yet (at least it starts correctly).

Hardware: MK908II with PicUntu 4.5 on board.

On the other hand, I tried to compile your fork from a scratch (source) but no dice. Same thing with other Mongo forks for ARM architecture: https://github.com/skrabban/mongo-nonx86 and https://github.com/RickP/mongopi (although they're working perfectly fine for RaspberryPi hardware - I have tested it).

"AssertionError: Unsupported architecture: armv7l"

Glad to see working MongoDB on ARM processor.

Comment by D'Heure Ben [ 01/Apr/14 ]

Hi guys ...
I'm new here, and I have to run Unifi controller on an Allwinner A20 board (so ARM-cortex-a7 processor) for my internship. I found this topic and the diff files, but I really don't know to which sources I have to apply these diff.

Someone here could help me ?
Every project about mongoDB on ARM I found are at least 2 years old... But I'm expecting to find some patches for a 2.x version of MongoDB.

Thank you with advance

Comment by Olivier [ 02/Apr/14 ]

Looks like this port is in standby, last activity was 3 weeks ago and SERVER-12283 is still unassigned.
Meanwhile, RethinkDB has added ARM support in their last release (cf. http://rethinkdb.com/blog/1.12-release/).
I think it's about time that MongoDB ships an ARM version.

Comment by Eric Milkie [ 02/Apr/14 ]

Olivier, SERVER-12283 is not related to ARM support. Did you mean to say SERVER-12064? That ticket improved MongoDB portability including on ARM platforms.

Comment by Phill Pafford [ 29/Jul/14 ]

How can we get this implemented? There is a growing need for this

Comment by Ivan Kostyuk [ 02/Aug/14 ]

I'm checking for same, trying to build Mongo on Raspberry Pi B+ equipped with ARMv6.
It seems there is fix for the problem but in another repository. The fix is implemented well for Arch Linux.
And it is working.

Comment by Phill Pafford [ 04/Aug/14 ]

would also like a Debian solution as well, thanks!

Comment by Andrew Morrow [ 04/Aug/14 ]

Hi All -

Here is a quick update on the status of ARM support. There are a number of projects under way, but a significant amount of work remains:

  • Removing x86 assumptions so the codebase is processor neutral: We are making incremental progress here. In particular, we have refactored the use of atomic integers in a large subset of the codebase to use portable compiler intrinsics, and we intend to remove the remaining non-portable instances soon. We are also working on a more general portability enhancement that will improve our behavior with respect to endian conversions, alignment restrictions, and C/C++ aliasing rules, which should enhance our portability not just to ARM, but to other non-x86 platforms (see SERVER-6018, CXX-49).
  • JavaScript interpreter support: We vendor in a copy of the v8 JS interpreter, so the set of systems MongoDB supports is necessarily a subset of the systems that v8 supports. The version of v8 that we currently use by default does not support ARM. A newer version, which does support ARM, has been is made available under a build option. However, the new incarnation of memory management in V8 is incompatible with running the javascript interpreter and database engine in the same process. This incompatibility will require a ground-up rewrite of javascript support, including improved support for managing subprocesses. It is a large project, and it is not yet fully scoped.
  • Testing and validation: We do extensive integration and regression testing on many x86 systems (see https://mci.10gen.com). For us to declare ARM an officially supported platform we need to establish and maintain a similar testing infrastructure for ARM systems. We are working with our partners in this space to gain experience with ARM and eventually develop the necessary testing infrastructure.

Until we have completed the above projects, ARM will remain unsupported. However, we are interested in offering MongoDB on ARM, and progress is being made on all of the above projects.


Comment by Glenn Byron [ 06/Jul/15 ]

It has been nearly a year now. Any word on when we will be able to run MongoDB on a Raspberry PI without jumping through hopes. With all the Internet of Things talk I'm surprised this has not become a higher priority. A Mean stack on a Raspberry PI seems like a great solution.

Comment by Sergii Puliaiev [ 14/Jul/15 ]

I would like to have the support of not only Raspberry - but some NAS servers as well - for example Netgear ReadyNAS 104.
It has a lot of applications right now, like PHP, Python, MySQL and so on...

It would be nice to have mongoDB as well.

Comment by Tony DEBOSCHERE [ 15/Jul/15 ]

Same goes for me.
Arm support would be great !
I look forward to it, it would open some new possibilities for my vps choice.
The lack of arm support was the only red flag for me to go to a better cloud vps hosting

Comment by Andrew Morrow [ 16/Jul/15 ]

Hi All -

Earlier this week, a major roadblock for portability to non-x86 platforms was resolved. For some time, we have been stuck using an old version of the V8 Javascript interpreter because newer V8 versions removed critical memory management facilities that we depended on to constrain resource utilization during server side Javascript execution. While newer versions of V8 had added ARM support, the version on which we were pinned did not have those changes. However, on Tuesday, we committed experimental support for building with SpiderMonkey. SpiderMonkey both provides the resource management facilities that we require, and we anticipate, though have not yet confirmed, that it will not represent a barrier to portability like old V8 engine did.

The next development release, 3.1.6, will contain the new SpiderMonkey interpreter as an opt-in, however, our initial integration will only have build information encoded for how to target x86. If you are interested in trying to build with SpiderMonkey on other platforms, please reach out to the development team on mongodb-dev and we can provide guidance on how to configure SpiderMonkey on those platforms, or for any other portability issues. To build with the new interpreter, invoke scons with the --js-engine=mozjs flag.

Please note that currently we only officially target, test, and release for x86, and we are aware of latent endian, aliasing, and alignment issues in the codebase in general, and in the storage engines in particular. These issues may or may not adversely affect ports to other processors, depending on their endianness and sensitivity to alignment. We are working to resolve these issues, however fixing them is not an explicit release goal for the upcoming 3.2 stable. Additionally, there are likely to be issues with the build system, which has not been well tested on non-x86 systems.

For examples of some of these types of issues, please see SERVER-19427, SERVER-19430 and SERVER-19431.

Comment by Richard Kimber [ 16/Jul/15 ]

Thanks @Andrew, that really good news!

Comment by Tony DEBOSCHERE [ 17/Jul/15 ]

Thanks ! Looking forward to it

Comment by Daniel Rosenberg [ 03/Sep/15 ]

With the strong trend of ARM microserver in the cloud space (see ovh, scaleway, HP, datacentred,...) with low TCO, support of ARM v7 and v8 is very welcome. +10. Really looking forward to it.

Comment by Andrew Morrow [ 03/Sep/15 ]

Hi Daniel Rosenberg - Please note that official support for ARM v7 is unlikely. The MMAPv1 storage engine is limited to ~1GB of journaled data on 32-bit systems, and the WiredTiger storage engine is 64-bit only. Effectively, this means that any future ARM port will only target Aarch64.

Comment by Joe Pea [ 20/Jan/16 ]

Any progress on this? I'd really like to get Meteor running on my Nexus 6P Android phone (AArch64).

Comment by Daniel Rosenberg [ 20/Jan/16 ]

I wonder if docker can give an alternative to run MongoDB on ARM v7 (32 bit) and ARM v8 (Aarch64).
Can you confirm this is viable ?

Comment by Joe Pea [ 20/Jan/16 ]

I'm not too familiar with docker. Would I install docker and run that command from inside Android Linux?

Comment by Daniel Rosenberg [ 20/Jan/16 ]

Me too. My question was more for Mongodb dev team. But it looks feasible. Docker is basically a light weight container, which enable software to run software which has been packaged as docker regardless of the underlying hardware. This is similar in concept to virtualization but is more effective. If I understand correctly, you have basically 3 layers:

  • Software dockerised and platform independent-
  • Docker
  • Hardware / OS

In our case, I understand that MongoDB could be dockerised and therefore run on any docker compliant platform.
Is my understanding correct ?

Comment by Fabian Köster [ 20/Jan/16 ]

Docker performs only container virtualization, meaning all docker containers are running on the Linux kernel of the host system, just isolated using Linux cgroups. So if your host system is ARM-based it can only run ARM-based containers or generally speaking: Docker can only run containers build for the same architecture as the host system.

So Docker (and other container virtualization systems) do not help with this issue. What you need is full hardware virtualization [1]. A popular software of this category is QEMU which can for example emulate a x86 system on an ARM-based Linux. It should be able to run on Android too. But be aware that this full virtualization is very expensive in terms of resources and adds a lot of overhead to the software running inside of it. So you probably won't get the performance from MongoDB you would expect, especially on relatively low-end processors like the ones in smartphones.

The only real solution is to add native ARM v8 support to MongoDB itself. More and more servers out there are using ARM architecture, so this is quite inevitable.

[1] https://en.wikipedia.org/wiki/Hardware_virtualization

Comment by Andrew Morrow [ 20/Jan/16 ]

Hi All -

Yes, there has been some progress on Aarch64, along with several other general portability improvements. That work is ongoing and incomplete, and is only available on the master branch, which is not suitable for production (the master branch is currently the source for the 3.3 development releases, which will eventually become the stable 3.4 release). Note that Aarch64 support is experimental, not currently slated to officially land in 3.4, and is not currently being actively developed or tested. However, you are welcome to experiment with it and we hope that you will report your findings.

Comment by Githook User [ 28/Apr/16 ]


{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}

Message: SERVER-1811 Re-enable aarch64 support
Branch: master

Comment by Brian McCarthy [ 23/Aug/16 ]

MongoDB is pleased to announce the 64-bit ARM development release for both its Community and Enterprise offerings. This encompasses the core server components including the shell, mongod and mongos processes, and the server tools. ARM support will apply for Ubuntu 16.04 64-bit on ARMv8 or newer.

Please note that only the WiredTiger storage engine is supported for the core server. MMAPv1 will not be supported on ARM.

The community edition of the binaries are now available on our downloads page for the latest 3.3.11 release.

For customers requiring comprehensive support, advanced security features, and certifications, the Enterprise Evaluation Edition is available here

Official ARM support will arrive with the MongoDB 3.4 GA.

Comment by Fredrik Svantesson [ 09/Aug/18 ]

Are there any plans to provide up-to-date ARM binaries for Debian 9 as well?

Comment by Andrew Morrow [ 09/Aug/18 ]

Fredrik Svantesson - If that is something you would like to see provided, would you mind opening a new ticket explicitly requesting it? This ticket is closed, and from a workflow perspective it is easier for us to evaluate and track such a request with an open ticket.

Generated at Thu Dec 13 09:49:24 UTC 2018 using Jira 7.12.1#712002-sha1:609a50578ba6bc73dbf8b05dddd7c04a04b6807c.