A software fix for the unexpected reboot case is possible, at least for recently manufactured Omega2+ boards.
The driver identifies the flash chip as a MX25L25635E, and Onion have provided the datasheet for the same. But this chip was was superseded by the MX25L25635F in 2012, and by the MX25L25645G in 2020. Both revisions included a process change, and Macronix deliberately retained the old JEDEC ID so that the new part could be a drop-in replacement, so I would find it surprising if E revision were still broadly available to manufacturers today. The F and G revisions support 4-byte opcodes, so the host can access memory beyond 16M while keeping the chip always in 3-byte address mode.
I modified OpenWrt v19.07.7, which normally hangs on reboot, to select the F instead of the E chip, and installed it on an Omega2+ purchased in 2021. Reboots now work correctly, and yes, I confirmed that the upper part of the flash memory is accessible as well.
So the first question is, do all the boards out there use the F chip or did earlier manufacturing runs get the E? Onion's fix to reset the address mode on shutdown relies on commands that are only documented in the F datasheet and not the E. So chances are good that it's been the F all along... but if somebody with older hardware could test, that would give more confidence than drawing conclusions from the absence of a command in the datasheet.
The second question is can we upstream a fix into OpenWrt, which definitely needs to support the E chip on non-onion devices? Recall that we can't use the JEDEC ID to differentiate because the IDs are the same. The mainline kernel already handles this by looking at the Basic Flash Parameters Table. Unfortunately the driver in OpenWrt bales out before loading the BFPT because the SFDP signature from the chip reads as 0xFFFFFFFF instead of the magic value it expects. The latter problem also occurs on an Omega2S+ which has the completely different W25Q256 flash chip. So I think reading the flash parameters is just broken in OpenWrt, but there have been so many changes to the SPI NOR code in mainline since the 4.14 branch that I wasn't able to find a promising patch to backport.
It's worth noting that some OpenWrt users fix this by naming a specific flash chip in their device tree config, rather than relying on the ambiguous JEDEC ID lookup. This isn't a good solution for Onion, however, because a single .bin file today is usable by the Omega2+ and Omega2S+, and hardcoding a name would require two separate builds.
I'm going to fix my application by installing my patch into the target/linux/ramips/patches-4.14 directory of OpenWrt before builds. You may want to do the same, but do your own testing in case any boards with an E chip are out there which would break. Hopefully when OpenWrt moves to a 5.x kernel we can have a more general fix.
@jonty No. The wireless Arduino IDE method outlined in our documentation has worked consistently since the launch of the Arduino Dock 2 back in 2016.
In @Noniono's case, using a programmer is meant to test the MCU.
It isn't responding to the Omega. If it also doesn't respond to the programmer, then we know the MCU has somehow gotten into a bad state or has been damaged.
@sks14 It will support all UVC (USB video class devices) compatible cameras: https://en.wikipedia.org/wiki/List_of_USB_video_class_devices
The Logitech C920 is tried and true. We used that in the timelapse camera project in the Omega2 Project Book.
From the blog post:
What if I need units now?
Visit our distributors Mouser and Digikey – they will continue to sell Omega2 devices in small and large quantities with immediate shipping.
Unfortunately, they’re both out of stock of the Omega2+ (OM-O2P) at the moment. We’re working to resupply them, currently estimating an April timeframe.
To find direct links for Onion products on our distributors’ sites, see our new How to Buy page (https://onion.io/buy)!
@maxromanovsky Short Answer: It doesn't affect the Omega2
MIPS (the company) has stopped developing new MIPS CPU architectures. But that doesn't affect existing MIPS architectures (like the MIPS 24KEc in the Omega2's CPU).
CPUs based on existing MIPS architectures will continue to work (no reason why they wouldn't). Software support for MIPS architectures will also continue for quite some time because there's so many MIPS-based CPUs out there in the wild.