OpenWrt Forum Archive

Topic: Bricked WRT160NL

The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi there,

I have been using OpenWRT on my WRT160NL for about a week or more now and it worked very well.
I had already done some upgrades with sysupgrade to clean tweak my image a bit, and every time, it worked perfectly,
untill now....

I was flashing a new image with IPv6 support, because I want to use a tunnel, when it said  "Error writing to flash".
It rebooted and never came up again.

So I opened it up, connected my FTDI  breakout, and tftp'ed (using upgrade code.bin) the image, but still no luck.
I have tried several new-build images, but I keep getting this erro:

## Booting image at bf04003c ...
   Image Name:   MIPS OpenWrt Linux-2.6.30.5
   Created:      2009-09-08   9:53:12 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1234738 Bytes =  1.2 MB
   Load Address: 80060000
   Entry Point:  80060000
   Verifying Checksum ... Bad Data CRC

I even tried to install the stock linksys firmware, but even that didn't work, it fails with:

## Booting image at bf04003c ...
Bad Header Checksum

Does anyone know how to fix this?

Thanks in advance!

(below is the complete bootlog)

U-Boot 1.1.5 (Apr  6 2009 - 13:54:11)

DRAM:  ar7100_ddr_initial_config(237) enter!
ar7100_ddr_initial_config(269) exit!


U-Boot 1.1.5 (Apr  6 2009 - 13:54:11)

AP81 (ar7100) U-boot
sri
32 MB
WRT160NL u-boot version: 1.0.0
Top of RAM usable for U-Boot at: 82000000
Reserving 277k for U-Boot at: 81fb8000
Reserving 192k for malloc() at: 81f88000
Reserving 44 Bytes for Board Info at: 81f87fd4
Reserving 36 Bytes for Global Data at: 81f87fb0
Reserving 128k for boot params() at: 81f67fb0
Stack Pointer at: 81f67f98
Now running in RAM - U-Boot at: 81fb8000
id read 0x100000ff
flash size 8MB, sector count = 128
Flash:  8 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ag7100_enet_initialize...
ag7100 get ethaddr for device eth0
Fetching MAC Address from 0x81feaf20

 --------***** Get the RTL8306SD Manufactory ID=34dc *****-------
 Reg6: speed=0 nway=1 duplex=1
 Reg5: speed=0 nway=0 duplex=0
 Reg1: a1=7fd9 a2=2890 a3=115c a4=2890 a5=0
 Reg1: a1=7fd9 a2=2890 a3=115c a4=2890
 Reg1: a1=7fd9 a2=2890 a3=115c a4=2890
 Reg1: a1=7fd9 a2=2890 a3=115c a4=2890
 Reg1: a1=7fd9 a2=2890 a3=115c a4=2890
eth0: 00:23:69:b5:b3:c9
eth0 up
eth0
### main_loop entered: bootdelay=1

Hit any key to stop autoboot:  0
## Booting image at bf04003c ...
   Image Name:   MIPS OpenWrt Linux-2.6.30.5
   Created:      2009-09-08   9:53:12 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1234738 Bytes =  1.2 MB
   Load Address: 80060000
   Entry Point:  80060000
   Verifying Checksum ... Bad Data CRC
 check link duplex:Full/speed:100
dup 1 speed 100
Tftpd start listening on port[69]!
Load address: 0x80060000

this is the output while flashing the image:

ar7100> upgrade code.bin
 check link duplex:Full/speed:100
Tftpd start listening on port[69]!
Load address: 0x80060000
Receiving firmware [code.bin] from [192.168.1.2]
Write File : CODE.BIN
#

Current Code Pattern:NL16 , Upgrade Code Pattern:NL16

Code Pattern is correct!
################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###################################
done
Bytes transferred = 2837548 (2b4c2c hex)
load addr= 0x80060000
boot file= CODE.BIN
NetBootFileXferSize= 002b4c2c
Erase linux kernel block !!
From bf040000 To bf7dffff
Erase Flash from 0xbf040000 to 0xbf7dffff in Bank # 1
First 0x4 last 0x7d sector size 0x10000                                      125
Erased 122 sectors
Programming.........
Copy to Flash... write addr: bf040000
done
ar7100> boot
## Booting image at bf04003c ...
   Image Name:   MIPS OpenWrt Linux-2.6.30.5
   Created:      2009-09-08   9:53:12 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1234738 Bytes =  1.2 MB
   Load Address: 80060000
   Entry Point:  80060000
   Verifying Checksum ... Bad Data CRC

I think I'm making some progress, but I'm not sure...

ar7100> tftpboot 0x80060000 code.bin
 check link duplex:Full/speed:100
Using eth0 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.1
Filename 'code.bin'.
Load address: 0x80060000
Loading: send option "timeout 5"
#Server did not acknowledge timeout option!


Current Code Pattern:NL16 , Upgrade Code Pattern:NL16

Code Pattern is correct!
################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################
done
Bytes transferred = 2753536 (2a0400 hex)

ar7100> bootm 0x8006003c
## Booting image at 8006003c ...
   Image Name:   MIPS OpenWrt Linux-2.6.30.5
   Created:      2009-09-08  12:49:40 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1145065 Bytes =  1.1 MB
   Load Address: 80060000
   Entry Point:  80060000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... Error: inflate() returned -3
GUNZIP ERROR - must RESET board to recover

So at this point, the checksum is ok, but the kernel can't be unzipped...

I think the unzip fails because it's overwriting the image in memory, but I'm not familiar with the memory layout of this kind of devices...

Kind of strange that the checksum of the image loaded in memory is valid,
but it's unvalid if the image is written to flash...

Output after writing to flash:

## Booting image at bf04003c ...
   Image Name:   MIPS OpenWrt Linux-2.6.30.5
   Created:      2009-09-08  12:49:40 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    1145065 Bytes =  1.1 MB
   Load Address: 80060000
   Entry Point:  80060000
   Verifying Checksum ... Bad Data CRC

(Last edited by koensadza on 8 Sep 2009, 16:21)

Dogge wrote:
koensadza wrote:

ar7100> bootm 0x8006003c

You have not read the Wiki page...

http://wiki.openwrt.org/inbox/wrt160nl#oem.tftp.install

Offcourse I did, see my first post,
it doesn't work when written to flash, so I'm trying alternatives (like booting from memory) to find out whrere the problem lies.

(Last edited by koensadza on 8 Sep 2009, 16:17)

Did you built the image by yourself with latest trunk?

Dogge wrote:

Did you built the image by yourself with latest trunk?

Yes I did.

Did you do make target/linux/clean between builds?
I have had problems before with my tree needing a cleaning.
Once I had to wipe my copy of trunk and download a new one.

vincentfox wrote:

Did you do make target/linux/clean between builds?
I have had problems before with my tree needing a cleaning.
Once I had to wipe my copy of trunk and download a new one.

I have tried serveral new images , all with a clean checkout.

So, I compared te image in RAM with the image on flash and this is the output:

ar7100> cmp 0x80060000 bf040000 2a0400
word at 0x80060090 (0x0d705bd5) != word at 0xbf040090 (0x0d00705b)
Total of 36 words were the same

What could be wrong?

When I try to copy the tftpboot'd image to flash I get this output:

ar7100> cp 80060000 bf040000 2a0400
Copy to Flash... Outside available Flash

Does this mean bf040000 (which is the default offset used by "upgrade code.bin" ) is wrong and should be lower?
What is a good offset to put the image?

(edit) scratch that, upgrade erases bf040000 until bf7dffff, which according to bc is 79FFFF, almost 3 times as much as 2a0400, so it should fit or am I mistaken?

(Last edited by koensadza on 8 Sep 2009, 18:21)

Wow I don't know what I did exactly, but now cmp shows a difference at the first byte:

ar7100> cmp 80060000 bf040000 2a490a
word at 0x80060000 (0x4e4c3136) != word at 0xbf040000 (0xffffffff)

looking in detail is seems as if the header that identifies the image as a valid image is missing:

ar7100> md bf040000
bf040000: ffffffff ffffffff ffffffff ffffffff    ................
bf040010: ffffffff ffffffff ffffffff ffffffff    ................
bf040020: 48445230 00002a00 72c875b4 00000100    HDR0..*.r.u.....
bf040030: 1c000000 00000000 00000000 27051956    ............'..V
bf040040: 90780728 4aa652e4 001178e9 80060000    .x.(J.R...x.....
bf040050: 80060000 1465e492 05050201 4d495053    .....e......MIPS
bf040060: 204f7065 6e577274 204c696e 75782d32     OpenWrt Linux-2
bf040070: 2e362e33 302e3500 00000000 1f8b0808    .6.30.5.........
bf040080: ce52a64a 0203766d 6c696e75 7800ec5b    .R.J..vmlinux..[
bf040090: 0d00705b d5953eef 49969e1d d9564021    ..p[..>.I....V@!
bf0400a0: 6aec6209 3fc74e63 182d359b 50d4e111    j.b.?.Nc.-5.P...
bf0400b0: 0c556800 c3c04e1a 321def02 3bee2eed    .Uh...N.2...;...
bf0400c0: b8b39969 20867d04 27951339 32d92cf5    ...i .}.'..92.,.
bf0400d0: 0603224d 824d1464 68000349 119004f3    .."M.M.dh..I....
bf0400e0: d312a896 86058267 37044353 7089160c    .......g7.CSp...
bf0400f0: 18de7ef7 9ea74472 9340433b 74e368e6    ..~...Dr.@C;t.h.
ar7100> md 80060000
80060000: 4e4c3136 00000000 09090801 00015532    NL16..........U2
80060010: 4e440011 3f000000 00000000 00000000    ND..?...........
80060020: 48445230 00002a00 72c875b4 00000100    HDR0..*.r.u.....
80060030: 1c000000 00000000 00000000 27051956    ............'..V
80060040: 90780728 4aa652e4 001178e9 80060000    .x.(J.R...x.....
80060050: 80060000 1465e492 05050201 4d495053    .....e......MIPS
80060060: 204f7065 6e577274 204c696e 75782d32     OpenWrt Linux-2
80060070: 2e362e33 302e3500 00000000 1f8b0808    .6.30.5.........
80060080: ce52a64a 0203766d 6c696e75 7800ec5b    .R.J..vmlinux..[
80060090: 0d00705b d5953eef 49969e1d d9564021    ..p[..>.I....V@!
800600a0: 6aec6209 3fc74e63 182d359b 50d4e111    j.b.?.Nc.-5.P...
800600b0: 0c556800 c3c04e1a 321def02 3bee2eed    .Uh...N.2...;...
800600c0: b8b39969 20867d04 27951339 32d92cf5    ...i .}.'..92.,.
800600d0: 0603224d 824d1464 68000349 119004f3    .."M.M.dh..I....
800600e0: d312a896 86058267 37044353 7089160c    .......g7.CSp...
800600f0: 18de7ef7 9ea74472 9340433b 74e368e6    ..~...Dr.@C;t.h.

the difference that was in there first is however gone now...

Ok, I cp'ed the differing bytes by hand:

ar710>cp 80060000 bf040000 8
Copy to Flash... write addr: bf040000
done

Now I tryed to boot, but it failed, so I rebooted and loaded the image into ram again.
The old dffering word was back again, so I tried to copy that too:

ar7100> cp 80060090 bf040090 4
Copy to Flash... write addr: bf040090
done
ar7100> cmp 80060000 bf040000 2a0400
word at 0x80060090 (0x0d705bd5) != word at 0xbf040090 (0x0d005051)
Total of 36 words were the same

So this doesn't work, those last two bytes just won't change...
Could this be bad flash?

I surely don't hope so, as I own this device for just a month now, and have lost guarantee by opening it...

(edit)
however, running cmp after upgrade runs, gives this output:

ar7100> cmp 80060000 bf040000 2a490a
word at 0x80800000 (0x02ffffff) != word at 0xbf7e0000 (0xffffffff)
Total of 1998848 words were the same

which suggests the flash works fine, but the images that upgrade and tftpboot store are different...

(edit)
which makes me think... does my tftp client upload in ascii of binary?
(im very excited, this may be it!)
(also note that the image sizes reported by tftpboot and upgrade are different!)

(Last edited by koensadza on 8 Sep 2009, 19:01)

GOT IT! It was the transfer mode of my tftp client :-D
Sorry for spamming the forum,
however I hope that this may be useful for someone else out there.

I've got a WRT160NL on order so this may be very useful - can you please advise which TFTP client (server?) you were using when the problem occurred? Did you have to change clients to get binary mode or was there a configuration option?

Many thanks, and congratulations for solving the problem.

Hi staylo,

The problem was indeed that if I used tftpboot, my computer would act as tftp server and then it uses binary mode by default.
However, if you use "upgrade code.bin", to upgrade the firmware, the router acts as server and you have to use the tftp client program, wich used ascii by default. So the right instruction is actually like this:

on the router: upgrade code.bin

on the computer:

$ tftp
tftp> connect 192.168.1.1
tftp> binary
tftp> put code.bin


I'm using netkit-tftp version 0.17, which is default in most linux distributions.

The discussion might have continued from here.