Installing OpenWrt 22.03 on an Omega2S+

[huntc]

I've managed to flash OpenWrt 22.03.0 to my Omega2S+ and it all appears to work. However, one area where I'm stumbling is trying to get OpenWrt to recognise the dual radio. The first radio is recognised, but the second one isn't. Apparently, using wifi config should be sufficient to generate configuration, but iw list is only showing a Wiphy phy0. Any pointers? Am I doomed?

[huntc]

Oh this is strange... I re-installed the Onion firmware, configured the WiFi via the wifisetup command, got that working, re-installed the 22.03 image, and now I can see "radio1" as well as "radio0" via uci show wireless. It seems that some config has been carried over, despite using sysupgrade -n. That all said, the WiFi doesn't appear to be working so I think I'm still up for not having two radios. Here's my current config:

wireless.radio0=wifi-device
wireless.radio0.variant='mt7628'
wireless.radio0.country='US'
wireless.radio0.hwmode='11g'
wireless.radio0.htmode='HT40'
wireless.radio0.channel='auto'
wireless.radio0.disabled='0'
wireless.radio0.device_mode='apsta'
wireless.radio0.op_mode='preference'
wireless.radio0.type='mac80211'
wireless.ap=wifi-iface
wireless.ap.device='radio0'
wireless.ap.mode='ap'
wireless.ap.network='wlan'
wireless.ap.ifname='ra0'
wireless.ap.encryption='psk2'
wireless.ap.key='some-other-key'
wireless.ap.disabled='0'
wireless.ap.ssid='Omega-AAAA'
wireless.sta=wifi-iface
wireless.sta.device='radio0'
wireless.sta.mode='sta'
wireless.sta.ifname='apcli0'
wireless.sta.encryption='psk2'
wireless.sta.network='wwan'
wireless.sta.led='omega2p:blue:wifi'
wireless.sta.disabled='0'
wireless.sta.key='some-key'
wireless.sta.ssid='some-network
wireless.@wifi-config[0]=wifi-config
wireless.@wifi-config[0].key='some-key'
wireless.@wifi-config[0].ssid='some-network
wireless.@wifi-config[0].encryption='psk2'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='platform/10300000.wmac'
wireless.radio1.channel='1'
wireless.radio1.band='2g'
wireless.radio1.htmode='HT20'
wireless.radio1.disabled='0'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'

[crispyoz]

@huntc I can see you are trying a lot of different things, but may I suggest a more structured approach. OpenWrt 22 is not supported by Onion, however with a bit of work you can get it to work and I have some running currently under test for several months. However if it's the namespaces you want to resolve, perhaps go back to the standard Onion OpenWrt 18 firmware so you are only dealing with a single issue.

I have some recollection of OpenWrt 22 config hanging around when I was experimenting some time ago. The quick fix was to perform a factory reset before running sysupgrade.

[luz]

@huntc while I can't help much with the particular issue you seem to have (because in my setup wifi works great), I spent quite some time to get OpenWrt 22.03.0 working on Omega2S for my applications. There are a number of problems around GPIO and GPIO based i2c/spi, as described in this old forum post of mine.

In the meantime, I have solutions (in the form of patches) for all these problems, in particular for the (IMHO unusably) weird auto-numbered GPIOs. If you or anyone else here is interested, I can share those patches - I'd need to cleanup a bit to make them work for the standard Omega2S device target, as I normally build for a modified Omega2S target with a different device tree. Just let me know.

Of course I can also share my known working /etc/config/network and /etc/config/wireless if that helps, but these are non-standard as well.

[huntc]

@crispyoz Thanks. I'll stick with the blessed path then. Makes more sense commercially anyhow.

[huntc]

@luz Thanks so much for your reply. I did notice your other post before. I think I need to follow a blessed path with Onion given the commercial implications of support. Thus, I'll abandon my pure OpenWrt trials for now.

[timj]

@crispyoz is what you have running under test an Onion firmware version running with OpenWrt 22? We have a dependency on Python 3.9 and we would like to also use the stm32flash library that was introduced in OpenWrt 21. Would your version be available to trail, maybe from a branch?

[crispyoz]

@timj My devices on test are for testing some customised network functionality, as @luz mentioned there are some issues with GPIO and I'm experiencing some strange PWM issues. Once I have time to work through and resolve some of these then I'll be happy to share any changes.

If you're keen to progress this, perhaps start a new thread and everyone can chip in their experiences.

[rdot]

@luz Just seeing your post here. While it's a couple months old, if you're still willing, I'd love to get any patches or info you have to make it work. Seems like Onion's dropping the ball on keeping things up to date.

I'm in the process of updating to compile on the latest GCC with Python3 under Ubuntu 22.04 so if you'd be ok with it, I'd like to share your patches back to all once I get things wrapped up.

[luz]

@Rob-Dautel of course I can share the patches. As the forum does not allow to attach .zip, please download the patches from my website here, these are diffs against a completely unmodified OpenWrt 22.03.2 checkout.

These work in my builds, but I can't test right now if these work with the standard Omega2(p) build target settings (as I use different ones for my targets), but I hope so.

• 251..253 add support for modern gpio cdev and for DT overlays (but the respective options need to be enabled in menuconfig to actually enable these features)

• 256 is cosmetic only, it reduces the inevitable message about the "broken flash reset" to a single line, because, yes, that's how things are on the omega2(s)+, it may not recover from unexpected reboots without powercycling the SPI flash chip (that's why reference schematics do exactly that at hardware reset). But I don't need a multiline catastrophy trace about this in every boot log...

• 257 and 258 finally restore the normal GPIO numbering starting at 0.

[rdot]

@luz said in Installing OpenWrt 22.03 on an Omega2S+:

because, yes, that's how things are on the omega2(s)+, it may not recover from unexpected reboots without powercycling the SPI flash chip (that's why reference schematics do exactly that at hardware reset)

Thanks for the zip file, I really appreciate it! Also thank you for the comment above. We have a custom setup too and we've been seeing odd failures where we let the device run overnight and at some point it appears to factory reset itself. Our board does not have the HW reset circuit so I'd bet we're seeing the serial flash hang. Gotta go add that circuit and see what happens.

Thanks again!

[luz]

@rdot said in Installing OpenWrt 22.03 on an Omega2S+:

We have a custom setup too and we've been seeing odd failures where we let the device run overnight and at some point it appears to factory reset itself.

This does not sound like something that could happen because of the "broken flash reset" to me.

To get a factory reset, active and quite specific write operations to the flash must happen (wiping the overlay partition). I cannot see how this could possibly be caused by the "broken reset" problem.

The "broken reset" issue is simply that the SPI flash chip must be in 3-byte address mode at the moment the MT7688 SoC resets, otherwise it won't reboot.

To access flash beyond 16MB, the SPI flash must be set to 4-byte mode. On systems without the "broken reset" problem, the SPI flash driver keeps the chip in that mode all the time because it is more efficient. On Omega2 and similar systems, the driver switches back to 3-byte as soon as possible, to minimize the periods of time when a reset would lead to a stuck system. Still, the problem cannot be avoided entirely, if you get a hardware reset exactly in the one of the remaining (short) periods of time when the SPI is in 4-byte mode, you're out of luck.

So if you don't need the ability to hardware-reset the SoC, you also don't need the extra circuitry which removes power from the SPI flash chip during reset (and thus resets it to 3-byte mode).

I'm not sure if it can happen that the MT7688 SoC internally hard-resets (brown-out, watchdog, maybe?) - if it can and does, not even the external circuit could avoid the hang.

But during normal operation, with no hardware reset involved, all this can't be what's causing your problem, IMHO.

[Chris Morgan]

Does it sound like we'll get official 22.03 support on Omega2s+ at some point?