• Visit https://www.embeddedcomputers.net/ for Hardware; Software and all other things related to FlashcatUSB

WinBond 25Q128BV SPI over BCM4718 JTAG

quarky

New Member
Is it possible for support to be added to this setup? I have a bricked LinkSys E4200 that I would like to bring back to life. It seems that the Broadcom chip is starting is a LV mode and needed to be switched to EJTAG mode. The software is unable to detect the IMPCODE and I think the LV mode nonsense is stopping it.

Anyone has any advice for me?

Thanks.
 
Hi all,

I managed to tweak the FlashcatUSB software to switch from Broadcom's LV mode to EJTAG mode. Below are the logs from the software's console. I've also uploaded the E4200_16M_JTAG.bcs script I've adapted from one of the WRT54G scripts. Now I'm stuck again. Anyone has any advice for me to continue?

Thanks.

LibUsbDotNet version: 2.2.8.104
FlashcatUSB Script Engine build: 202
Welcome to FlashcatUSB interfacing software, build: 330
Running on: Microsoft Windows 7 Ultimate (32 bit)
Initializing EJTAG engine
Device connected in JTAG mode: 7.05
Before LV mode switch - IdCode = 0x1471617F
Before LV mode switch - ImpCode = 0x1471617F
Looks like we're in Broadcom LV mode. Switching to EJtag mode ...
After LV mode switch - IdCode = 0x8C17F
After LV mode switch - ImpCode = 0x8C17F
JTAG: IR length set to 5
JTAG: sent processor reset command
JTAG engine setup successfully
Detected CPU ID: 0x8C17F IMP CODE: 0x60414000
Manufacturer ID: 0xBF Part ID: 0x8C
EJTAG Version support: 3.1
Target device does not support DMA mode
Checking for a device specific script to automatically load
Loading device specific script: E4200_16M_JTAG.bcs
Loading script: E4200_16M_JTAG.bcs
Setting device parameter (Intel Flash delay) to 0x32
Setting device parameter (AMD Flash delay) to 0xC8
Setting device parameter (Memory Read Delay) to 0x32
JTAG: SPI register returned 0x0
MemoryInit: Failed - device parameters failed Init
 

Attachments

  • E4200_16M_JTAG.bcs
    4.1 KB · Views: 14
It would be easier and quicker for you to connect direct to the SPI chip on board and reflash it in SPI mode
 
I tried that as well but it does not seem like I can control the flash. I suspect it could be due to the Broadcom SOC interfering. I could not read anything from the flash when I tried to connect direct to the flash on the logic board.
 
It should not be an issue ,, when u connected direct to the chip were you powering it to the VCC pin on the chip or have you found an ISP point on the board ? Try downloading the latest build as well , because the chip you are trying was not implemented in that software version.
 
I've tried powering it from the adapter's Vcc as well as trying while the board is powered on. In any case, I'll try again with the latest version.

Thanks.
 
Don't use the power from the board unless you have an ISP point . You may have to use the 5v setting on FCUSB as the board may well draw any power you have from the 3v setting thus not giving you enough to get a detection.
 
I'll try to measure the voltage at 3.3v first before trying 5v. Am afraid I'll fry the flash and the boards ICs if I use 5v directly.

Thanks for the advice d3m0n!!

Much appreciated.
 
Hi d3mon,

Followed your advice and connected the Flash to the 5v supply and managed to detect and flash the chip! Thanks a lot for the help.

Unfortunately I still can't revive my bricked Linksys E4200 v1.

Well, guess I will have to get another router to tinker with.

Thanks again!
 
What did you flash it with ? You would need a full dump to recover it unless you had a script to load the relevant sectors.
 
I erased the entire flash and wrote only the CFE into it. I managed to obtain a CFE from a working E4200 and compared it with what I extracted from my bricked E4200. They compared the same except for the MAC address and serial numbers.

Rightfully with only the CFE running, without the kernel and NVRAM, the router should boot and allowed me to TFTP a working firmware into it.

Unfortunately it still goes into a boot loop. I think the router's Ethernet circuit is busted.

I still could not figure out how software could damage hardware though.

I could post the boot log from the serial console if interested.

Thanks.
 
As you say flashing just CFE should give you serial access , did you manage then to write the firmware itself through serial ?
 
Unfortunately even with only the CFE in the flash, the router goes into a continuos boot loop. I obtained the log below from the serial console (MAC address masked.) From the log, it seems the TFTPd has not been started before the exception occurred.

I'm very certain that the CFE I flashed took effect as I could change the default MAC address in the CFE with a Hex editor before flashing into the chip and the boot log shows the changed MAC address.

I think the CFE could not initialize the Ethernet port and threw an exception.

--------------------------
CFE version 2010.09.20.0 based on BBP 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Fri Nov 12 11:01:26 CST 2010 (lzh@team2-complier)
Copyright (C) 2000-2008 Broadcom Corporation.

Init Arena
Init Devs.

No DPN
This is a Serial Flash
Boot partition size = 262144(0x40000)
Found an ST compatible serial flash with 256 64KB blocks; total size 16MB
sflash_cfe_probe: flash type ST, nparts 4
sflash_cfe_probe: idx 0, name boot, descr ST Serial flash offset 00000000 size 256KB
sflash_cfe_probe: idx 1, name trx, descr ST Serial flash offset 00040000 size 1KB
sflash_cfe_probe: idx 2, name os, descr ST Serial flash offset 0004001C size 16068KB
sflash_cfe_probe: idx 3, name nvram, descr ST Serial flash offset 00FF1000 size 60KB
sflash_cfe_probe: flash type ST, nparts 3
sflash_cfe_probe: idx 0, name boot, descr ST Serial flash offset 00000000 size 256KB
sflash_cfe_probe: idx 1, name trx, descr ST Serial flash offset 00040000 size 16068KB
sflash_cfe_probe: idx 2, name nvram, descr ST Serial flash offset 00FF1000 size 60KB
sflash_cfe_probe: flash type ST, nparts 0
CPU type 0x19740: 133MHz
Tot mem: 65536 KBytes

CFE mem: 0x80700000 - 0x8079EA40 (649792)
Data: 0x80734000 - 0x80737FE0 (16352)
BSS: 0x80737FE0 - 0x80738A40 (2656)
Heap: 0x80738A40 - 0x8079CA40 (409600)
Stack: 0x8079CA40 - 0x8079EA40 (8192)
Text: 0x80700000 - 0x80734000 (212992)

board_final_init: commit=0, restore_defaults=0Boot version: v5.2
The boot is CFE

mac_init(): Find mac [xx:xx:xx:xx:xx:xx] in location 1
Nothing...
country_init(): Find country code in location 0
The country is same
**Exception 8: EPC=80718DDC, Cause=80000008 (TLBMissRd)
RA=80718DE4, VAddr=0000000C

0 ($00) = 00000000 AT ($01) = 807300A8
v0 ($02) = 00000000 v1 ($03) = 00000000
a0 ($04) = 80739A80 a1 ($05) = 8072E345
a2 ($06) = 00000001 a3 ($07) = 80738A58
t0 ($08) = 8079E5D4 t1 ($09) = 00000000
t2 ($10) = 807337EC t3 ($11) = 00000000
t4 ($12) = 00000000 t5 ($13) = 48534C46
t6 ($14) = 9FC036BC t7 ($15) = FBFFFEDF
s0 ($16) = 00000000 s1 ($17) = 8072E32C
s2 ($18) = 8072E2E4 s3 ($19) = 8072E2F0
s4 ($20) = 8079E800 s5 ($21) = 8079E800
s6 ($22) = 19A14716 s7 ($23) = 00000001
t8 ($24) = 04000000 t9 ($25) = 00000000
k0 ($26) = CAD1CAD1 k1 ($27) = CAD1CAD1
gp ($28) = 8073C000 sp ($29) = 8079E7D8
fp ($30) = 00000000 ra ($31) = 80718DE4
 
Actually I'd read a lot of the DD-WRT forum posts and had the impression that either my CFE or NVRAM was corrupted.

But when I managed to extract the CFE from the flash chip, it compared the same with a known working copy of CFEs I extracted from a working E4200.

Also I erased the entire flash chip and wrote only the CFE back and it did not work. I also wrote many versions of CFEs I found from the DD-WRT forum but it still goes into a boot loop.

The reason I suspect it's due to faulty hardware is due to post such as this:

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=670747

From the post above it appears the CFE managed to initialize the Ethernet port and starts TFTPd whereas mine was missing those lines in the boot log.

Anyway, I'm still trying to revive the router. Hope it's still firmware issues and not hardware.

Thanks.
 
When you erased the flash did you double check to see if it wall ALL erased all FFFF ? So Erase the chip , check all FFFF power it down close software , and restart it and see if it is all still FFFF as NVRAM is held near the end it could still be holding that info.
 
Yes, I checked after the erase and confirmed the NVRAM and firmware sections are all FFFF. I even prepared files with zeros and flashed those to the NVRAM and kernel sections as well, hoping that it'll make a difference.

So I guess now it's down to reading MIPS assembly codes ...
 
An important thing that i detected on one of my routers with that flash memory , is if you turn on th router and try to fash it then you wont be able to do it because the circuit board puts a tension on the "write Protected" pin of the flash , and no matter what you try to do , it will be impossible .
I had to do it over SPI directly with the router disconnected .
When you flash that rom , and then you turn on the router to see if it is working fine , and then you notice that flash is not working perfectly and you decide to re-flash it again , in my case i have to turn off the router , and wait 3 minutes for the condesators to discharge the power over the circuit board .
Only after that point i was able to re-flash again without the write protection switch .
 
I managed to re-flash using SPI mode by disconnecting power to the router and powering the chip directly with the adapter's 5v supply. The 3.3v supply was not enough.

Sadly, my router is still bricked even after the re-flash.
 
that chip works at 3,3V and not 5V .
I had to use an external 3,3V power source to feed the rom because backcat did not had enough power .
I used a raspberry pi with a circuit protection board to feed the 3,3V .
DSCF1813.jpg


I have no idea if your flash is good using a 5V power source and flashing at 3,3V in blackcat , unless you changed the blackcat to 5V position , but even that i have no clue if a superior voltage will interfere with the final result .
Maybe someone here already did a similar test and can write a few lines on the result .
 
Back
Top