From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] BDIxxxx and others...
Date: Wed, 17 Jun 2009 09:53:06 -0400 [thread overview]
Message-ID: <4A38F542.9010106@ge.com> (raw)
In-Reply-To: <4A382998.4010300@ovro.caltech.edu>
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
<http://www.urjtag.org/>
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:
<http://en.wikipedia.org/wiki/Halting_problem>
> Cheers,
> Dave
Best regards,
gvb
next prev parent reply other threads:[~2009-06-17 13:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 23:00 [U-Boot] BDIxxxx and others ksi at koi8.net
2009-06-16 23:24 ` David Hawkins
2009-06-16 23:34 ` Leon Woestenberg
2009-06-16 23:43 ` David Hawkins
2009-06-17 5:39 ` Wolfgang Denk
2009-06-17 15:41 ` ksi at koi8.net
2009-06-17 13:53 ` Jerry Van Baren [this message]
2009-06-17 15:55 ` David Hawkins
2009-06-17 5:37 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A38F542.9010106@ge.com \
--to=gerald.vanbaren@ge.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.