Community

cas

Still going strong: :-)

root@Omega-FA93:~# uptime
 12:23:21 up 576 days, 18:38,  load average: 0.00, 0.00, 0.00

cas

@crispyoz
Your file will be there, but is being replaced and removed at startup by the code in: files/etc/uci-defaults/14_banner.

cas

@chris-Ó-Luanaigh asked:

A question - why is the global version $19 more expensive?

I'd expect that the chip in the global model that supports all the additional bands is more expensive.

cas

@Cameron-Spitzer
The short answer is: Yes
However, there is more to it than just supplying 3v3 power.

Experience has shown us that the Omega2 is very sensitive to power fluctuations, requires a regulator at least, but a couple of caps are highly recommended together with the use of short, heavy gauge wire due to the current drawn when hitting wifi initialisation at boot.

Your first port of call should be the official documentation here: Powering the Omega with No Dock

Next, doing a quick search of these forums will yield a fair amount of discussion from the enthusiasts here on their own experiences and suggestions on making it a smoother experience for you.
Here is just one thread of many: [Resolved] Omega 2+, Powered without Dock, Shuts off after 18s

Having said all that, do not underestimate the power of having a spare expansion dock available when things go wrong. It is by far the simplest way to power your O2 and get direct serial access to the console for troubleshooting.

Welcome and Good luck !!

cas

Looks like a good move: MIPS Goes Open Source

Will that MediaTek wifi driver that was the bane of our development efforts before the warp core release now enter the public domain, I wonder? ;->

cas

@brolly759 said

I tried the above and it worked, if you have the time, try it to and let me know how it goes! :)

Well, perhaps you can backup your uboot, but it seems that ~~you can't write it back this way~~:

# mtd write u-boot.bin mtd0
Could not open mtd device: mtd0
Can't open device for writing!

[edit]
You can, but it's not as trivial, so it requires some hoop jumping to get it done.

# mtd write u-boot-env.bin u-boot-env
Unlocking u-boot-env ...

Writing from u-boot-env.bin to u-boot-env ...
# mtd write u-boot.bin u-boot
Unlocking u-boot ...

Writing from u-boot.bin to u-boot ...

[/edit]

cas

@Edward-Cheadle asked:

@Janus-Sanders Do you know if this Docker Image;
https://hub.docker.com/r/onion/omega2-source/
will work for my Omega2 Pro;
https://onion.io/announcing-the-new-omega2-pro/

Yes, it will, but that docker image is a bit long in the tooth now, so there are a few things you'll have to do, namely:

fix the ubuntu package install environment
install the time package
update the source
switch to the openwrt branch
create a symlink to the O2 .config if building firmware b222 and later

Something along the lines of (after creating your container):

# fix the ubuntu package install environment
# install the time package
apt-get update
apt-get -f install
apt-get install time

# update the source
git pull

# switch to the openwrt branch
git checkout openwrt-18.06

# clean out any old LEDE related feeds
./scripts/feeds clean
./scripts/feeds update -a
./scripts/feeds install -a

# create a symlink to the O2 .config (only relevant when building firmware b222 onwards)
ln -s .config.O2 .config

# build
make

I took this from my container's history, so I hope I haven't missed anything or made any errors.

Also make sure you allocate enough space for the container. I suggest 30GB at a minimum, but more if you have it.

If you'd like to build a particular firmware revision, it's useful to add a few git tags where necessary. If you are interested here are the last few of mine:

git tag v0.3.2-b222 96400e1
git tag v0.3.2-b221 221604e
git tag v0.3.2-b220 0984915
git tag v0.3.2-b219 7cdd57e
git tag v0.3.2-b218 adfead5
git tag v0.3.2-b217 d624ea1
git tag v0.3.1-b216 c22c17c

Then you can run a specific build with a:

git checkout v0.3.1-b216
make

cas

@Douglas-Kryder said:

@Lazar-Demin just noticed that there is no expansion header pin reference at all printed on the board.

Ooh, good catch!
Also, since there's no longer a diagonal corner to act as a visual guide, the expansions are at risk of being installed in an incorrect orientation by those new to the board.
And, since the expansion header is so close to the edge, when inserted, the expansions are bound to overlap the edge of the board underneath, so enclosures will have to be designed accordingly.

cas

Just a heads up that the project is now live in case anyone would like to back it.

cas

@alejandro-neujovics

FATAL ERROR: Committing semi space failed. Allocation failed - process out of memory

Perhaps you need more swap space, or disk space?

cas

@Carst-Dan

Unfortunately the actual docker version runs only on win 10, I'am using win 7.

If you decide to follow the docker route any further, they do provide Docker Toolbox for older systems Docker Toolbox overview

At moment i am contacting some colleagues, maybe they can help.

Ok, best of luck, I hope that you are successful. But if not, we can always keep exploring options here.

cas

@Yvan-Gagnon
Well it turns out that you don't need the Onion blynk-library, you can just use the standard one. So you don't need to wait for @Lazar-Demin.

Just follow the blynk 2 bullet Tuesday example with some minor modifications.

In the section "Let’s switch over to the Omega", substitute what is there with the following (assuming that you are running a b2xx firmware):

opkg update
opkg install node-npm

NOTE - This requires a fair amount of space.[1]

Test that node and npm are working:

root@Omega-BFC9:~# node --version
v8.10.0
root@Omega-BFC9:~# npm version
{ npm: '5.6.0',
  ares: '1.10.1-DEV',
  http_parser: '2.7.0',
  modules: '57',
  nghttp2: '1.25.0',
  node: '8.10.0',
  openssl: '1.0.2p',
  uv: '1.19.1',
  v8: '6.2.414.50',
  zlib: '1.2.11' }

NOTE - npm takes a bit of time to get going, so be patient.

Then install the blynk-library using npm:

root@Omega-BFC9:~# npm install -g blynk-library
/usr/bin/blynk-client -> /usr/lib/node_modules/blynk-library/bin/blynk-client.js
/usr/bin/blynk-ctrl -> /usr/lib/node_modules/blynk-library/bin/blynk-ctrl.js
+ blynk-library@0.5.4
added 1 package in 22.028s

Create the test.js file as described, except you must change the source of the blynk-library in the first line of the file:

var BlynkLib = require('/usr/lib/node_modules/blynk-library');
 
var blynk = new BlynkLib.Blynk('YOUR AUTH TOKEN HERE'); // !!!
var v1 = new blynk.VirtualPin(1);
 
v1.on('write', function(param) {
  console.log('Hi! Pin V1 is: ', param);
});

Remember to use your own blynk auth token as described in the 2 bullet Tuesday article.

Then run and test:

root@Omega-BFC9:~# node test.js

    ___  __          __
   / _ )/ /_ _____  / /__
  / _  / / // / _ \/  '_/
 /____/_/\_, /_//_/_/\_\
        /___/

  Give Blynk a Github star! => https://github.com/vshymanskyy/blynk-library-js

Connecting to: blynk-cloud.com 443
SSL authorization...
Connected
Authorized
Hi! Pin V1 is:  [ '1' ]
Hi! Pin V1 is:  [ '0' ]
Hi! Pin V1 is:  [ '1' ]
Hi! Pin V1 is:  [ '0' ]
^C
root@Omega-BFC9:~#

[1] - Here is a before and after snapshot of my free space when installing node-npm and node:

root@Omega-BFC9:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.0M      8.0M         0 100% /rom
tmpfs                    61.0M    220.0K     60.8M   0% /tmp
tmpfs                    61.0M    112.0K     60.9M   0% /tmp/root
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock6           22.3M    692.0K     21.6M   3% /overlay
overlayfs:/overlay       22.3M    692.0K     21.6M   3% /


root@Omega-BFC9:~# opkg install node-npm
Installing node-npm (v8.10.0-3) to root...
Downloading http://repo.onioniot.com/omega2/packages/packages/node-npm_v8.10.0-3_mipsel_24kc.ipk
Installing node (v8.10.0-3) to root...
Downloading http://repo.onioniot.com/omega2/packages/packages/node_v8.10.0-3_mipsel_24kc.ipk
Configuring node.
Configuring node-npm.


root@Omega-BFC9:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 8.0M      8.0M         0 100% /rom
tmpfs                    61.0M    220.0K     60.8M   0% /tmp
tmpfs                    61.0M    112.0K     60.9M   0% /tmp/root
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock6           22.3M     14.0M      8.3M  63% /overlay
overlayfs:/overlay       22.3M     14.0M      8.3M  63% /
root@Omega-BFC9:~#

If you do like I did the first time I tried this and install on an O2+ with insufficient space, you will run out of space during the installation. Thereafter it can be a bit of a PITA to regain space because opkg won't allow you to remove the packages that it didn't successfully install.

In this case, there is a very handy utility here: opkg-cleanup.sh (Albeit, FOR OpenWRT 18.06 ONLY) that will get you out of trouble and manually remove the packages. You'll probably have to delete a file or two in /overlay/upper first so that you can create enough space to create the cleanup tool.

cas

@Pedro-Moura
Perhaps the details and the links to further information contained in here can be of assistance: FAQ: I heard there is some issue with hardware SPI?

cas

@mawg
An official Onion docker container is available. Instructions are available in the source repo readme file Using the Docker Image at OnionIoT/source

cas

@CAP-33

In connection with this event, the question arises: will the support of Omega2 and Omega 2+ be discontinued?

I wouldn't think so.
There are many O2's and O2+'s out there in the wild, not to mention all the docks that rely on them. IMHO, It wouldn't make sense to discontinue them.

To my mind, the O2Pro is basically a little beefed up version of an O2+ hard fixed to a power dock.

Or are you seeing something obvious that I am missing here?

cas

@Erik-Hougaard
I'm no docker expert, but I've been learning a bit about it over the last few days. When you exit a container it automatically maintains its last state.

I would suggest that you review the docker docs on how to re-use a container. i.e. look into docker start or docker attach if you detached instead of exiting.

cas

So I was trying to use sysupgrade to upgrade an O2+ to the latest firmware and kept getting "Could not get image magic" and "Image check failed." errors.

I'd copied the .bin file from my USB to my O2+ root filesystem and ran sysupgrade with the -n parameter like so:

root@Omega-C0D3:/# cp /tmp/mounts/USB-A1/omega2p-v0.2.0-b183.bin .
root@Omega-C0D3:/# sysupgrade -n omega2p-v0.2.0-b183.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... onion-helper udhcpc udhcpc dnsmasq mountd ntpd ubusd logd rpcd netifd odhcpd uhttpd device-client avahi-daemon
Sending KILL to remaining processes ...
Switching to ramdisk...
Performing system upgrade...
Could not get image magic
Image check failed.
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
[  128.911166] Removing MTD device #6 (rootfs_data) with use count 1
[  128.947452] reboot: Restarting system

After a fair amount of head scratching and frustration (including comparing md5sums of the source and the destination files), I found that running it directly from the USB drive worked:

root@Omega-C0D3:/tmp/run/mountd/sda1# sysupgrade -n omega2p-v0.2.0-b183.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... onion-helper udhcpc udhcpc dnsmasq mountd ntpd ubusd logd rpcd netifd odhcpd uhttpd device-client avahi-daemon
Sending KILL to remaining processes ...
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...

Writing from <stdin> to firmware ...
Upgrade completed
Rebooting system...
umount: can't unmount /tmp/run/mountd/sda1: Resource busy
umount: can't unmount /tmp/run/mountd: Resource busy
umount: can't u[  484.971767] Removing MTD device #6 (rootfs_data) with use count 1
nmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[  485.008580] reboot: Restarting system

Thought I'd put this out there in case anyone else runs into the same problem....

[edit]
Ok, so the root of the problem (pun not intended) actually appears to be that you can't run the sysupgrade command if the firmware binary is in your root (/) directory.
Observe:

BusyBox v1.26.2 () built-in shell (ash)

   ____       _             ____
  / __ \___  (_)__  ___    / __ \__ _  ___ ___ ____ _
 / /_/ / _ \/ / _ \/ _ \  / /_/ /  ' \/ -_) _ `/ _ `/
 \____/_//_/_/\___/_//_/  \____/_/_/_/\__/\_, /\_,_/
 W H A T  W I L L  Y O U  I N V E N T ? /___/
 -----------------------------------------------------
   Î©-ware: 0.1.9 b159
 -----------------------------------------------------
root@Omega-C0D3:/# cp /tmp/mounts/USB-A1/omega2p-v0.2.0-b183.bin .
root@Omega-C0D3:/# sync
root@Omega-C0D3:/# sysupgrade -n omega2p-v0.2.0-b183.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... uhttpd device-client onion-helper udhcpc avahi-daemon dnsmasq udhcpc mountd ntpd ubusd logd rpcd netifd odhcpd
Sending KILL to remaining processes ...
Switching to ramdisk...
Performing system upgrade...
Could not get image magic
Image check failed.
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
[  373.914390] Removing MTD device #6 (rootfs_data) with use count 1
[  373.951674] reboot: Restarting system

But if we move the firmware file from the root (/) directory to root's home directory (/root), hey presto, no problem writing it, as you can see here:

BusyBox v1.26.2 () built-in shell (ash)

   ____       _             ____
  / __ \___  (_)__  ___    / __ \__ _  ___ ___ ____ _
 / /_/ / _ \/ / _ \/ _ \  / /_/ /  ' \/ -_) _ `/ _ `/
 \____/_//_/_/\___/_//_/  \____/_/_/_/\__/\_, /\_,_/
 W H A T  W I L L  Y O U  I N V E N T ? /___/
 -----------------------------------------------------
   Î©-ware: 0.1.9 b159
 -----------------------------------------------------
root@Omega-C0D3:/# mv omega2p-v0.2.0-b183.bin /root/
root@Omega-C0D3:/# cd /root
root@Omega-C0D3:~# sysupgrade -n omega2p-v0.2.0-b183.bin
killall: watchdog: no process killed
Sending TERM to remaining processes ... onion-helper udhcpc udhcpc dnsmasq mountd ntpd ubusd logd rpcd netifd odhcpd uhttpd device-client avahi-daemon
Sending KILL to remaining processes ...
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...

Writing from <stdin> to firmware ...
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
[  215.389374] Removing MTD device #6 (rootfs_data) with use count 1
[  215.425706] reboot: Restarting system

[snip]

BusyBox v1.25.1 () built-in shell (ash)

   ____       _             ____
  / __ \___  (_)__  ___    / __ \__ _  ___ ___ ____ _
 / /_/ / _ \/ / _ \/ _ \  / /_/ /  ' \/ -_) _ `/ _ `/
 \____/_//_/_/\___/_//_/  \____/_/_/_/\__/\_, /\_,_/
 W H A T  W I L L  Y O U  I N V E N T ? /___/
 -----------------------------------------------------
   Î©-ware: 0.2.0 b183
 -----------------------------------------------------
root@Omega-C0D3:/#

Hopefully less head-scratching for someone else (and I've marked the topic title [solved] for anyone finding this from google as a google search didn't have a lot of hits on this one).

[/edit]

cas

I think this is an awesome deal Humble Book Bundle: DIY Electronics by Wiley

Even if you don't need the books yourself, tell your friends.

cas

@Elliot-477569 said

Am I doing this correctly?

elliot477569@Helium2:/mnt/d/Onion/source/build_dir/host/sed-4.2.2$ make configure
make: 'configure' is up to date.

Maybe we're missing something.
My interpretation of this is that configure didn't get built:

make[4]: Entering directory '/mnt/d/Onion/source/build_dir/host/sed-4.2.2'
CDPATH="${ZSH_VERSION+.}:" && cd . && bash /mnt/d/Onion/source/build_dir/host/sed-4.2.2/build-aux/missing --run autoconf
autom4te: need GNU m4 1.4 or later: /mnt/d/Onion/source/staging_dir/host/bin/m4
Makefile:1023: recipe for target 'configure' failed
make[4]: *** [configure] Error 1
make[4]: Leaving directory '/mnt/d/Onion/source/build_dir/host/sed-4.2.2'

But your make says it's up to date, which would indicate it was built successfully.

Perhaps it's time to backup your .config and make distclean and start from scratch?

[edit]
Looking back through the thread, the following:
1.) make died, making sed.
2.) a later make skipped over sed (indicating it was successful - correlates with your make configure ) and then died making the next file: patch.

Maybe this is a timing issue within make? Perhaps a later thread is exiting before an earlier thread has completed?
What if you just run make with no parameters? It'll be slow, but hopefully sequential...
[/edit]

Best posts made by cas