Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
docs:guide-user:troubleshooting:generic.debrick [2018/09/15 14:04] – ToC Cleanup | Removed broken external links | Added external link names jw0914v2docs:guide-user:troubleshooting:generic.debrick [2018/12/19 12:54] – old revision restored (2018/09/14 19:51) per @tmomas' view jw0914
Line 8: Line 8:
     - or desolder the flash chip, connect it to some device, that does give you write access to it and restore the bootloader. You did perform a [[docs:guide-user:installation:generic.backup]], right?     - or desolder the flash chip, connect it to some device, that does give you write access to it and restore the bootloader. You did perform a [[docs:guide-user:installation:generic.backup]], right?
  
-  * If you need help **[[docs:techref:hardware:soldering|soldering]]**+If you need to solder, you can find some help here:  
-    * [[docs:techref:hardware:port.jtag|JTAG Port]] +  * -> **[[docs:techref:hardware:soldering]]**[[docs:techref:hardware:port.serial|Serial Port]][[docs:techref:hardware:port.jtag|JTAG Port]]
-    * [[docs:techref:hardware:port.serial|Serial Port]]+
  
 ---- ----
  
-  * [[https://forum.openwrt.org/viewtopic.php?id=35462|Un-brick a WG302]]+  * [[https://forum.openwrt.org/viewtopic.php?id=35462]]
  
-===== Ways to Recover =====+==== As for the proper ways to recover a "bricked" router ====
  
-==== boot_wait ====+=== boot_wait ===
 The single best thing you can do is have boot_wait set, meaning that all you have to do is TFTP a new firmware. At one time the reflashing instructions included a an exploit for the Linksys firmware that set the boot_wait variable; as time progressed and Linksys eventually fixed the bug (after several failed attempts) we found that people were flashing to other firmwares for the sole purpose of setting boot_wait so they could reflash to OpenWrt. We figured this was somewhat pointless and altered the instructions to indicate that you could safely reflash to OpenWrt without setting boot_wait. The single best thing you can do is have boot_wait set, meaning that all you have to do is TFTP a new firmware. At one time the reflashing instructions included a an exploit for the Linksys firmware that set the boot_wait variable; as time progressed and Linksys eventually fixed the bug (after several failed attempts) we found that people were flashing to other firmwares for the sole purpose of setting boot_wait so they could reflash to OpenWrt. We figured this was somewhat pointless and altered the instructions to indicate that you could safely reflash to OpenWrt without setting boot_wait.
  
-==== JTAG ====+=== JTAG ===
 It's one of those amazingly useful things that allows you to recover from pretty much anything that doesn't involve a hardware failure. While the JTAG can technically be used to watch every instruction and register as the system boots, the recovery software only uses it for DMA access to the flash chip, making it somewhat a blind recovery mechanism. It's one of those amazingly useful things that allows you to recover from pretty much anything that doesn't involve a hardware failure. While the JTAG can technically be used to watch every instruction and register as the system boots, the recovery software only uses it for DMA access to the flash chip, making it somewhat a blind recovery mechanism.
  
Line 30: Line 29:
 FIXME: OK, you have told us what NOT TO DO, now please tell us what TO DO! Let us take the most usual case where someone has installed a bad image on their router. The usual recovery methods have failed, forceing the user to to go to JTAG. The user has used to good OpenWrt Documentation to set up the cables and hardware and software. The user is now sitting at an OPENOCD, URJTAG, or Hairydairymaid prompt. The user has never used a JTAG tool before. What should he do now? What backup commands should he issue, before trying his fix? Some say that by erasing some partitions it will cause the system to start working, well enough to use the other recovery methods. OK, but what exactly is the correct procedure? If this does not work, is there a way to install a good openwrt image directly using JTAG? FIXME: OK, you have told us what NOT TO DO, now please tell us what TO DO! Let us take the most usual case where someone has installed a bad image on their router. The usual recovery methods have failed, forceing the user to to go to JTAG. The user has used to good OpenWrt Documentation to set up the cables and hardware and software. The user is now sitting at an OPENOCD, URJTAG, or Hairydairymaid prompt. The user has never used a JTAG tool before. What should he do now? What backup commands should he issue, before trying his fix? Some say that by erasing some partitions it will cause the system to start working, well enough to use the other recovery methods. OK, but what exactly is the correct procedure? If this does not work, is there a way to install a good openwrt image directly using JTAG?
  
-==== SBC ====+=== Serial === 
 +Serial consoles are great, there's just one problem - the routers run on 3.3v and a normal PC serial port puts out +/-12v, easily frying a router. This means that a level shifter such as a max233 is required (free samples can be obtained from Texas Instruments or Maxim), and adding the ICs and caps required is beyond the ability of most users -- luckily there's a shortcut. Most cellphones are either USB or 3.3v serial, so the data cable for a 3.3v cellphone can be used to make an easy and professional looking serial console connection (e.g the DKU-5 Cable for Nokia handsets). You only need to identify and connect 4 wires (vcc, rx, tx, gnd) -- and if your cable uses a pl2303 you can skip the vcc connection. 
 + 
 +Serial console allows you to interact with the CFE command line, watch the kernel boot and console access to linux. This is probably the only way you'll every get any meaningful feedback about the device boot up. 
 + 
 +== Serial modes == 
 + 
 +Some [[docs:techref:hardware:port.serial#serial_modes| serial modes]] allow you to upload a binary directly to ram or to the flash memory from the serial connection, allowing you to repair a broken bootloader
  
 === Arduino === === Arduino ===
Line 40: Line 46:
 If you don't have a USB serial ttl but have a Raspberry Pi, you can use it to connect to the router's serial pins. The Raspberry Pi's uart works at 3.3V which is the correct voltage for most routers. Connect the GND to GND, the RX to TX, and the TX to RX. Leave VCC (or 3.3V) unconnected (that is, in the end you will only be connecting 3 pins out of 4). If you don't have a USB serial ttl but have a Raspberry Pi, you can use it to connect to the router's serial pins. The Raspberry Pi's uart works at 3.3V which is the correct voltage for most routers. Connect the GND to GND, the RX to TX, and the TX to RX. Leave VCC (or 3.3V) unconnected (that is, in the end you will only be connecting 3 pins out of 4).
  
-==== Serial ==== +=== WIFI ===
-Serial consoles are great, there's just one problem - the routers run on 3.3v and a normal PC serial port puts out +/-12v, easily frying a router. This means that a level shifter such as a max233 is required (free samples can be obtained from Texas Instruments or Maxim), and adding the ICs and caps required is beyond the ability of most users -- luckily there's a shortcut. Most cellphones are either USB or 3.3v serial, so the data cable for a 3.3v cellphone can be used to make an easy and professional looking serial console connection (e.g the DKU-5 Cable for Nokia handsets). You only need to identify and connect 4 wires (vcc, rx, tx, gnd) -- and if your cable uses a pl2303 you can skip the vcc connection. +
- +
-Serial console allows you to interact with the CFE command line, watch the kernel boot and console access to linux. This is probably the only way you'll every get any meaningful feedback about the device boot up. +
- +
-=== Modes === +
- +
-Some [[docs:techref:hardware:port.serial#serial_modes| serial modes]] allow you to upload a binary directly to ram or to the flash memory from the serial connection, allowing you to repair a broken bootloader +
- +
-==== WIFI ====+
 If by chance the lan bridge is not working after flashing and the router is inaccessible, it might be worth a shot to use the serial instructions to add a serial port and configure Wifi. If ssh connection via Wifi is working a newer/bugfixed/stable image can be copied via scp and then installed via sysupgrade command. If by chance the lan bridge is not working after flashing and the router is inaccessible, it might be worth a shot to use the serial instructions to add a serial port and configure Wifi. If ssh connection via Wifi is working a newer/bugfixed/stable image can be copied via scp and then installed via sysupgrade command.
  
Line 61: Line 58:
  
  
-===== Warnings =====+===== Stupid things people do =====
  
-==== Pin shorting ====+Pin shorting
  
 In the past we used to suggest that people shorted a few pins of the flash; when CFE booted and attempted to perform the CRC32 there would be a flash read error which would change the outcome of the CRC and the resulting failure would force CFE into recovery mode. It's a great trick, but over the years we've learned that people are idiots and will take that as an invitation to poke mangle and short just about every pin on the device based on some irrational belief that if they find the right pin everything will magically work again. You do not want someone paranoid at the thought of breaking the device scraping up every single electrical connection on the device -- it never ends well, and generally results in the flash chip or the router being damaged in the process. In the past we used to suggest that people shorted a few pins of the flash; when CFE booted and attempted to perform the CRC32 there would be a flash read error which would change the outcome of the CRC and the resulting failure would force CFE into recovery mode. It's a great trick, but over the years we've learned that people are idiots and will take that as an invitation to poke mangle and short just about every pin on the device based on some irrational belief that if they find the right pin everything will magically work again. You do not want someone paranoid at the thought of breaking the device scraping up every single electrical connection on the device -- it never ends well, and generally results in the flash chip or the router being damaged in the process.
Line 75: Line 72:
 Depending on which pins are shorted/broken, it may be possible to access CFE but not to access the rest of the flash. Meaning CFE boots fine but can't read or write the firmware. This can be confirmed by JTAG. Depending on which pins are shorted/broken, it may be possible to access CFE but not to access the rest of the flash. Meaning CFE boots fine but can't read or write the firmware. This can be confirmed by JTAG.
  
-==== Wrong CFE ====+Wrong CFE version -
 Loading the wrong CFE version can also lead to devices which boot into CFE but are unable to write to the flash, or are unable to initialize the networking. Loading the wrong CFE version can also lead to devices which boot into CFE but are unable to write to the flash, or are unable to initialize the networking.
  
 And yes, there are actually a few obscure versions that require the firmware to be named "code.bin" or a specific port to be used. Unfortunately nobody can remember exactly which devices, leading to all sorts of superstition. And yes, there are actually a few obscure versions that require the firmware to be named "code.bin" or a specific port to be used. Unfortunately nobody can remember exactly which devices, leading to all sorts of superstition.
  
-This article is based on: [[https://forum.openwrt.org/viewtopic.php?id=11304|Everything you need to know about broadcom hardware (Part 1)]]+This article is based on: [[https://forum.openwrt.org/viewtopic.php?id=11304]]
  
 ---- ----
  
-  * [[https://forum.openwrt.org/viewtopic.php?pid=128790#p128790|Report from failed attempt with TL-WR1043ND]]+  * [[https://forum.openwrt.org/viewtopic.php?pid=128790#p128790]]
  
  
Line 90: Line 87:
 In this case, someone manage to wipe out the [[docs:techref:bootloader]] of his [[/toh/d-link/dir-825|D-Link DIR-825]]. In this case, someone manage to wipe out the [[docs:techref:bootloader]] of his [[/toh/d-link/dir-825|D-Link DIR-825]].
  
-The full originals by vavasik can be found [[http://translate.google.de/translate?hl=de&ie=UTF-8&sl=auto&tl=en&u=http://webcache.googleusercontent.com/search%3Fq%3Dcache:wZfxY3lVVfQJ:forum.ixbt.com/topic.cgi%253Fid%253D14:49819%2Bhttp://forum.ixbt.com/topic.cgi%253Fid%253D14:49819%26cd%3D1%26hl%3Den%26ct%3Dclnk%26source%3Dwww.google.com&prev=_t|here]].+The full originals by vavasik can be found at: 
 +  * [[http://translate.google.de/translate?hl=de&ie=UTF-8&sl=auto&tl=en&u=http://webcache.googleusercontent.com/search%3Fq%3Dcache:wZfxY3lVVfQJ:forum.ixbt.com/topic.cgi%253Fid%253D14:49819%2Bhttp://forum.ixbt.com/topic.cgi%253Fid%253D14:49819%26cd%3D1%26hl%3Den%26ct%3Dclnk%26source%3Dwww.google.com&prev=_t]]
  
   - Open the Router’s case   - Open the Router’s case
Line 143: Line 141:
  
   * 6 Now that the LPT ADAPTER is done and its wires are soldering to the chip, you have to connect the other side to LPT interface of your computer and also to connect the 3,6V external battery array. You must see the light of some LEDs on board.   * 6 Now that the LPT ADAPTER is done and its wires are soldering to the chip, you have to connect the other side to LPT interface of your computer and also to connect the 3,6V external battery array. You must see the light of some LEDs on board.
-  * 7 So, if everything is done properly, download the software SPIPGMW ([[http://rayer.ic.cz/programm/programm.htm#SPIPGM|<broken link>]]) and run it in a DOS session. It is good use the key “i” in order to check if the chip is correctly identified.+  * 7 So, if everything is done properly, download the software SPIPGMW at the following address: [[http://rayer.ic.cz/programm/programm.htm#SPIPGM]] Run it in a DOS session. It is good use the key “i” in order to check if the chip is correctly identified.
  
 SPIPGMW.EXE /i SPIPGMW.EXE /i
Line 161: Line 159:
   * 13 - Check the success of recording operation by comparing recorded file and recently dumped file fc / b filename_1 filename_2. Files must have exactly the same content.   * 13 - Check the success of recording operation by comparing recorded file and recently dumped file fc / b filename_1 filename_2. Files must have exactly the same content.
   * 14 - Disconnect LPT cable and external power supply, try to boot. Look at the serial console terminal program and follow the boot process. Luckily everything will work fine.   * 14 - Disconnect LPT cable and external power supply, try to boot. Look at the serial console terminal program and follow the boot process. Luckily everything will work fine.
 +
 +  * http://img189.imageshack.us/img189/134/recoveringadir825flashc.jpg
 +  * http://img251.imageshack.us/img251/134/recoveringadir825flashc.jpg
 +  * http://img833.imageshack.us/img833/134/recoveringadir825flashc.jpg
 +  * http://img708.imageshack.us/img708/134/recoveringadir825flashc.jpg
 +  * http://img267.imageshack.us/img267/134/recoveringadir825flashc.jpg
 +  * http://img267.imageshack.us/img267/8935/recoveringadir825flashco.jpg
 +  * http://img209.imageshack.us/img209/134/recoveringadir825flashc.jpg
 +  * http://img513.imageshack.us/img513/134/recoveringadir825flashc.jpg
 +  * http://img171.imageshack.us/img171/134/recoveringadir825flashc.jpg
 +  * http://img403.imageshack.us/img403/134/recoveringadir825flashc.jpg
 +  * http://img593.imageshack.us/img593/134/recoveringadir825flashc.jpg
 +  * http://img522.imageshack.us/img522/134/recoveringadir825flashc.jpg
 +
 +  * http://rayer.ic.cz/elektro/spipgm.htm RayeR's homepage/Programmer SPI FlashROM for parallel port
 +  * http://rayer.ic.cz/programm/programe.htm#SPIPGM RayeR's homepage/Programming - SPIPGM.ZIP ver. 1.8 [79 kB] :
  
 ^SPI FlashROM supported^ ^SPI FlashROM supported^
Line 173: Line 187:
 | M25P128 (16MB)| | M25P128 (16MB)|
  
 +  * [[http://richard-burke.dyndns.org/wordpress/2009/02/programming-an-asus-p5b-bios|Programming an ASUS P5B BIOS | Adventures in Home Computing]]
  
-===== Write via USB =====+ 
 +===== Write flash chip by USB =====
  
 This is the probably easiest way to "burn" a flash chip: It is a cheap (cable ~20 EUR), universal (USB) and multiplatform (many OS) solution. Buy a FTDI cable C232HM-DDHSL-0 (in case of 3.3 Volts), connect the wires to the flash chip as shown below and write the data with [[http://flashrom.org/|flashrom]]. This is the probably easiest way to "burn" a flash chip: It is a cheap (cable ~20 EUR), universal (USB) and multiplatform (many OS) solution. Buy a FTDI cable C232HM-DDHSL-0 (in case of 3.3 Volts), connect the wires to the flash chip as shown below and write the data with [[http://flashrom.org/|flashrom]].
Line 212: Line 228:
 Warning: If you use a FTDI cable for [[docs:techref:hardware:port.serial.cables#prebuilt_cables|serial console]] then you probably must disable the FTDI serial port driver or exclude the product ID 0x6014 for the FT232H chip in the serial driver. Patch for MacOS: Warning: If you use a FTDI cable for [[docs:techref:hardware:port.serial.cables#prebuilt_cables|serial console]] then you probably must disable the FTDI serial port driver or exclude the product ID 0x6014 for the FT232H chip in the serial driver. Patch for MacOS:
  
-<code diff>+<code>
 --- tmp/FTDIUSBSerialDriver.kext/Contents/Info.plist    2012-08-08 14:01:40.000000000 +0200 --- tmp/FTDIUSBSerialDriver.kext/Contents/Info.plist    2012-08-08 14:01:40.000000000 +0200
 +++ /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist     2013-11-17 10:48:54.000000000 +0100 +++ /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist     2013-11-17 10:48:54.000000000 +0100
  • Last modified: 2023/03/18 23:40
  • by ryanc