I agree with you that the XML isn't a problem and neither is USB JTAG NT's capabilities since the WRT160NL is very much like this router and even the boards are laid out much the same way. (In reference to the position of the components and what ones are used)usbbdm wrote:The reason I ask you to focus on CPU ID is you get excited when you see DEBUG ON when your CPU ID is ffffffff.
If you get CPU ID 0 and even you do get DEBUG ON it does not mean anything. It will not help you get detect CPU ID nor read data properly.
I agree with you there might be missing trace but there is very little interest of this router and spend time to find out the missing trace is not what I would do if there is only one interest.
However if you do get CPU ID I would be happy to create the XML for you. (Very easy and not rocket science if you open the WRT160NL.xml). It is just a few lines of memory definition and possibly some init strings that can ge added basked on the information from Google.
The reason I guess that this router should work out of the box is
1. It has proper JTAG port populated.
2. It uses dd-wrt as its stock firmware. We all know dd-wrt is for hackers and hackers will mess around with it. So the JTAG port should be available for people to play.
This is a guess and I could be wrong but it is a reasonable guess.
I need several other people who show the interest before I invest the money on this router.
Even I do get the router and the JTAG port is not accessible, I might not be able to do much as there is really NO DEVELOPMENT needed for this chip. Development for this chip was done when WRT160NL was finished. Create a new XML with different flash size is not considered development in here.
I have already a huge pile of routers collected over the years. Most of them were donated by members. I remember the last router was M20 donated by Canadian member which created new release of software.
On example of router I bought off the ebay was WNR854T which needs a lot of development. I was challenged by the member since at the time NT simply could not do it.
Recently I have client who used Atheros 9XXX in his development in Taiwan. I helped him remotely to create the XML and he is happy. So I have no doubt that NT now does support Atheros SPI flash with the framework same as WRT160NL.
I only got excited about the "Debug On" because I thought I made a break through and I didn't realize I was just getting a binary 1. (Active high) Before I went to bed, I noticed that pin 3 on the JTAG header connects directly with VCC and that explains the active high state, so I'll need to work on that a bit more.