M
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.
