Hmmm... I got RPi2 and Odroid C2. But you would need to tell me how to connect to serial via GPIO.

I use an odroid c1 running arch/screen, the pinouts are on the odroid site. It is 3.3 TTL works like a charm, if you have some wire you can string. Just TX,RX,GND. pi will work as well I think.

Edit: uart. There is also a 4 pin serial on that board, as well as the GPIO header. You can use either. The connections for the wrtX are on the wiki

(Last edited by anomeome on 28 May 2016, 20:28)

Could you tell sth more about it?
I know that Odroid requires to enable the specific GPIO and after you do all of that, how you open the serial console?

Power must be cut as soon as the power LED turns off (~2s after power on)... please see Firmware Recovery in the wiki.

That's because you're not doing it right =] 
Power switch needs to be turned off immediately upon the Power LED going off (~2s after boot).  IIRC, there's only ~1.5s window for failsafe to be activated once the power LED goes off, but before that and the other lights come back on.

I haven't had the time to troubleshoot that issue on mine, as my WRT1900AC v1 has been doing that for over a year if it's flashed via sysupgrade or via the WebGUI.  I simply installed a 3.5mm jack and flash exclusively via serial with a USB-TTL AJ cable (takes less than 60 seconds to flash, verify nothing went wonky, and the router enters promiscuous mode).

Many don't utilize the 192.168.1.0/24 subnet (router's failsafe IP can also be changed via menuconfig to something other than 192.168.1.1/24), with it simply being easier to tell users to set the env variables for ip and server ip.

However, I will be adding @Sera's suggestion of how to transfer the image via USB vs TFTP to the wiki sometime this week, as I wasn't aware that was possible until they mentioned it.   

Could you elaborate on the SBC method as well (or point me to a link), as that would also be nice to have in the wiki.

(Last edited by JW0914 on 28 May 2016, 20:56)

Yes, but this requires a serial connection, which when using tftp seems counter intuitive. I just expect some reasonable known default, and to just set the required IP on my tftp server. Does not take much to manually assign an IP temporarily on whatever OS, no matter the IP range you use internally.

Edit: Using a SBC is just using the UART of some SBC to communicate with the wrtX. As long as it is 3.3 TTL you should be good with whatever tty emulator you use;screen.minicom etc. It going to vary by SBC/OS so the specifics will have to be ferreted out by the owner, Probably enough that the concept is there just to turn on the light; so to speak.

(Last edited by anomeome on 28 May 2016, 20:50)

My understanding (which I could very well be wrong/misinformed] is that it's not possible to transfer the image via the serial connection alone from PC to router, which is why the LAN cable is required for TFTP.  I wasn't even aware there were other ways to transfer the image until @sera mentioned the USB method the other day

Should the wording in the Wiki about TFTP be modified?

(Last edited by JW0914 on 28 May 2016, 20:53)

@belliash

To start the recovery process -- did you do the following? I apologize if you said you did this already.

Reset router by pressing reset button until PWR light starts to flash {should take ~ 15 seconds}. Then do the power down/on steps.

It appears the reset button step is missing from the current wiki.

It's [reset button] no longer required since failsafe mode was incorporated by default in RC3 (might have been RC2).  In fact, I don't even know if the reset button functions, as I've tried several times to use it, and it's never worked to reset the router.  No lights turn off, router doesn't reboot, nada... though to be honest, I never tried it on stock firmware, so it could very well be the button itself on my router is defective.

(Last edited by JW0914 on 28 May 2016, 21:00)

So you don't recommend he even try since he can't get it to go over?

**EDIT** From what I recall, but could be wrong.. Not using the reset  button only worked if the failsafe system detected the system wouldn't come up clean.

(Last edited by davidc502 on 28 May 2016, 21:03)

Not to my knowledge. I have never used tftp on this particular device. In my experience, with other routers, by whatever method you kick the device into doing a tftp file request, it just uses some predefined IP, and expects a tftp server at some other predefined IP to respond. So I'm just saying that it seems unreasonable that you "have" to have a serial connection to set an IP for tftp; whether that is the case I do not know.

I didn't mean that (I apologize if that's the way it came across), simply that the reset button isn't required to flip between mtd5 & 7.  I've never been able to get my reset button to function on OpenWRT, however it is possible I simply have a defective button, as I've never tried utilizing it on stock.

I would be interested in troubleshooting why this is occurring on the WRT1900AC v1, as mine started doing the same as he's experiencing over a year ago.  It's occurred on RC3 and CC final (haven't tried 15.05.1), as well as trunk on kernels 4.1.x and 4.4.x.  I got sick of it occurring every time I tried to flash via the WebGUI or via sysupgrade, that I installed a 3.5mm jack and now flash via TFTP exclusively.

That's a good point, as the only time I've ever used the recovery procedure is because of a trashed flash.  I'll have to try it when I have some time and report back the results.

(Last edited by JW0914 on 28 May 2016, 21:07)

I'm curious now too... It's been since kernel 4.1 since I've had to recover, and the reset button worked then, but it may not work anymore... Dunno

No apology necessary.. we are all just trying to help out.

(Last edited by davidc502 on 28 May 2016, 21:07)

Were you utilizing a TFTP server on a Linux/BSD distro by chance?  If so, I'll add that information as an annotation to the TFTP section when I finalize that section later on this week. 

I've never used a TFTP server on Linux/BSD and always TFTP flash using TFTP64 on Windows.  I do know while TFTP32/64 will auto recognize when a file is being requested, U-boot won't auto recognize itself as having a failsafe subnet of 192.168.1.1/24 [WRT1900AC v1, so this could have changed for the other 3).

(Last edited by JW0914 on 28 May 2016, 21:14)

No, just as you are doing. TFTP64 on win10.
I did not know that the reset button was an option, have never used it. When things failed, usually the NAND issue, I always just used the tri-power cycle, and it always worked; except on occasion when I had serial connected, and then disconnecting would allow it to work.

I'll have to try the way you're describing when I flash next =]

Managed to get console working with Odroid C2. It showed to me nice kernel panic as I thought:

[    2.080482] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Can you interrupt boot process? You could try explicit:
run nandboot
run altnandboot

Both failed, so I flashed both

OK - main question now is - how to upgrade next time to not brick it?

(Last edited by belliash on 28 May 2016, 23:20)

i got this in dmesg (luci don't wont to render) on my 1900acs

[   44.531347] br-lan: port 2(wlan0) entered forwarding state
[   51.805156] SQUASHFS error: xz decompression failed, data probably corrupt
[   51.812088] SQUASHFS error: squashfs_read_data failed to read block 0x99fd5e
[   51.819169] SQUASHFS error: Unable to read fragment cache entry [99fd5e]
[   51.825916] SQUASHFS error: Unable to read page, block 99fd5e, size bad0
[   91.940686] SQUASHFS error: Unable to read fragment cache entry [99fd5e]
[   91.947453] SQUASHFS error: Unable to read page, block 99fd5e, size bad0
[   99.737799] SQUASHFS error: Unable to read fragment cache entry [99fd5e]
[   99.744569] SQUASHFS error: Unable to read page, block 99fd5e, size bad0

does anyone happend the same?

maybe there is a NAND patch/issue?

(Last edited by gsustek on 29 May 2016, 10:28)

Guess it depends on what went wrong.  Like what image you flashed, what patches were applied, ....

I flashed latest trunk - sysupgrade image:

sysupgrade -n sysupgrade-image.tar

From what image?

Edit: Just for historical reasons, I always use the factory image. Shouldn't be necessary, but from fighting fires in the past it just worked well, so I stuck with doing it that way.

Edit2: Right, but what image were you running when you did the upgrade?

Edit3: Weren't you looking for the latest mwlwifi somewhere back?

Edit4: I would expect the upgrade to work in that case.

Edit5: Yes, just found the post. That image will not have the latest mwlwifi if that is of concern to you.

(Last edited by anomeome on 29 May 2016, 00:37)

I flashed exactly this: https://downloads.openwrt.org/snapshots … pgrade.tar and I was running some 15.05 RC. I dont remember exactly which version was it.

(Last edited by belliash on 29 May 2016, 00:29)

Not that it really matters, but 2 times I attempted to upgrade using the sysupgrade command, needed to be recovered by secondary flash. So, since that time, I've always just used luci and flashed the .img, and haven't had any problems with that method.

Would anyone be surprised if someone had the opposite experience?    

Heck, we probably have some who brick just so they can have fun trying to recover. JK  lol  Those adventurous types......

That depends... if flashing via the WebGUI works, great; if not, some in depth troubleshooting will need to be performed as I have the 1900 v1 and I've had the problem for over a year, whether flashing via sysupgrade, or the WebGUI

I've never had the time to thoroughly troubleshoot it and haven't cared since I installed the 3.5mm jack about a year ago lol  Whichever way you try to flash, ensure you're set up to flash via serial when you do, just in case something wonky occurs.

(Last edited by JW0914 on 29 May 2016, 01:00)