I recently acquired an Openwrt One and it worked reliably for a while but from one day to the other without me doing anything the router did not boot up again. It was repeatedly trying tough. From the LED side of things it was always a loop of every led being lit than only the white boot one and than nothing until the cycle repeated.
I looked into it with via the USB-C Debug Console in the front and some AI help to decipher the output. The boot logs seemed fine but it always returned to the boot selection menu. It was also no help to switch to NOR or NAND.
AI was concluding that the hardware is at fault. It was suspecting a sticky reset button but with the console I could rule that out. Interestingly enough I also happened to check the GPIO and the input labeled reset was active. I could not get it to either ignore this input or to reset it to inactive.
I have by now tried everything I could think of and nothing worked so I am reaching out in the hopes anyone can help me. My money currently is on a hardware fault which would be very unideal.
I followed the steps 1:1 like the docs told me under the "Flashing image" section. But I did not get to the LED getting green. I ended up with a red LED and the message:
on
starting USB...
Bus xhci@11200000: xhci-mtk xhci@11200000: hcd: 0x0000000011200000, ippc: 0x0000000011203e00
xhci-mtk xhci@11200000: ports disabled mask: u3p-0x1, u2p-0x0
xhci-mtk xhci@11200000: u2p:1, u3p:1
Register 200010f NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus xhci@11200000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
** Bad device specification usb 0 **
Couldn't find partition usb 0:1
Can't set block device
I got into the console and used "usb reset" and "usb start" but with no change to the "0 Storage Devices" part.
Inspecting the drive itself I can not make anything out that is suspicious:
[notroot@SnowWhite:~]$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 14.65 GiB, 15728640000 bytes, 30720000 sectors
Disk model:
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1f09ec41
Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 30719999 30717952 14.6G 83 Linux
[notroot@SnowWhite:~]$ lsblk -f /dev/sdc
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdc
└─sdc1 vfat FAT32 OPENWRT 2852-D68F 14.6G 0% /run/media/notroot/OPENWRT
[notroot@SnowWhite:~]$ ls /run/media/notroot/OPENWRT
openwrt-mediatek-filogic-openwrt_one-factory.ubi openwrt-mediatek-filogic-openwrt_one-snand-preloader.bin
But maybe u guys have a better eye for this and can spot anything or if you want me to try something or need more info be sure to message me. ^^
Specifically this Note: Note: You may have to try other USB drives formatted to FAT32. There are observations that some USB drives have incompatibility issues. Try using a MBR partition table. If you get a Bad device specification usb 0 error from u-boot, increasing the delay may help:
U-Boot Shell
OpenWrt One> setenv usb_pgood_delay 4000
OpenWrt One> usb reset resetting USB... scanning usb for storage devices... 1 Storage Device(s) found
Tried out some more flashing stuff and now I think I bricked it completely. Not even any LED except the power one go on if I plug in the power cable and the console does not give out anything. The last thing printed (repeatedly) was:
Regarding the docs you send, I did read through it but the steps are the same for flashing.
In regards to the MBR. It is a DOS (MBR) partition table on the stick so that should not be it. And I did not get the chance to test out the delay.
Next steps, possibly:
Boot through UART (docs) meaning I try to push a system into ram and try to boot that seems like the last resort now.
Also also
I descoverd a production fault on the PCB. Two pins of the GPIO are soldered together on the back. Althoug I doubt it has anything to do with the fault because the device worked for a while and this must have been the case since I got it.
It's not that I would have not believed you. I just want to make sure that someone with the same hardware can better comment on that. But yes, looks suspicious.
Mine is clean FWIW and I couldn’t even begin to guess what that solder bridge could do. I do know it’s a defect when you see solder bridges where there shouldn’t be one. Suggest you should think toward getting it replaced.
You guys are absolutely right. I will return it and hopefully get a working replacement.
Thanks for all the help. I really appreciate you taking the time out of your day to help me. ^^
Final update on trying to solve the initial problem
Ultimately I could not determine what the real cause of the problem seems to be. I tried the UART boot but even that does not seem to work with the error being a timeout.
mtk_uartboot - 0.1.1
Using serial port: /dev/ttyACM0
Handshake...
hw code: 0x7981
hw sub code: 0x8a00
hw ver: 0xca00
sw ver: 0x1
Baud rate set to 115200
sending payload to 0x201000...
thread 'main' panicked at src/bootrom.rs:53:53:
called `Result::unwrap()` on an `Err` value: Custom { kind: TimedOut, error: "Operation timed out" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
./uart_ram_boot.sh: line 15: 3150 Aborted (core dumped) "$MTK_UARTBOOT" --aarch64 --brom-load-baudrate 115200 --bl2-load-baudrate 115200 -s /dev/ttyACM0 -p "$BL2" -f "$FIP"
It is very likely to be the fault of a wrongly set up TFTP server. Connecting with a client to it over localhost worked. Connecting over a network (Ethernet cable) did not. I tried for like 3 hours to fix it and now I do not care enough anymore as I can not be bothered to start over with the setup.
The good side of this
Well for what it is worth at least I am happy I learned a lot from this. A lot of first times doing anything like this.
Also a good thing is I somehow reverted the device back to the boot loop state I had at the time I created this thread. After the failed UART boot it just necromanced itself back to the living and the LEDs started glowing again.
