Important: There are two versions of the firmware; one for the Omega2 and Omega2S, and one for the Omega2+ and Omega2S+:

• Firmware starting with omega2-... is for the Omega2 (OM-O2) and Omega2S (OM-O2S) - both with 64MB RAM and 16MB storage
• Firmware starting with omega2p-... is for the Omega2+ (OM-O2P) and Omega2S+ (OM-O2SP) - both with 128MB RAM and 32MB storage

Looking for a way to probe the hardware to reliably detect if it is a Omega2/2S (64MB MB RAM, 16 MB Flash) or an Omega2+/2S+ (128MB MB RAM, 32 MB Flash)

Why is this useful?

If an Omega2+ is flashed with Omega2 firmware, the software (like ubus call system board) will identify it as an Omega2 regardless of the hardware differences.

We need a way to identify the actual hardware on the device to determine if it is an Omega2 or Omega2+

Solution that works from Linux Userspace

In the kernel messages (which can be viewed with the dmesg command), there is a line like:

[    0.358842] m25p80 spi0.0: w25q128 (16384 Kbytes)

or (in newer OpenWrt versions):

[    0.639801] spi-nor spi0.0: w25q256 (32768 Kbytes)

This is a message from the spi-nor kernel driver after detecting the actual flash chip. So it is not dependent on the flash size that is baked into the firmware image, but shows the real size of the flash chip. Both of the example lines above are from a firmware made for the Omega2. The first is run on an actual Omega2, the second shows 32M so it is a Omega2+.

The only gotcha with this is that the dmesg buffer is not infinite and will loose older lines when too many new ones arrive. This means detecting the flash chip size needs to be done shortly after startup.

So I put the following line into a startup script (e.g. /etc/rc.local) :

dmesg | sed -n -r -e '/spi0.0: .*w25q/s/.*(w25q.*\))/\1/p' > /tmp/flashchip

With this, the chip name and size is captured and can be read any time later from /tmp/flashchip to detect an Omega2(S)+ vs Omega2(S)+.

Credit

Solution found and published by @luz: https://community.onion.io/topic/4212/any-way-to-detect-an-omega2-when-running-with-omega2-fw

Better Options

There are other better sysfs gpio libraries available for Python3:

• https://pypi.org/project/gpio/
• https://python-periphery.readthedocs.io/en/latest/gpio.html
• https://github.com/vitiral/gpio

Let us know how it goes!

The hardware SPI can only drive 2 devices, as there is only CS0 (already used by internal flash) and CS1.

If you need more than 1 additional SPI device, you'll need to resort to software (GPIO based) SPI. (Also known as bit-bang SPI).

Setting up a Software I2C Bus

Install the required kernel modules

opkg update
opkg install kmod-spi-gpio-custom

Then load the spi-gpio-custom kernel module:

# configure software GPIO SPI
# bus<Y>=<devid>,<SCK>,<MOSI>,<MISO>,<mode>,<speedInHz>,<CS>
insmod spi-gpio-custom bus0=1,11,5,4,0,100000,18

Where

• Y just numbers the software SPI "buses" controlled by spi-gpio-custom. If you need multiple software SPI, you need to specify all of them on the same insmod command line, and specify parameters like bus0=... bus1=... bus2=...
• devid is the number X you'll have in the /dev/spidevX.0 name
• SCK, MOSI, MISO, CS are GPIO numbers for the respective signals
• mode is the SPI mode, usually 0
• speedinHz is the speed. Note that software SPI speed is limited, you'll not get the HW SPI top speed with it

The example above will get you a /dev/spidev1.0 on pins 11,5,4 and 18, in mode 0 and with 100kHz speed.

Drawbacks

Lower Bus Speed. Since this is a software-based bus, it will not be as fast as a hardware SPI bus.

Credit for this FAQ goes to @luz from this thread

• When powered, the Omega2 device does not boot
  • The power LED doesn't light up
• The serial console outputs this and only this:
  

The Root Cause

The 64 kB DRAM in the serial output is the key here. It indicates a hardware issue: the RAM is no longer connected to the MT76 SoC.
The 64kB in the screenshot is a small cache of DRAM that's internal to the SoC.

What can cause this issue

This issue can be caused by a few things:

• Factory defect - possible but very unlikely since every module is extensively tested during manufacturing
• Damaged in transport - possible but not likely
• Damaged during assembly - most common for surface mount modules

Questions to ask to narrow down the issue:

• Did the module ever work before?
  • If not, then it's likely a factory defect
  • If it did, then it was somehow damaged
• For surface mount modules:
  • Was it hand-soldered to your circuit board or was a reflow oven used? If it was a reflow oven, was the reflow profile from the Omega2S datasheet followed?
    • If a hotter reflow profile was used, then it's possible the higher heat desoldered some contacts on the SoC or RAM chip
  • Was the middle ground pad on the bottom of the module soldered?
    • We recommend against soldering the middle ground pad. See the Omega2S datasheet for the recommended reflow profile.

Relevant Forum Posts

https://community.onion.io/topic/1135/omega2-not-starting-up
https://community.onion.io/topic/3969/omega2-gone-non-responsive

See this official solution thread: https://community.onion.io/topic/3049/omega2-reboot-fix-official-solution?_=1606328930119

Note this solution does not apply for the FW_RST (GPIO38) pin

Check out the OpenWRT documentation on this topic: https://openwrt.org/docs/techref/hardware/port.i2c#i2c_over_gpio

Setting up a Software I2C Bus

Install the required kernel modules

opkg update
opkg install kmod-i2c-gpio-custom

Setup a bus:

insmod i2c-gpio-custom bus<BUS NUMBER>=<BUS NUMBER>,<SDA GPIO>,<SCL GPIO>

Example

For example, to setup a SW I2C bus with SDA on GPIO18 and SCL on GPIO19:

insmod i2c-gpio-custom bus1=1,18,19

If all goes well, there will be a message in the kernel log:

[  308.931002] Custom GPIO-based I2C driver version 0.1.1
[  308.936785] i2c-gpio i2c-gpio.1: using pins 18 (SDA) and 19 (SCL)

And there will be a new I2C bus 1 device available:

root@Omega-F195:/# ls /dev/i2c-*
/dev/i2c-0  /dev/i2c-1

Notes:

• Check out the Omega2 pinout and GPIOs article in the documentation to select your GPIOs
• The Omega's hardware I2C bus is occupying the bus0 label, so your new sw i2c bus will need to be bus1
• Keep in mind this is bit banging so the timing is not exact. However since I2C is synchronous it should not be a problem.
• If you're using Onion's Omega2 firmware, you'll need to be on the latest available firmware to install the required kernel modules. See our documentation for more details.

Changing the SW I2C Bus Speed

If you are using SW I2C over GPIO, then when you insert the kernel module you can specify a delay value

For example:

insmod i2c-gpio-custom bus1=1,5,4,udelay

where I2C speed (kHz) = 500 / udelay
udelay can only be an integer

Keep in mind this is bit banging so the timing is not exact however since I2C is synchronous it should not be a problem.

The hardware I2C bus on the Omega2 family has a default clock speed of 100kHz, the standard clock speed for I2C:

How is the I2C Clock Set?

The clock speed is governed by the clock divider in the I2C SM0CTL0 register.

The register's default value is 0x8190 800F, with 0x190 set for the clock divider.

• 0x190 = 400
• The master clock is 40 MHz
• 40 MHz / 400 = 100 kHz

Changing to Fast Mode: 400kHz

It is possible to change the I2C bus clock speed to 400kHz (fast mode) by writing to the SM0CTL0 register using devmem to change the clock divider:

devmem 0x10000940 32 0x8064800F

This changes the clock divider to 0x64 (100), 40MHz / 100 = 400 kHz

To optionally confirm, read the register:

devmem 0x10000940
0x8064800F

Tested on firmware v0.3.2

Credit goes to @György-Farkas from this post from 2018.

More Info

Check out the MT7688 SoC datasheet to see the full register definition.

To get around this and find a list of active clients, the command iwpriv ra0 get_mac_table can be used in conjunction with the DHCP leases.
It will output a list of the MAC address of all connected clients.

# iwpriv ra0 get_mac_table
ra0       get_mac_table:
MAC                 Avg RSSI Last RSSI AP  AID PSM AUTH CTxR  LTxR  LDT       RxB       TxB       Conn Time
e4:ce:8f:0c:02:14   -53      -53       0   2   1   1    54    0     0         0         0         454

As soon as a client disconnects, it will no longer appear on the get_mac_table output.

This can then be cross-referenced with /tmp/dhcp.leases to get a list of active clients.

Taking a look at /etc/config/firewall, you'll notice it has zones that control traffic flow of the network interfaces defined in /etc/config/firewall

By default, the wan firewall zone is attached to the wwan network interface.

Looking at /etc/config/network you'll see that the wwan network interface is apcli0, the Omega's WiFi client interface

We can change the wan firewall zone configuration to enable or disable traffic through this interface.

To start, my Omega is connected to WiFi and can ping the internet:

root@Omega-F195:/# ping www.google.com
PING www.google.com (172.217.164.196): 56 data bytes
64 bytes from 172.217.164.196: seq=0 ttl=115 time=18.968 ms
64 bytes from 172.217.164.196: seq=1 ttl=115 time=22.639 ms
...

Then, I'll run these commands to REJECT input and output traffic for the wan zone:

uci set firewall.@zone[1].output='REJECT'
uci set firewall.@zone[1].input='REJECT'
uci commit firewall

Note: these changes can also be made by modifying the /etc/config/firewall file directly

And restart the firewall:

/etc/init.d/firewall restart

I can no longer access the internet. The WiFi client interface is still associated with the network, but no traffic can go through:

root@Omega-F195:/# ping www.google.com
PING www.google.com (172.217.164.196): 56 data bytes
ping: sendto: Operation not permitted
root@Omega-F195:/# ping www.google.com
PING www.google.com (172.217.164.196): 56 data bytes
ping: sendto: Operation not permitted

A few notes:

1. The default firewall configuration only has zones for the WiFi AP and WiFi Client network interfaces. You'll need to add more zones to the firewall to control the ethernet network interface, or other network interfaces like cellular modems.
2. The firewall also supports creating Rules. For a deeper dive into the firewall and rules, take a look at the openwrt firewall documentation: https://openwrt.org/docs/guide-user/firewall/firewall_configuration

Based on this thread: https://community.onion.io/topic/4189/looking-for-input-managing-network-connection-interfaces

Source code for the wiki articles can be found here: https://github.com/OnionIoT/wiki

We strongly recommend upgrading to the Omega2 family, the hardware is more powerful, it’s a more mature product, and we've done a lot of work to make it a great IoT computer.

There will be current consumption spikes during the Omega's boot, especially when the WiFi radio is being enabled. If the power supply cannot keep up, the Omega will not be able to complete the boot process.

We strongly recommend getting a Dock for your Omega to get the best experience and most performance, functionality, and stability from your device.

If you would like to stick with your no Dock setup, see this documentation article for our recommended power supply circuit: http://docs.onion.io/omega2-docs/hardware-prep-no-dock.html

The documentation that's hosted at https://docs.onion.io/ is open source and can be found on Github: https://github.com/OnionIoT/Onion-Docs

To suggest a change, submit a Pull Request and we'll go from there.