Skip to content
This repository has been archived by the owner on Oct 13, 2022. It is now read-only.

Bricked TL-wr841n #40

Closed
N1ght5tar opened this issue Oct 11, 2014 · 7 comments
Closed

Bricked TL-wr841n #40

N1ght5tar opened this issue Oct 11, 2014 · 7 comments
Labels

Comments

@N1ght5tar
Copy link

Hello!

I downloaded latest git on 16 Sep 2014, built it for wr841 with make tplink_wr841n_v8,
flashed it on device and it stuck without output.
The command sequence was:
setenv ipaddr 192.168.1.3
setenv serverip 192.168.1.1
tftp 80800000 <bin_file>
erase 9f000000 +10000
cp.b 80800000 9f000000 10000

md 9f000000 after flash showed u-boot image head and I believed it is fine. However after "reset" no output at all, and after swapping power too.

I then unbricked board (with original firmware from tp-link_wr841n_v8_130506.bin), built RAM version and put in in memory in 80100000 and issued "go 80100000" and it worked. However I tried to flash freshly built non-RAM version of it and it stuck again.

RAM version works fine and detects my bigger flash, but flash version stucks.
I can send binary images or any other files you need to see what's wrong with them.

Below is log of second attempt:

uboot> tftp 80800000 ub.bin

TFTP from IP: 192.168.1.1
Our IP: 192.168.1.3
Filename: 'ub.bin'
Load address: 0x80800000
Using: eth1

Loading: #############

TFTP transfer complete!

Bytes transferred: 65536 (0x10000)
uboot> erase 9f000000 +10000
Erase FLASH from 0x9F000000 to 0x9F00FFFF in bank #1
Erasing: #

Erased sectors: 1

uboot> cp.b 80800000 9f000000 10000
Copying to FLASH...
Writting at address: 0x9F000000

Done!

uboot> md 9f000000
9F000000: 100000FF 00000000 100000FD 00000000 ................
9F000010: 10000194 00000000 10000192 00000000 ................
9F000020: 10000190 00000000 1000018E 00000000 ................
9F000030: 1000018C 00000000 1000018A 00000000 ................
9F000040: 10000188 00000000 10000186 00000000 ................
9F000050: 10000184 00000000 10000182 00000000 ................
9F000060: 10000180 00000000 1000017E 00000000 ...........~....
9F000070: 1000017C 00000000 1000017A 00000000 ...|.......z....
9F000080: 10000178 00000000 10000176 00000000 ...x.......v....
9F000090: 10000174 00000000 10000172 00000000 ...t.......r....
9F0000A0: 10000170 00000000 1000016E 00000000 ...p.......n....
9F0000B0: 1000016C 00000000 1000016A 00000000 ...l.......j....
9F0000C0: 10000168 00000000 10000166 00000000 ...h.......f....
9F0000D0: 10000164 00000000 10000162 00000000 ...d.......b....
9F0000E0: 10000160 00000000 1000015E 00000000 ...`.......^....
9F0000F0: 1000015C 00000000 1000015A 00000000 ..........Z....
uboot> reset

Resetting the board...

@pepe2k pepe2k added the bug label Oct 11, 2014
@pepe2k
Copy link
Owner

pepe2k commented Oct 11, 2014

Hello @N1ght5tar,

If RAM version works without any problems, that means there is some problem in low level initialization. Could you tell me exact revision of the SoC (AR9341-XXXX), please? What memory chip do you have in that WR841v8?

Regards,
Piotr

@N1ght5tar
Copy link
Author

Sorry for delay.
I can't exactly tell what the board is, the only info "visible" to me is:
TL-WR841N(RU) Ver:8.4, board rev:1.2
Memory chip: ESMT M13S2561616A

Another thing I may got wrong - I used LZMA compressor from xz-5.0.2 instead of yours (lzma-4.32.7), because I am running pure x86_64. Could this be reason that raw RAM image worked fine but compressed flash is not booting, i.e. no output at all?

@Deoptim
Copy link

Deoptim commented Oct 14, 2014

pepe2k wrote:

What memory chip do you have in that WR841v8?

Or just read in uboot console "Chip Revision ID" value (common for all ath79):

md 0x18060090 0x1

@N1ght5tar
Copy link
Author

Deoptim,

If that helps, this is the output from that command:
wasp> md 0x18060090 0x1
18060090: 00010123 ...#

@pepe2k
Copy link
Owner

pepe2k commented Oct 14, 2014

@N1ght5tar
Try image from the link below and let me know if it works for you. Different LZMA tool version on your host machine was probably the reason.

http://www.tech-blog.pl/pliki/uboot_for_tp-link_tl-wr841n_v8__20141014.tar.gz

@Deoptim
Yes, bits [0:3] should indicate minor revision ID (higher bits are for major ID), here (in @N1ght5tar WR841Nv) we have minor revision ID = 3. I have revision 1 on my desk (the one which I'm using for tests).

Regards

@N1ght5tar
Copy link
Author

Thanks pepe2k, it working!
I guess it's my mischoice of LZMA tool before build.
I will try my image next time I will have another this device.
Close if needed.

@pepe2k
Copy link
Owner

pepe2k commented Oct 14, 2014

Hi @N1ght5tar,

Great news!

Cheers

@pepe2k pepe2k closed this as completed Oct 14, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants