@crispyoz, @matiaslao: sorry for not responding. Unfortunately this forum does not have an RSS feed, so I sometimes forget checking regularily. Anyway, I hope your reset issue could be sorted out in the meantime. If I remember the difference between v23.5 and older versions correctly, the broken-flash-reset in the device tree has become a standard feature of the mtd/spi-nor subsystem, while before the workaround was a specific patch with no DT option, and implemented differenty. In the new driver (if I am reading drivers/mtd/spi-nor/core.c correctly), the chip is kept in 4-byte mode most of the time, and only reverted to 3-byte when the device is removed or a shutdown occurs. echo c >> /proc/sysrq-trigger crashes the kernel immediately, so the spi-nor driver will not get a chance to switch back to 3-byte and the reboot will fail. The old workaround probably switched forth and back between 4-byte and 3-byte for every flash access, so a HW reset or kernel crash while no flash access was actually ongoing was fine.

@Patrick-Mischler Does anything show on the console? I mean if you connect the device to the USB on your computer and run a terminal application to receive the output from the Pro, does it show anything at all? Let us know if you are running windo$e or *nix on your computer so we can troubleshoot.

@Antony If you're using the standard Warp Core driver some of this stuff is not functional and there is no documentation. If you are using the OpenWrt driver you can refer to the relevant documentation here. Keep in mind that altering some of this stuff may breach the law in your jurisdiction.

This is fixed in u-boot 1.1.3 release date 18th November 2020. There is another version 1.1.3 with release data Feb 2019, which still has this bug.

@t3therdev welcome! The USB pins exposed on the expansion header are the same USB signals that are routed to the USB-A Host Port. You can use one or the other at one time, but not both. You can see this in the Omega2 Pro schematic. The same nets are connected to the USB host port and the expansion header:

@Lazar-Demin I used a custom config created with menuconfig an there i activated only the omega2 pro for device and changed some packages. And then after building i see no bin file but compilation was successfull. So i tried the minimal config. And then i get all bin files except the pro. Maybe i changed something i shouldnt change ;-). But i think if im using the minimal config with the python script the config should be overwritten? Anyway whats the best way to reset the build config without setting up the whole build system again? Maybe that helps...

@Antony Again, like I mentioned in a previous post, it would be helpful if you gave some background and context on what you're doing. Following the How to Ask for Help on this Forum guidelines when posting will lead to getting better help from the community. Without context on whether you're, for example, trying to build your own firmware or trying to find Onion's released firmware, it's difficult to get to the bottom of the issue.

Will do!

@Antony Take a look at /etc/hotplug.d/00-netstate, you can use hotplug to execute commands on state change for the wwan interface. Below is a sample of a script I used to update the listen iterface for nginx web server, when the wwan interface connected to wifi, you could update it for the action ifdown: echo "Starting interace hotplug ${DEVICE} Action: ${ACTION} Interface: ${INTERFACE}" >> /tmp/cblog if [ "$ACTION" = "ifup" -a "$INTERFACE" = "wwan" ]; then echo "IFUP ${DEVICE}" >> /tmp/cblog echo "Run ip setup script for device: ${DEVICE}" >> /tmp/cblog echo "listen $(ip -o -4 a s apcli0 | awk '{ print $4 }' | cut -d/ -f1):80;" > /etc/nginx/listen_ip fi

@crispyoz thanks i'll give that a try. I'm always a bit wary if removing system-sounding things

@György-Farkas you were right, hardware flow control was active and once I disabled it the console worked. Thanks again for your help!

@Matt-Gessner-0 while it is technically possible to do some development on the omega, it is quite impractical. You will quickly run out of capacity and patience and you'll end up using a more suitable build environment. Save youself the time and heartache. Take a look at the cross compiling docs it is easy to set up a build environment and use the better resources of a proper development platform

@Matt-Gessner-0 See the Omega2 Pro guide here: https://onion.io/omega2-pro-get-started/

Thank you very much, will order one then

@Junxiao-Shi said in Unable to connect to non-alphabet SSID: I reflashed my device with standard OpenWrt 18.06 and it works great. Procedure and experience on my blog: https://yoursunny.com/t/2019/omega2pro-openwrt/ Excellent, thanks!

I'm going to take the battery to a friends house tomorrow that has a charger for rc cars and test it if anyone has any suggestions on troubleshooting.

This solution did not fix the problem in my case. The problem was that there was an extra line "379" which must have had one of those un-allowed line endings or the carriage return on line "378". This was causing the /usr/bin/oupgrade: local: line 378: not in a function error. Deleted the extra blank line and all was fixed.

@Lazar-Demin Thank you.