Posted: Fri Oct 12, 2012 19:43 Post subject: Will EJTAG v3.0 work with a TIAO USB Adapter
I just downloaded the EJTAG v3.0 software and I have the TIAO USB Multi-Protocol Adapter
http://www.dd-wrt.com/phpBB2/profile_sec.php?mode=activate&u=265077&act_key=96a0e513e7
loaded and operational (all drivers).
I cannot detect the CPU using the tjtag3 -probeonly
command. I've double checked the cables and nothing.
I have a NetGear WNR3500 router (Model N300) with the
Broadcom BCM4718A chip.
Will the EJTAG software work with this TIAO USB Adapter?
Posted: Wed Oct 17, 2012 23:41 Post subject: Re: Will EJTAG v3.0 work with a TIAO USB Adapter
try zjtag...
ktmoldman wrote:
I just downloaded the EJTAG v3.0 software and I have the TIAO USB Multi-Protocol Adapter
http://www.dd-wrt.com/phpBB2/profile_sec.php?mode=activate&u=265077&act_key=96a0e513e7
loaded and operational (all drivers).
I cannot detect the CPU using the tjtag3 -probeonly
command. I've double checked the cables and nothing.
I have a NetGear WNR3500 router (Model N300) with the
Broadcom BCM4718A chip.
Will the EJTAG software work with this TIAO USB Adapter?
Recovery tool for BCM6348 based DSL routers. This SoC have a bizzare bug, that prevents entering CPU debug mode via jtag, if ADSL controller inside BCM is not initialized (if you compile the original firmware without DSL driver, you are also not be able to enter debug). This tool completly bypass CPU, and access flash via jtag boundary scan,so you may flash CFE directly on board. But for this, you must put out 64Mhz crystall to stop CPU core before. I tested this tool on DSL-2640RU Rev B2 router, but with MX29LV160 flash. I have'nt native 32Mbit flash.
I've come up with a workaround for non-supported flash chips, at least for spansion chips; could work for other chips too.
After going through the source code of several jtag software, I noticed that the flash regions for cfe, nvram, kernel etc., are identical across the jtag software I analyzed, ie:
Therefore, using the flash identification operand /fc:115 for 16MB Spansion chips, which are fully supported, would work for 32/64/128Mb spansion chips which are yet to be 'fully' supported in zjtag, brjtag, tjtag, xjtag and others. This also applies to flash chips made by other flash chip manufactures ie. Macronix, SST, ATMEL, EON, etc. We simply need to identify the nearest supported 8/16MB chip for the chip we have.
The only limitation to this workaround is in attempting to delete / wipe the entire flash chip.
As we can see in the code above, a -erase:WHOLEFLASH for a 16MB chip ends with flash region 0x1000000. To fully erase a >= 32MB flash chip, we will need to identify the flash end region (length) for the flash chip we are working with and use the /window: /start: /length: operands with /erasechip.
The real work lies in carrying out a '2-step initialization' of non-supported CPUs, which in my case was the BRCM 0x4706, so that we're able to effectively read/write to supported/non-supported flash chips. This hack 'could potentially' put an end to non-supported CPUs in jtag software.
The guide is still WIP.. I am planning on releasing it as soon as I am done going over my notes and replicating the hack on parallel jtag boards.
I've come up with a workaround for non-supported flash chips, at least for spansion chips; could work for other chips too.
After going through the source code of several jtag software, I noticed that the flash regions for cfe, nvram, kernel etc., are identical across the jtag software I analyzed, ie:
Therefore, using the flash identification operand /fc:115 for 16MB Spansion chips, which are fully supported, would work for 32/64/128Mb spansion chips which are yet to be 'fully' supported in zjtag, brjtag, tjtag, xjtag and others. This also applies to flash chips made by other flash chip manufactures ie. Macronix, SST, ATMEL, EON, etc. We simply need to identify the nearest supported 8/16MB chip for the chip we have.
The only limitation to this workaround is in attempting to delete / wipe the entire flash chip.
As we can see in the code above, a -erase:WHOLEFLASH for a 16MB chip ends with flash region 0x1000000. To fully erase a >= 32MB flash chip, we will need to identify the flash end region (length) for the flash chip we are working with and use the /window: /start: /length: operands with /erasechip.
The real work lies in carrying out a '2-step initialization' of non-supported CPUs, which in my case was the BRCM 0x4706, so that we're able to effectively read/write to supported/non-supported flash chips. This hack 'could potentially' put an end to non-supported CPUs in jtag software.
The guide is still WIP.. I am planning on releasing it as soon as I am done going over my notes and replicating the hack on parallel jtag boards.
Made a donation a few days ago, from the site, and still got no download link or anything.
Is Tornado still available?
I made my donation 2 weeks ago and still nothing. I posted on the TIAO forum asking how long it should take and an admin gave me a link to the download.
So try asking there. _________________ I am far from a guru, I'm barely a novice.
Just donated and used Tjtag for the first time today. Home built the simple interface. Worked Great!
I un-bricked a Belkin F7D7301.
Only problem was I have 6 computers in my house, all 64 bit. So I had to put some ram in an old 32 bit machine and fire it up. I see in post above Tornado is working on win7 x64bit, awesome.
By the way, the command that worked on this router was tjtag3 -erase:nvram /cable:DLC5 /fc:43 /byte_mode
Tried a serial adapter first but boot was in some kind of loop, so no-go. Then tried Tjtag, Bingo!