I have a GL.iNet X750 (spitz, v1) that was running the stock firmware and decided to "upgrade" to plain OpenWRT using the 23.05 sysupgrade image on the device's wiki page. When I uploaded the firmware I got a warning about device incompatibility (it said something about x750-nor) which I foolishly decided to ignore. Now the device is dead. I hooked up serial and all I get is
This is whether I hold the reset button pressed or not. I never progresses beyond this. No LED blinking either.
So if you try to go down that route: don't ignore the warning!
Edit: I'm wondering whether I need to reflash u-boot onto the SPI flash chip. Can I download the u-boot image anywhere?
I see you have also asked the same question on GL's forums:
As they are supporting you with how to recover via uboot to stock GL firmware, can this be solved as when you are back to the stock firmware it will be easier to help you switch to actual Openwrt.
I don't think I'm getting support on the GL.iNet forum, they don't understand...
Do you know where I can get a fresh u-boot to flash to the SPI chip? A quick look at the sysupgrade image doesn't look like u-boot to me..
Thanks for the reply. I am quite familiar with the OpenWRT devices in general and have done the u-boot rescue/flashing process on others. What is happening is that I have two GL.iNet X750 purchased in 2019 that don't behave the way they're "supposed to".
One is currently working, the other I evidently flashed bad firmware and I don't quite know which partition it messed-up.
What I observe on both devices:
they have 5 LEDs: SYS, WAN, 2G, 5G, 4G (2G/5G are for Wifi and 4G is for cellular)
at power-on the 4G LED is brightly lit and the WAN and 5G are dimly lit
they never blink, whether I keep reset pressed or not
on the one that boots the LEDs also never change, even if I fiddle with the LED settings in Luci, I can't affect the LEDs in any way
if I keep reset pressed indefinitely at boot on the one that works it never boots into either normal or recovery
on both the u-boot serial output never progresses past what I posted
So I don't get any indication when I should release the reset button to get into the u-boot recovery...
I also tried:
if I arping 192.168.1.1 while booting normally then at some point I get 8 responses, i.e., the firmware has 192.168.1.1 for 8 seconds; but if I hold down reset it never gets there, so it must expect me to release reset before that
So all the replies I get tell me to use the u-boot recovery but I can't get into it...
Edit: I did a few more tests with a timer. If I hold down reset for 10 seconds or less after power-on the working device boots normally (it responds to 7-8 arpings to 192.168.1.1 around 30s after boot and comes up with its assigned IP address 1m25s after power-on). If I hold down reset 11 seconds or longer it never responds to either 192.168.1.1 or its assigned IP address. I tried a couple of times to release between 10-11 seconds and I never see it sticking to 192.168.1.1, which would indicate recovery mode. So I can't get the working device into recovery (I had hoped to figure out the timing and then apply it to the non-working one).
I hope you took at least a full backup of the bricked device beforehand, to restore your own wifi calibration/ ART and other device specific data (MAC addresses, etc.) from the bricked device - or you aren't going to have much fun with the 'recovered' device anymore.
I did make a backup, where do I find instructions for how to restore that type of settings data?
The recovered device's 2.4Ghz Wifi died 3 years ago so it's an ethernet/cell router at this point. The other device's 2.4Ghz Wifi died a few months ago, prob will have to replace it. The LED drivers on both devices are bust. Sounds like someone cut corners big time!
Sounds good - if I recall, there is a MCU update which runs all the LED's, and that is part of their build... complicated perhaps, as the core SoC could handle this, but then there is the 4g modem interface...
