If I may ask, what are you trying to accomplish?
MongoDB is not really a lightweight database server in the sense the Omega is lightweight. For example if i recall correctly MongoDB starts off with 100 MByte initial size for an empty database. It is really more intended to run on servers than on embedded systems.
Maybe Redis woudl be a better choice (not sure)? Or what about somethin embedded like SQLite of BerkleyDB? Or maybe using Micropython in conjunction with their BTree module?
If I may ask, what are you trying to accomplish?
MongoDB is not really a lightweight database server in the sense the Omega is lightweight. For example if i recall correctly MongoDB starts off with 100 MByte initial size for an empty database. It is really more intended to run on servers than on embedded systems.
Maybe Redis woudl be a better choice (not sure)? Or what about somethin embedded like SQLite of BerkleyDB? Or maybe using Micropython in conjunction with their BTree module?
As far is I know the SPI bus on the external header of the Omega2 is shared with the internal NOR Flash (which is tied internally to CS0). This probably causes the 'boot-effects' you're experiencing (as the APA102 does not have a CS/SS line)
For devices without SS-line it's probably easiest to set up a software (bitbang) spi bus e.g. with the spi-gpio-custom module, which isn't shared with something else.
I seem to have found a solution for this issue, or at least a work around that works for me: YMMV
I've merged in the OpenWRT repo (git merge -X theirs openwrt/lede-17.01) into my OnionIoT/source repo. That built flawlessly ! :). So we're running kernel 4.4.153 now. That's nice on its own (always recommended to keep up with LTS kernel versions!).
Anyway, the SPI problem persisted. Then I removed the original Onion patch file for the spi-mt7621 module (rm ramips/patches-4.4/9999-spi-mt7621.patch) and rebuilt the image. Now we're using the unpatched mainline SPI driver. Guess what: this seems to work flawlessly! 
I'm a happy man now.
I only did some quick smoke tests, so it could be other SPI stuff breaks because of the missing patch. On the other hand, there have been some commits to the spi-mt7621 module in June, so the mainline might just be the only thing we need.
In the pursuit to track down my SPI issues I've reconfigured my kernel to not include the mt7621 SPI HW driver.
The patch to the .config is almost trivially simple:
diff --git a/target/linux/ramips/mt7688/config-4.4 b/target/linux/ramips/mt7688/config-4.4
index c4a844da38..6fc9a91e6d 100644
--- a/target/linux/ramips/mt7688/config-4.4
+++ b/target/linux/ramips/mt7688/config-4.4
@@ -225,8 +225,11 @@ CONFIG_SOC_MT7620=y
# CONFIG_SOC_RT3883 is not set
CONFIG_SOUND=m
CONFIG_SPI=y
+CONFIG_SPI_BITBANG=y
+CONFIG_SPI_DEBUG=y
+CONFIG_SPI_GPIO=y
CONFIG_SPI_MASTER=y
-CONFIG_SPI_MT7621=y
+# CONFIG_SPI_MT7621 is not set
# CONFIG_SPI_RT2880 is not set
CONFIG_SRCU=y
CONFIG_SWCONFIG=y
Building a new image works fine, but the resulting image -somehow- is not booting. I did not touch anything other that the patch above. Here is the kernel boot output deemed important:
[ 0.000000] Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jffs2
**snip**
[ 0.435122] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 0.442720] Please append a correct "root=" boot option; here are the available partitions:
[ 0.451254] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 0.460532] Rebooting in 1 seconds..
Seemingly the kernel is not correctly pointed towards the rootfs. Isn't it u-boot's job to inform the kernel of the whereabouts of the rootfs and the layout of the MTD main storage device?
Me not (yet :)) being an OpwnWRT/Buildroot expert, it's probably something trivial I'm overlooking here. Any handles anyone?
Correction:
It is not only my own custom build that fails the test. Just tested with the pre-built omega2p-v0.2.0-b196.bin and has same problem. (Kernel version 4.4.74)
The build I get using oupgrade --force (omega2p-v0.1.10-b160.bin, kernel 4.4.46) has a working SPI (but is otherwise too old/buggy).
Any pointers where to look for the bug ? (spidev driver of the newer kernel?)
I'm getting started on getting the SPI bus on my Omega working using Rust.
I ported a SPI library (rppal) from the RasPi to Omega2 (In case anybody else is struggling with this: ioctl's are defined/composed differently on MIPS(el) than on other architectures!).
After getting my ioctl's sorted, everything seems to work fine using the stock firmware, both using the hardware spidev as well as when using the spi-gpio-custom driver.
On my own firmware build however (based on https://github.com/OnionIoT/source head), the spidev stops working. The device node is present /dev/spidev32766.1, ioctls work and my scope registers digital signals going over the bus... All data read on the bus however is the same byte, either using my own tool or the bundled spi-tool (not all ones or zeroes but the same byte each time). Tying the MISO to GND or VCC doe not change the data read.
Iv'e compared modules of my firmware and the stock, with these results:
Modules in stock fw, but not in mine:
dma_shared_buffer, mt76x8, ralink_eeprom_api, snd_pcm_dmaengine, snd_soc_core, snd_soc_ralink_i2s, snd_soc_simple_card, snd_soc_wm8960, snd_usb_audio, snd_usbmidi_lib, uvcvideo, v4l2_common, videobuf2_core, videobuf2_memops, videobuf2_v4l2, videobuf2_vmalloc, videodev
and vice versa: modules in my build, but not in stock:
ip6_udp_tunnel, mt_wifi, spi_bitbang, spi_gpio, tun, udp_tunnel, wireguard
What am I missing here? Any ideas on what could be wrong?
As you're also linking in the source of the driver, the following question arises:
Is this purely a device tree addition/enhancement, or is also a patch to the spidev kernel module needed?
Btw: great work!