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

• 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

On my omega 1, after node is installed I'm left with 1.7MB of space remaining. This is a decent amount if you are building your entire code base. You must be very careful which external packages you choose to use, that 1.7MB can run out really quickly. I know this from experience.

Now to start, I'm not sure if I'm lazy or just bored, one of the two is my excuse for doing this. I've been working on an existing project for the past couple of days and ran out of space on the Omega. Instead of using a USB stick and pivot overlay, I am using /tmp, which I believe is ram space.

Obviously ram gets cleared during a reboot or power cycle, so it's kinda hard to run your code when it doesn't exist.

Enter init.d....

I have created an init.d script that does a git pull on a repo in to /tmp. After a successful pull, the script also launches the application. User specific settings are kept in /root to maintain some amount of persistence.

While my omega_garage project is running, /tmp usage is at 22% and fairly steady.

Depending on your projects requirements, this may be a viable solution for people that don't want to setup pivot overlay, people that don't have extra USB sticks lying around, or if you are like me and didn't want to pull the ladder out to climb up and insert a USB stick.

I have been running this in my garage for 3 days, there does not seem to be any ill side effects.

Please let me know what you think of this idea, or any potential downfalls to this approach.

Happy coding!

about to go through the tutorial to increase ram and storage on USB flash drive so i can run node red on omega 2+
i would like to keep the usb drive free, can i use an sd card instead
if so is there any advantages/disavantages, is there a certain spec sd card i need to use
there is an obvious advantage as i also brought a usb blue tooth dongle, which maybe my fault but i wanted a device to run node red so i brought this omega device to do that and i also wanted blue tooth, i didn't know at time of purchase that i need to create ram/storage on usb which i may of not purchased
plus keeps the unit quite tidy if i was to use sd
also if yes do i follow the same tutorial i assume so

appreciate your help

asking before i try as i came to soo may issues updating the omega and getting it connected to wifi, i would hate to hit an issue and come to the wrong conclusion that i can't use sd card

thanksbolded text