@Leif-Bloomquist

I found a supplier. Try SamTec part number SQT-116-01-F-S.

I order a batch, they came in last week and they fit perfectly.

Problem solved. Running opkg update, then opkg install obidots-client worked.

...I guess I should add that it may take you the better part of a Saturday to get cross compile and Eclipse working, but once its all setup, you'll get it all back and more over using 'Cloud Compile'.

I use VirtualBox running Ubuntu on my OSX box, and that works great.

My current development environment is Eclipse (CDT) using the tool chain that is built as part of the instructions on the wiki. When you create your Eclipse project(s), you specify the tool chain location, etc. I simply copy the generated binaries over to the Omega and I'm off to the races.

FWIW, I use two build profiles within Eclipse, 'Release' and 'Unit'. The Release profile cross compiles and generates Omega binaries, the Unit profile is for unit testing and generates native (Ubuntu) binaries. This way I run all my unit tests locally and then, assuming all unit tests pass, push (scp/rsync) the Release profile generate code to the Omega.

It's not clear from the photo, but can you make sure you don't have a short around the shiny areas in this zoomed section of one of your photos?


Agreed @Kit-Bishop. Automating the 'copy to the Omega' within the IDE makes total sense.

At some point I was going to look into FSSM/RDIST to completely automate the copy (i.e. FSSM detects changes to the binaries and calls scp/rdist to copy them out).

The recipe is really quite straightforward (in hindsight ). Once you have your development linux OS (i.e. Ubuntu) installed and running, compile the OpenWRT/LEDE OS using the instructions on the Cross Compile wiki. I've done it several times now and it works for me every time. FWIW, I'm using OpenWRT versus LEDE as I'm still focusing on Omega(1) until things calm down a bit on the Omega2 front. Once compiled, the OS will contain a openwrt-toolchain-... directory. That is the cross compile toolchain.

Now install the latest (stable) Eclipse CDT.

With Eclipse running, create a new 'hello world' c/c++ project, and in the cross compile options page of the new project wizard specify the prefix (I use 'mips-openwrt-linux-') and the full path to your tool chain.

Now, in Eclipase compile a simple HelloWorld implementation. The 'Release' directory within your Eclipse workspace for the project will contain the 'a.out' (or whatever) binary. Copy the binary to the Omega and run it.

...I guess I should add that it may take you the better part of a Saturday to get cross compile and Eclipse working, but once its all setup, you'll get it all back and more over using 'Cloud Compile'.

I use VirtualBox running Ubuntu on my OSX box, and that works great.

My current development environment is Eclipse (CDT) using the tool chain that is built as part of the instructions on the wiki. When you create your Eclipse project(s), you specify the tool chain location, etc. I simply copy the generated binaries over to the Omega and I'm off to the races.

FWIW, I use two build profiles within Eclipse, 'Release' and 'Unit'. The Release profile cross compiles and generates Omega binaries, the Unit profile is for unit testing and generates native (Ubuntu) binaries. This way I run all my unit tests locally and then, assuming all unit tests pass, push (scp/rsync) the Release profile generate code to the Omega.

It was down more than it was up (same symptoms you describe) prior to the Omega2 upgrade. I'm not sure how reliable it is now, I'm cross-compiling exclusively now (way better BTW).

Thanks @Luciano-S.

Downloading the latest image from (http://repo.onion.io/omega/images) did the trick. I'm now back to the Onion OS.

I'm still vague on why I might be running out of memory. I'm confused because the image size is always the same (16252928 bytes). Even for the different images on the repo site. It seems like this is normal, but I don't understand it. Perhaps the image size is always the same, regardless of what it contains. If that is true, do you (or does anyone) know how to determine what a given image contains?

Thanks again for your reply.

Thanks for responding @Kit-Bishop.

Yeah, I was aware of the tri-state (< >, <M>, <asterisk>) marking in menuconfig. I was careful to select the <*> version. Also, running make following my selections succeeded, and resulted in the set of expected .bin files (in bin/ar71xx/).

I have two clones of the source code. One stock/unmodified and one modified to include gdb (and a few other modules). Comparing the sizes for the onion images from each show the exact same size, leading to my suspicion that I'm not actually changing anything by modifying the build via menuconfig.

@Jürgen-Pollex In the first photo BTW. Halfway down the left-hand row of exposed metal hashes.

Look closely at the array of exposed metal strips. One of them appears to have a couple of holes that the one I have in my hand doesn't have.