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.

It looks from the screenshots in the guide that the hosted web site for firmware upgrades is very Onion specific. I'm concerned that I've wiped out all Onion related stuff when I flashed OpenWRT.

Also, the instructions are really about getting the image file on the device, which I can do just fine.

My problem is that after an apparently successful sysupgrade on the image file, the new image doesn't take affect, and following the automatic reboot, the old OpenWRT image boots.

Thanks for responding @Luciano-S. I do have an ethernet dock. Everything in the instructions your provided works fine, but the httpd server never responds (at 192.168.1.1). My browser just spins forever.

Any ideas?

...I should point out that I have tried the 7 second (i.e. hard) factory reset to no avail. The device reboots, but boots into OpenWRT again.

Hey,

I flashed my Omega (1) to stock OpenWRT (openwrt-ar71xx-generic-vmlinux.bin). That worked fine, but now I'm trying to go back to the Omega image (openwrt-ar71xx-generic-onion-omega-squashfs-sysupgrade.bin) and the call to sysupgrade succeeds, however the same old OpenWRT OS is always what boots up.

Is there a problem flashing the onion OS over OpenWRT?

Thanks in advance

Hey,

Using the cross compile wiki (Omega1 FWIW) I built a new OS image and have successfully installed that image. However, I tried to modify the image by adding things through menuconfig (i.e. gdb support, etc.) but the compiled image size never changes.

Is there something else I need to do to modify the openwrt-generic-onion-...-factory.bin file?

Thanks.

Thanks Kit. That is what I was looking for.

I agree...a link on the new docs home page makes total sense.

Now that the onion.io site has been updated with the Omega2 documentation, is there a link to the previous Omega1 documentation that it replaced? I've got lots of work left to do on the Omega1 before I start on the port/upgrade to the Omega2/Lede.

Thanks in advance

I forgot to mention that I've already set kernel.core_pattern in /etc/sysctl.conf, however, attempting to change the core file size limit as follows,

ulimit -S -c unlimited

results in "ulimit: core file size: cannot modify limit: Invalid argument". The current value is set to 0 (zero), which means no core file.

I've tried various other arguments to no avail.

Has anyone been able to capture core dumps on the Onion Omega (1)? If so, can you provide the recipe? I've got a c program that is crashing but there is no core dump left behind.

UPDATE: I found that pulling the RST pin low (GND) causes a reset. Reading the RST pin shows 3.3vdc. This answers my question.