Posted: Sat Sep 25, 2010 19:53 Post subject: WNR3500L JTAG Issue
Hello,
I'm trying to debrick my WNR3500L router. By accident I've erased the CFE. Only orange and blue LEDs are weak lit. Router's serial console is dead. The only hope is in JTAG.
I've installed tjtag3.0.2-RC1 (at README it states that BCM4718 is supported) at WinXP T23 laptop.
Unfortunately, when I started it, with -probeonly switch, I see all 111111111111 as CPU ID.
One strange thing is that on the cable schematic presented above the pin1 is not connected, but on the router's board I can see that it is going to CPU. I've poked around for some other LPT <-> JTAG cables (e.g. wiggler), but I don't know which exactly works with tjtag and WNR3500L.
Can anyone, who managed to use tjtag with WNR3500L, share the knowledge which tjtag version and JTAG cable was used?
I'm trying hard to fix my router (i.e. restore CFE at bootloader partition), but so far with no success.
I've installed tjtag3.0.2-RC1 (at README it states that BCM4718 is supported) at WinXP T23 laptop.
Unfortunately, when I started it, with -probeonly switch, I see all 111111111111 as CPU ID.
One strange thing is that on the cable schematic presented above the pin1 is not connected, but on the router's board I can see that it is going to CPU. I've poked around for some other LPT <-> JTAG cables (e.g. wiggler), but I don't know which exactly works with tjtag and WNR3500L.
The unbuffered jtag cable (resistor only cable) is prone to interference and it is very importan to keep the wires as short as possible and not twisted together.
Make sure that your LPT port is set to ECP in bios and try another computer if you don't get it to work.
Windows XP may give a better result than Win7 or Vista.
pin1 in the jtag connector should be connected to + 3.3V via a 100 ohm resistor and should be done immediately after applying power to the router.
The cpu, when router starts, wants to see this pin as a low level and there is a pull-down resistor for that on the circuit board. Applying +3.3V to the pin via resistor will notify the cpu that the jtag interface is activated.
Some routers can manage without pin1 in high state, others just refuse to work unless there is a high level on the pin. _________________ Kernel panic: Aiee, killing interrupt handler!
I've managed to force JTAG to work with my WNR3500L router.
I've used the wiggler, buffered cable (which I've build on the universal PCB). It works with tjtag3.0.2-rc1. I'm able to -probeonly my router:
./tjtag302 -probeonly /cable:wiggler
CPU Chip ID: 00000000000010001100000101111111 (0008C17F)
*** Found a Broadcom BCM4716 Rev 1 CPU in MIPS MODE chip ***
*** Found a Macronix MX25L6405D (8MB) Serial Flash Chip ***
Why the CPU is recognized as BCM4716 rev1, not BCM4718 as it is written on the package?
However I can erase the whole flash. It works (after erasing backup of CFE shows all 0xFFFFFFFFs).
Moreover -flash:cfe also can be done. It finishes with success. I've tried two versions of cfe.bin ( v1.0.29 and v1.0.25). Unfortunately when I flash them it seems, that nothing is changing. Still power (green) and wifi (blue) LEDs light with diminish lights.
When I backup, what has been written, the original CFE.BIN and the CFE.BIN.SAVED don't match. When compared with hexeditor the binary difference is for example: oardmfg=NETGEAR. versus drao=gfmGTEN.RAE It looks that there are some errors. Maybe the cable is to long? It has around 40cm.
4716 is the cpu core in 4716/17/18 and is what they all report to be but with a revision number afterwards.
Your cfe backup is indeed endian swapped so I suspect Netgear to be the culprit, they have done so in the past for other cfe's as well.
I take for granted now that you didn't use the swapendian tjtag cmd switch when doing the backup, that would had been an explanation for this behaviour.
You can test by doinhg an endian swap in the hex editor before writing the file via jtag. _________________ Kernel panic: Aiee, killing interrupt handler!
It turned out, that I needed to change the endianess of CFE.BIN before flashing it with JTAG. Frankly speaking, I don't know why this operation was needed (any idea?).
After flashing I've got access to the CFE> serial console.
CFE for WNR3500v2 version: v1.0.25
Unfortunately, the hwaddr is 00-FF-FF-FF-FF-FF, despite that I've changed it to proper value with hexeditor before flashing.
I can stop the booting of the serial console and perform
CFE> tftpd
Start TFTP server
Reading ::
From my host machine I'm using the tftp for uploading data:
tftp 192.168.1.1 -c put WNR3500L-V1.0.2.50_31.1.25.chk
Reading :: Done. 5330293 bytes read
Reading ::
And it stays like that.
The power LED (green) is blinking. I can ping it.
Before I've erased the whole flash (including original CFE), I saw the checksum calculation (which was wrong). The router was at least trying to flash yourself . Now I don't see this attempt.
Any help?
I'm also trying to explore the capabilities of CFE (since help and ? is NOT implemented at my version). I've "discovered" following commands:
tftpd, ping, flash (but I don't know how to use this command to be able to download data via tftp and flash it to the proper partition)
Does anyone know how to:
1. Check mtd partions (like mtdparts at u-boot) for flash0.
2. Check the flash memory status.
3. Try to read/write data to flash/DRAM memory - for test purposes.
If you start tjtag with a -probeonly cmd switch, then you will get some info like this (from another router):
Chip ID 4716
Chip Rev 1
Package Options a
Number of Cores 9
Core Revision 79
Core Type 710
Core Vendor ID 19a10000
Flash Type 700
Flash Type = PFLASH
Dest is bits 0
Dest is bits1 0
Dest is bits 0
Flash is byteswapped 0
Endian Type is LE 0
PLL Type 00000000
Done
By erasing the wholeflash you did also wipe out your caldata area containing the routers software identifier, its serial number, and its mac addresses.
Surely you did a backup of wholeflash before erasing it so now you have to write back the wholeflash via tjtag as your first step.
When that is done, then you probably have to erase the kernel since it is likely bad in the wholeflash. _________________ Kernel panic: Aiee, killing interrupt handler!
Hi,
Unfortunately, since I'm fresh with routers I DID NOT made any backup.
I was not aware,that there is any other partition, which is storing the flash byteswap information (among others) :-/
I only knew, from the router documentation, the layout of the mtd partitions.
On the dd-wrt wiki page regarding the JTAG and tjtag use, it was clearly stated, that I shall do a CFE backup (which I did not) and then perform -erase:wholeflash and write CFE again.
I've downloaded CFE.BIN for WNR3500L router and follow the instructions from the web.
So how shall I proceed now to debrick my router?
Now, I suspect, the caldata with information regarding flash byteswap was corrupted. This is explaining why I need to byteswap CFE.BIN image before flashing.
Correct me if I'm wrong (or propose something more appropriate ). The steps shall be:
1. Find/ask somebody for WHOLEFLASH.BIN (with caldata) for WNR3500L and flash it to memory chip.
2. With correct flash chip endianess reflash CFE.BIN.
3. Try to download and flash original/any kernel image.
4. Router is debricked :-)
Is this correct? Could anybody share WHOLENAND.BIN for WNR3500L router?
The endian type is not stored in the factory (caldata) partition, it is a mfgr configuration most likely done by strapping a cpu pin to high or low level.
I have changed the wiki now, the old text may explain why so many users erases everything as their first step.
pm me your router serial number, security pin, and the mac address(es) all from the routers label and I'll see if can build a factory partition file for you. _________________ Kernel panic: Aiee, killing interrupt handler!
Joined: 24 Jan 2010 Posts: 13 Location: Massachusetts, USA
Posted: Sun Oct 10, 2010 13:13 Post subject:
majess wrote:
Hi,
Correct me if I'm wrong (or propose something more appropriate ). The steps shall be:
1. Find/ask somebody for WHOLEFLASH.BIN (with caldata) for WNR3500L and flash it to memory chip.
2. With correct flash chip endianess reflash CFE.BIN.
3. Try to download and flash original/any kernel image.
4. Router is debricked :-)
Is this correct? Could anybody share WHOLENAND.BIN for WNR3500L router?
Thanks in advance,
Lukasz
"1. Find/ask somebody for WHOLEFLASH.BIN (with caldata) for WNR3500L and flash it to memory chip."
Do not use a WHOLEFLASH.BIN unless you want to wait for many hours (days if your computer is slow) for this go into the router using JTAG. This will not be a good situation because the NVRAM will have the MAC address of the wrong router.
"2. With correct flash chip endianess reflash CFE.BIN."
Download the files I (mild_pats_fan) posted here about 2/3 of way down the page:
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=25971&postdays=0&postorder=asc&start=270
These files have the correct endianess and you will not need to make corrections for them. There is also instructions on how to setup the NVRAM file which contains the MAC address and other info. The NVRAM is small (1/2 size of CFE) and will go into the router quickly like the CFE. There is no reason to edit the CFE. To be very clear, you only need three files: CFE (unedited), NVRAM (edited with your routers info) and the FIRMWARE (OEM or DD-WRT that ends in .chk). Erase the whole router via JTAG. Load CFE via JTAG. Load modified NVRAM via JTAG. TFTP firmware and wait. That's it.
"3. Try to download and flash original/any kernel image."
Yes, but clear the full memory and start from scratch. Make sure you pick a firmware that will work if it is not the OEM. I would suggest you start with the OEM to know you have everything working, then you can play with third party firmware like DD-WRT when you have the confidence you can bring it back from the dead any time you want with your JTAG setup. Wait a LONG time after the TFTP before doing anything. I timed the 3500L and it has taken from 1:40-3:00 to tftp, finish the transfer from RAM to FLASH inside the router, reboot and then reset the data constants or partitions.
"4. Router is debricked "
Yes, but router is technically not a brick when the CFE works.
PMed you back on the other questions and some specific suggestions. Will check PM later this afternoon to see if you made progress....
. Now I don't see this attempt.
