I've bricked my device. I am unable to enter failsafe as I don't think it gets that far in the process (the LED used to blink when it was ready to enter failsafe, but it no longer does that).
It was bricked after I ran a sysupgrade on the device.
What should I do?
Look for recovery mode in the bootloader, if there is any. Some vendors build e.g. TFTP based recovery into u-boot
You could get better advice after you tell which device it is.
It's a YunCore XD3200.
How do I look for recovery mode in the bootloader?
Use search tools.
Check wiki page for that device here, in Openwrt etc. Check ddwrt site. Check the vendor's help pages for that device.
In the commit adding support for that device, the bootloader is u-boot so it's relatively likely that there is a recovery mode through tftp. https://patchwork.ozlabs.org/patch/576146/
If you can open the device and locate serial TTL pins you can connect to it with a USB-to-TTL adapter and you should be able to communicate with uboot to find out how it is set up.
@pepe2k has added support to his custom u-boot for other yuncore devices so he might know if the stock u-boot has some kind of recovery mode and how to operate it.
I'll see if I can find a USB-to-TTL adapter, I've never done this before, so I'm pretty hazy on how I would go about doing that. How do I use the adapter to find out how it is setup? Are there any instructions anywhere?
Thank you!
The hope is that the bootloader has already a function for recovery that kicks in on its own, and you just need to set up a tftp server, and set yout PC to a specific IP address for recovery, but I don't know that device, nor what yuncore does usually, so it would be best to see that first.
Only info I could find is another yuncore product here https://wiki.openwrt.org/toh/yuncore/cpe-880 it seems to be pretty default, and it has TTL pins soldered already.
It is a bit time-consuming, especially if it is your first experience with serial and bootloaders, so be warned.
this is a usb-ttl adapter I also use (not affiliated with that seller, it's just one of many selling the same stuff).
TTL pins are usually 4, a ground, a Tx (transmit) a Rx (receive) and a power pin. If you are lucky they are already soldered or there are clear pin holes you can solder pins on, if you are not, they are accessible from contact pads. this is an example of device with obvious pin holes for TTL.
Find out what of the pins is the power pin with a multimeter, and DO NOT use it (the usb-ttl adapter is powered by USB anyway), the other 3 pins you can simply find out by trying them (as there is no power involved, mistakes don't damage the board).
From the PC, the usb-ttl adapter is seen as a serial adapter (because it is a serial adapter after all), and so you should use putty/kitty or other programs set to talk to serial, most common settings (also used in the other yuncore device above) are
Bits per second: 115200
Data bits: 8
Stop bits: 1
Parity: None
Flow control: None
Then you should see text scrolling by when you power up (see the "bootloader boot log" in the entry about the other yuncore device for an example).
U-boot (the bootloader) usually writes "hit any key to stop autoboot" and in this time you should write something to stop boot sequence. Some devices require a specific word (tp-link wants "tpl") but for many u-boots any keyboard key will work.
Once you pressed a key to stop the boot, you are in the bootloader's console, assuming that the u-boot wasn't modified to show a custom menu (on some devices it will say "press 1 to do X, press 2 to do Y), write "help" to get a list of commands.
If it has "tftp" or "tftpboot" in the list, you can recover it manually by tftp.
"printenv" to see what are its settings, it should show a "serverip" and "ipaddr" variables with IPs in them.
serverip is the IP you must place the tftp server at so you can transfer the firmware over, ipaddr is the ip address of the device itself.
you can usually change them (temporarily) by writing "setenv ipaddr write-new-address-here", note that basic networking still applies. The devices must be in the same subnet, so having these two IPs set up as 192.168.1.1 and 192.168.1.2 will work, while if yous et them as 192.168.2.1 and 192.168.1.2 will not work
If you got to this point, you can install a tftp server in your PC, there are plenty of tutorials, it's usually very easy as tftp is a very simple protocol used by bootloaders and other very simple systems.
Set your PC to a fixed address specified in "serverip" and connect the ethernet cable to the device.
The command to transfer the file is either tftp 0x81000000 code.bin or tftpboot 0x81000000 code.bin
When transfer went well, you must erase the flash partition with firmware and write a new firmware image to that flash partition.
I don't know how that device is set up in LEDE so I'm not going to post the erase/write commands that could screw it up even further (there are partitions with hardware wifi calibration data, if these are erased the wifi will not work anymore), see if you can contact the guy that made that patch I linked above (there is an email in the commit description) to get this information.
@bobafetthotmail thank you for the sound advice! I was able to get it working by doing the following:
Good. Glad that you sorted out your issue. 
Could you write down the info about that device (also with photos of the board and bootlogs, and this recovery procedure if possible) in the OpenWRT wiki like it was done for the other device?
(entries from there will be eventually imported in LEDE wiki, I don't know if @tmomas has finished his tests with our table of hardware, until he is done with that the hardware articles here can be mass-deleted)
The ToH is in productive use since 24.12.2016, i.e. no testing on the dataentries any more.
But you are talking of a devicepage, or installation instructions. Those were never part of my testing. In fact, we currently do not have devicepages in the LEDE wiki, not even a finalized template for them -> Something to be worked on.
If you want to create a devicepage: https://wiki.openwrt.org/meta/create_new_device_page (must be logged in to create one)
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.