From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 17 Jun 2009 09:53:06 -0400 Subject: [U-Boot] BDIxxxx and others... In-Reply-To: <4A382998.4010300@ovro.caltech.edu> References: <4A382998.4010300@ovro.caltech.edu> Message-ID: <4A38F542.9010106@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de David Hawkins wrote: >> I see you guys talking about BDI3000 and I decided to ask a related >> question. >> >> Those who happen to own MPC8548CDS or something like this know it comes with >> a small box called CodeWarrior USB TAP. >> >> It is supposed to work with their software one has to pay for. I never used >> anything but GCC suite for anything GCC supports and always tried to avoid >> commercial tools like a plague. So I want to ask if somebody knows if there >> are any free tools for that thing... >> >> Not that I really need it for something but it is sitting in the box >> gathering dust and it would be nice ot somehow put it to do something... > > I've wondered the same thing. But didn't manage to find > anything out there. I've got three ... in the boxes > the Freescale MDS boards came in. Yup, got a handful myself. > The USB-TAP has a PowerPC processor in it ... so even if you > had to blow away the original firmware, I'm sure it wouldn't > be too hard to figure out what code would be required to > make the device look like a USB debugger, and then create > a set of USB commands to generate JTAG transactions. MPC866PVR133A in the one I disassembled. Not a top-of-the-line processor, but plenty for the job. > I think the main problem is getting the JTAG TAP codes > for manipulating JTAG. I've never seen a document relating > to that, so they are obviously NDA. Yup. > That being said, a weekend with a logic analyzer on a > BDI2000 JTAG connection would probably give you all the > info you need to figure out the appropriate JTAG > commands. The problem is that it is going to be different for every processor family and it may even change between processor revisions. There is a risk that, if you send the wrong sequence, you will damage your target processor (JTAG+BSDL can burn up chips too if you set outputs to fighting - DAMHIKT). With a large number of internal registers (many unknown) all hooked together into a single scan chain, it will take quite a bit of effort to hit each register individually to correlate the scan chain to the register. Oh, and you need to purchase a commercial debugger to do this, at which point you've already spent your money, got your functionality, and lost your incentive. > I've wired up the COP connection on my board via an FPGA, > so that I could conceivably use the PowerPC JTAG via > PCI. However, its the lack of open documentation on the > JTAG commands that has limited my interest in pursuing > this. However, it would be simple to use that interface > to log all JTAG transactions, to figure out all the > JTAG TAP instructions. The *JTAG* commands *ARE* documented and you can download the BSDL (Boundary Scan Description Language) files for all chips that I've looked at. This is *NOT* the internal proprietary "COP" scan chain - that just piggybacks on the JTAG/BSDL documented scan chain. The boundary scan allows you to wiggle the external pins on the processor... e.g. you can drive an address + data + CS*, toggle the WR* pin, and viola, you are programming flash (lots of pain glossed over). I've looked at UrJTAG but have not gone further because I already spent the money for a BDI ;-). I typically use the BDI for debugging for a few hours on board bring up (requires a good board design to start with - thanks, hardware guys!). After that, the only reason I need the BDI is to recover from loading bad bits into flash. The UrJTAG software + JTAG hardware + BSDL file would allow me to reprogram my flash for a lot less than the cost of a full JTAG debugger. This is where the USB-TAP support would be Really Nice. This would also work for the "burn & learn" method - if you are lucky and smart (in that order), it can be effective. Unfortunately, "burn & learn" falls into the CompSci category of halting problems: > Cheers, > Dave Best regards, gvb