From: Kerl, John <hidden> Date: 2002-02-21 20:12:12
I don't want to scare anyone off ... JTAG *is* slow, painful,
and fraught with hazards -- *if* you try to write your own
software to bit-bang the JTAG pins over, say, a parallel port.
#1, the software is complex because you have to know the
pin-outs of all the parts in the scan chain on your board. Also
you have to wiggle pins such as write-enable, etc. which
normally the CPU's memory controller would wiggle for you. You
have to think about setup & hold times, etc.
#2, the bit rate out the parallel port is abysmal. Another
poster on this list cited 40 KB in 12 minutes; our experience
is comparable. As one of my co-workers said a few weeks ago,
"If it were any slower, it would be running backward."
However, if you get a tool such as Corelis (there are two other
major competitors whose names I can't remember), JTAG can
actually be very pleasant.
#1, you don't write any C code; you get the BSDL files from the
part vendors, and the board's netlist from the board vendor.
It normally takes our hardware guys a day or two to get it set
up for a new board, but from that point on we're good to go.
#2, Corelis (and I assume its competitors have similar
hardware) doesn't use the parallel port. Instead, it has a
proprietary card in an expansion slot in the PC which can
wiggle the JTAG lines a lot faster than the parallel port can.
Still not breaking any speed records, but maybe 250 KB in 2
minutes, which is better.
#3, socketed flash tends to wear out -- we've had a lot of
frustration with metal fatigue on the flash pins and/or socket
pins. When you use JTAG, you aren't wearing out your flash
pins by popping them in & out of sockets, in & out of the flash
programmer, dropping them, etc.
#4, board testers such as this don't just program flash -- they
can also do hardware verification, e.g. finding shorts, opens
etc. This is invaluable with new hardware.
The downside is that Corelis is not at all cheap; also the
flash-programming and board-verification options are licensed
separately. (My group finds that it can afford the
flash-programming option but can't afford the board-testing
option.)
So: JTAG is very complex, & is best left to the vendors which
understand it. & if you can afford the tools those vendors
build, it can make your life a lot easier.
-----Original Message-----
From: Jerry Van Baren [mailto:vanbaren_gerald@si.com]
Sent: Tuesday, February 19, 2002 4:41 AM
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: custom mpc8240 student project (long)
I agree, a socketed flash/EEPROM is your simplest method.
If you _really_ want to go JTAG, Mot has the 8240 BSDL available on their
web site:
http://e-www.motorola.com/collateral/MPC8240R1EBSDL.txt
This is the boundary scan description: it shows how the pins of the chip
can be scanned via JTAG. You can write to flash by repeatedly (and I mean
_repeatedly_!) scanning in the states of all the pins to wiggle the
address, data, and control signals (CS0*, write strobe, etc). By wiggling
the proper pins to simulate write cycles, you can write to flash.
Disclaimers:
* This is slow and painful.
* I've seen this done successfully with an Intel 386EX processor. That was
the only time someone I know was foolish enough to do this.
* Before it was done successfully with an Intel 386EX processor, I saw at
least two of them burned up. If you do the JTAG wrong, you can define
input pins to be output pins, causing a driver conflict which quickly blows
the pin.
* The BSDL tends to change with processor revisions. Make sure your BSDL
matches the processor revision!
* Flash works because there is typically no cycle-to-cycle timing
requirements to set up the write and the write itself.
* EEPROM can be a problem because it typically has a 100uSec max timing
requirement for the write sequence and you will find that hard to do via a
bit-bang parallel port. In the 386EX case, we were able to write to EEPROM
if software write protect was OFF. If it was ON, it required a hardware
JTAG accelerator card to unlock it because we could not do the whole
unprotect sequence fast enough.
* It takes three scans per write cycle: scan in the three sequences
<address, data, not write>, <address, data, write>, <address, data, not
write>. (It seems like it should be do-able in two, but my coworker was
unable to do it in two on the 386EX -- YMMV.) When you count how many bits
need to be shifted, you quickly realize how slow this is.
* Did I mention it is slow, painful, and fraught with hazards?
gvb
P.S. You are on your own if you go this route. Enjoy learning BSDL :-).
P.P.S On the positive side, if you want to work for a JTAG tester company,
you will have a _really_ impressive resume'.
At 03:32 PM 2/18/2002 -0700, Dustin Byford wrote:
I understand what you're saying about the COP so I need to evaluate my
options. We are all students working on this so I don't think my coleauges
will spring for the BDI since we don't have one available to us at the
University. Is the BDI1000/2000 the least expensive way to use the
JTAG/COP?
An alternate idea: What if I jumper in a 32 pin PDIP 8-bit EEPROM
somewhere
that I can boot from (RCS0/8-bit). I can pull this part off of the board
and
throw it in a programmer we have at the university. Hopefully I'll be able
to program it with something that will "simply" program itself onto the
TSOP
AMD flash (which would then be jumpered to (32-bit/RCS1). Remove the
jumpers
and reset the board and maybe I would have a ROM that can downlaod stuff
through the UART. Not the quickest of development cycles but it is a
no-cost
solution.
Or: Leave the EEPROM on RCS0 all the time. The AMD Flash on RCS1 all the
time and find another place to put the UART. Suggestions?
Thanks
--Dustin
From: Jim Thompson <hidden> Date: 2002-02-21 20:32:32
Kerl, John writes:
#3, socketed flash tends to wear out -- we've had a lot of
frustration with metal fatigue on the flash pins and/or socket
pins. When you use JTAG, you aren't wearing out your flash
pins by popping them in & out of sockets, in & out of the flash
programmer, dropping them, etc.
I can't begin to endorse just how true this is. The top of my
keyboard/desk are littered with tiny dead flash parts. Our (8245)
boards have had the sockets re-soldered at least 3 times each, due
entirely to handling stress.
Not mentioned is the fact that the pins eventually oxidize.
We'ld have used the COP (JTAG) port to program the flash, but the
proto board had the flash bus wired backwards (all to easy to do,
apparently), and the JTAG probe can't identify the flash parts.
#4, board testers such as this don't just program flash -- they
can also do hardware verification, e.g. finding shorts, opens
etc. This is invaluable with new hardware.
A BDM or JTAG probe should also allow you to get the internal state of
the CPU, which makes finding where your program went wrong possible,
if not easier.
Jim
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Ron Bianco <hidden> Date: 2002-02-21 22:40:05
My $.02:
Why don't you just use a regular old EPROM to hold your ppcboot monitor image.?
IIRC, it has a serial driver and provision for downloading linux kernels to
SDRAM.
I'm not sure if it has provision for R/W of flash, but maybe.
You're planning to run at a very low clock speed on your wire-wrapped board.
Ugh!
Better check the 8240 datasheet, there may be lower limits to what's allowed.
You'll be very handicapped by not having a BDI2000, which, BTW, uses JTAG port
for fast downloads to SDRAM.
Surely your school has a budget for development tools? The BDI would have other
uses besides just your 8240 project.
Good luck, Ron
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I don't want to scare anyone off ... JTAG *is* slow, painful,
and fraught with hazards -- *if* you try to write your own
software to bit-bang the JTAG pins over, say, a parallel port.
Now, the parallel port is as we all know parallel.
JTAG is, as we all know, synchronous serial.
To interface the former to the latter, one would normally
place a shift register with clock control inbetween. But
the clock control can be complex enough to justify replacing the
shift register and clock control with a single microcontroller
with a SPI port. The SPI port basically constitutes of a shift
register with clock control which we can misuse as such.
An AVR AT90S4433 would suffice. It also offer an HW UART if
serial communication is preferable to the parallel port.
One needs one full 8 bit port free to read an external octal
latch/register or FIFO, which other side will be hooked up to
the parallel port. Basically two chips and perhaps some glue.
Preferabely use an 9 bit wide FIFO like the 9x64 word deep
74HC7030. The 9'th bit can be connected to an control
line of the parallel port to distinguish between control
and data in the FIFO. The other end of the 9'th bit can
then be routed to an interrupt pin on the microcontroller
to avoid SW polling.
#2, the bit rate out the parallel port is abysmal. Another
poster on this list cited 40 KB in 12 minutes; our experience
Legacy parallel port perform @ 100 KByte/s. This is about
the saturation level of the microcontroller too. It is also
as fast than the SPI port will go, wich tops out below Fosc/4
or 8MHz/4 = 2MBit/s = 256 KByte/s. But datapushing at 100 KB/s
leaves a headroom of ~64 instructions per byte. Tight.
#1, you don't write any C code; you get the BSDL files from the
part vendors, and the board's netlist from the board vendor.
What I would like to know is wether this BSDL file can be used
to reversengineer the functionality of the internal TRAP logic.
We really don't want to do boundary scan in the true meaning of
the words, but rather we want to do what BDM4GDB does for us on
the XPC8xx series CPUs - control the core. I do HW, not really SW.
This is all about control - the manufactures should not be allowed
to place a NDA on this information. Redirecting customers to 3'd
party vendors of debug equipment effectively means customer
filtration. "If your are to small to afford the contiousely
astronomical cost of 3'd party tools, then you're also too
small for us." Need I remind you that the same melody can
be applied to GCC and LinuxPPC vs. 3'd party too...?
#3, socketed flash tends to wear out -- we've had a lot of
frustration with metal fatigue on the flash pins and/or socket
pins. When you use JTAG, you aren't wearing out your flash
pins by popping them in & out of sockets, in & out of the flash
programmer, dropping them, etc.
Zero Force Sockets? But really, reprogramming a flash is not the
right way to do debugging. One needs the good, old EPROM emulator.
It is really not that hard to make - works much the same way as the
JTAG dongle above, but parallel in both ends. Use either some dual
port SRAM - or - (larger) single sided SRAM plus bus mastering
capabilities between the MCU and the CPU (PowerPC.) The bus
mastering is not used for anything else than throwing the CPU
off the bus so that the MCU can update/patch the SRAM.
The easiest and most flexible solution is the dual ported SRAM
version, the cheapest is the single sided SRAM + bus mastering.
But GDB server stubs has to reside in the (DP)SRAM too. Reverse
channel communication can also be done through the same (DP)SRAM.
The open source community could really use such an beast, given
the current NDA state of JTAG. The dual ported SRAM version is
even CPU independant - EPROM/Flash chips looks the same regardless
of platform. Hmmm. Anyone want to do the GDB server part if I do
the hardware?
--
******************************************************
Never ever underestimate the power of human stupidity.
-Robert Anson Heinlein
GeirFRS@invalid.ed.ntnu.no
******************************************************
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Jerry Van Baren <hidden> Date: 2002-02-22 13:09:16
[snip]
quoted
#1, you don't write any C code; you get the BSDL files from the
part vendors, and the board's netlist from the board vendor.
What I would like to know is wether this BSDL file can be used
to reversengineer the functionality of the internal TRAP logic.
No. BSDL stands for Boundary Scan Description Language (well, I'm guessing
on the "DL", but that is probably right). Note the first term "boundary"
as in "the boundary of the chip". That is important. The BSDL file is
always (?) disclosed, not covered by a NDA. The original purpose for JTAG
was board test. With JTAG and BSDL, the tester can, for instance, set all
the pins in a net to inputs except for one, wiggle the target net high and
low with the one driven pin, and observe that all the pins in the net
wiggle properly. This tests the soldering and traces on the boards.
What you are asking for is the information covering the separate ring that
goes through the innards (registers) of the CPU.
We really don't want to do boundary scan in the true meaning of
the words, but rather we want to do what BDM4GDB does for us on
the XPC8xx series CPUs - control the core. I do HW, not really SW.
This is all about control - the manufactures should not be allowed
to place a NDA on this information. Redirecting customers to 3'd
party vendors of debug equipment effectively means customer
filtration. "If your are to small to afford the contiousely
astronomical cost of 3'd party tools, then you're also too
small for us." Need I remind you that the same melody can
be applied to GCC and LinuxPPC vs. 3'd party too...?
I suspect that it's about sanity preservation, not control. Releasing this
extremely complex information (which can vary from chip rev to chip rev) to
John Q Public is going to generate a LOT of technical support calls that
they are currently avoiding by carefully selecting who they release the
information to.
By the way, the 3rd party tool costs are NOT astronomical. Entry level is
$50 for a BDM4GDB, $150 for a Macraiger Wiggler. That is roughly the same
as the cost of the CPU you are trying to debug. That's pretty reasonable
in my book. With the BDI-2000 or Corolis accel card you are paying a LOT
more for the HARDWARE ACCELERATION. The software, which is the part
covered by the NDA, you can download from Macraigor for _FREE_ so
quicherbitchin:
http://www.ocdemon.net/Merchant2/merchant.mv?Screen=CTGY&Store_Code=MTS&Category_Code=FS
Now, back to the "boundary" in BSDL. You CAN program flash with only the
BSDL information. It isn't easy, but it CAN and HAS been done (by several
people on this list, as a matter of fact). If you want to start an Open
Source project doing this, you can start TODAY. Hey, you could become as
rich and famous as Wolfgang :-).
quoted
#3, socketed flash tends to wear out -- we've had a lot of
frustration with metal fatigue on the flash pins and/or socket
pins. When you use JTAG, you aren't wearing out your flash
pins by popping them in & out of sockets, in & out of the flash
programmer, dropping them, etc.
Zero Force Sockets? But really, reprogramming a flash is not the
right way to do debugging. One needs the good, old EPROM emulator.
JTAG programming flash is cheaper and easier if you are comparing equal
systems (parallel port dongles). All of the information necessary to
program flash via JTAG _is_ publicly available. If you are willing to
spend the money to build a SRAM dongle, you will find a Macraiger Wiggler
costs about the same with no assembly required, so where's the beef?
It is really not that hard to make - works much the same way as the
JTAG dongle above, but parallel in both ends. Use either some dual
port SRAM - or - (larger) single sided SRAM plus bus mastering
capabilities between the MCU and the CPU (PowerPC.) The bus
mastering is not used for anything else than throwing the CPU
off the bus so that the MCU can update/patch the SRAM.
The easiest and most flexible solution is the dual ported SRAM
version, the cheapest is the single sided SRAM + bus mastering.
But GDB server stubs has to reside in the (DP)SRAM too. Reverse
channel communication can also be done through the same (DP)SRAM.
Couple of reality checks:
JTAG SRAM
---- ----
Pins 5 32 (possible 32x4)
Size 10 pin header 32 pin DIP, no wait TSOP,
no wait BGA, no wait...
(DIP footprint by 1++ inches long)
Speed don't care full bus speed (66MHz)
Support logic 1 logic buffer CPLD and buffers
Future works Obsolescence is a continual problem
Cost $15 in parts $$$
Software roughly the same both ways
The open source community could really use such an beast, given
the current NDA state of JTAG. The dual ported SRAM version is
even CPU independant - EPROM/Flash chips looks the same regardless
of platform. Hmmm. Anyone want to do the GDB server part if I do
the hardware?
Do it, be rich and famous, but my professional opinion is that using JTAG
to program flash is going to be a much easier path to the same end goal.
gvb
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-02-23 19:16:28
Jerry Van Baren wrote:
I suspect that it's about sanity preservation, not control.
This is exactly the reason and all semiconductor companies do this.
They use the NDA as a mechanism to track who may be calling for support,
not to necessarily protect any information. This is done for several
categories of features, not only the COP (in the case of Motorola).
By the way, the 3rd party tool costs are NOT astronomical. Entry level is
$50 for a BDM4GDB, $150 for a Macraiger Wiggler.
For BDM devices, yes. The COP tools are usually more expensive, except in
the case of more flexible tools like those from Abatron where the hardware
cost can be amortized across a wide range of devices. Due to the complexity
of COP, I think everyone uses some kind of hardware acceleration just to
make it usable. You have to be moving bits at megabit speeds to make
reasonable progress with COP, especially when you are debugging operating
systems with MMUs and caches enabled on the processor.
Of course, for those of us that work for a living, these tools can pay for
themselves in a matter of hours :-).
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
What I would like to know is wether this BSDL file can be used
to reversengineer the functionality of the internal TRAP logic.
What you are asking for is the information covering the separate ring that
goes through the innards (registers) of the CPU.
I did take a quick look at the BSDL file and the enclosed JTAG
documentation in the 8260 user manual. But at first glimse,
there was nothing to hint at internal debug registers the
like of BDM. Unfortunately. But there is plenty codespace
left in the 4 bit command register to implement debugging
and an alternate scan line.
quoted
This is all about control - the manufactures should not be allowed
to place a NDA on this information. Redirecting customers to 3'd
I suspect that it's about sanity preservation, not control. Releasing this
extremely complex information (which can vary from chip rev to chip rev) to
John Q Public is going to generate a LOT of technical support calls that
they are currently avoiding by carefully selecting who they release the
information to.
The actual motive/reason of Motorola for placing this under NDA is
not really our concern. What is our concern is that Motorola like
all other manufacturers of JTAG enabled controllers _has_ put an
NDA on this information. That hurts us, or at least a large number
of us even if you do not count yourself in. This is the situation
the OS market was in that lead to Linux in it's time. And GCC.
Hence it is an situation we have to remedy. Cracking or stealing
information is not the style of the Open Source community. Neither
is giving in. Reverse engineering might so the trick, since I refute
the assertion that the JTAG debug logic is 'extremely complex.'
I'm almost willing to bet that it is close to or identical to
the tried and tested BDM implementation embedded within JTAG.
But I do not dispose neither an BDI200 nor an 82xx to do logic
analysing and logging with. But even if I did I would not have
a goog enough understanding of how GDB works to break down the
problem into manageable pieces.
But revers engineering will by its very nature be a continuing
struggle to overcome increasingly strong encryption put in place
by the manufacturers.
Hence we develop our own solutions or - in this case - workarounds.
I do not see why you oppose my suggested alternative so much. EPROM
emulators har been around since the beginning of digital logic and
does indeed work. You are quite correct in that EPROM emulators are
both more complex and more costly than a JTAG dongle. But as long
as we are cut off from the information required to utilize an JTAG
dongle (which I also suggested how to build) we are forced to find
alternatives and workarounds, wouldn't you agree?
By the way, the 3rd party tool costs are NOT astronomical. Entry level is
$50 for a BDM4GDB, $150 for a Macraiger Wiggler. That is roughly the same
I have built BDM4GDB adapters for less than $5. Guss the wiggler
is much the same. It is not the HW that is the culprit. SW is.
as the cost of the CPU you are trying to debug. That's pretty reasonable
in my book. With the BDI-2000 or Corolis accel card you are paying a LOT
more for the HARDWARE ACCELERATION.
I can build my suggested accelerated JTAG dongle for less than $20.
An even faster solution would be to use a PowerQUICC SCC port in
transparent mode for the JTAG shift register requirement. This, of
cause, requires the presence of an existing PowerQICC system.
Just a suggestion.
The software, which is the part covered by the NDA, you can download
from Macraigor for _FREE_ so quicherbitchin:
The first shot is, as we know, always free.
Source project doing this, you can start TODAY. Hey, you could become as
rich and famous as Wolfgang :-).
I do not even come close to the SW knowledge of Wolfgang or Malek, so
I am more likely to enter a joint venture. It is the SW that is stopping
me, not the HW. And yes, it is quite possible to do Open Source HW
in the BSD license style. The GNU style is harder to apply since
HW is all about recycling old ideas (prior art) and implementations
in new permutations.
spend the money to build a SRAM dongle, you will find a Macraiger Wiggler
costs about the same with no assembly required, so where's the beef?
The assurance is about control. To know that I'm not at the whims
of Macraigor, that the dongle implmentation is here to stay. Etc.
There are more pins on the HC244 buffers within the JTAG dongle.
But that is not the point. The point is that the EPROM emulator
we can use, the JTAG we can not due to NDA.
Size 10 pin header 32 pin DIP, no wait TSOP,
no wait BGA, no wait...
(DIP footprint by 1++ inches long)
Five more pins already on the JTAG header. But no, it will not
come close to an EPROM emulator (200++ pins) The SRAM packeage
does not apply, since it will not sit in the actual system but
typically on an expansion board with access to the local bus an
of cause the boot chip select line /CS0. But for those systems
that can spare the area the DIP socets occupy the dongle can
interface directly into these. Do not worry to much about the
physical layout of the EPROM emulator. It can be done.
Speed don't care full bus speed (66MHz)
No EPROM can do full bus speed. SRAM can, but that is beside the
point. We will rely on the System Interface Unit to do its job.
Support logic 1 logic buffer CPLD and buffers
Nix, No, Njet. I can do this dongle in only discreets.
An AVR would be helpful, but is not really required.
Future works Obsolescence is a continual problem
The other way around. Todays EPROM/Flash will look the same in
10 years from now. All embedded CPUs on the marked today can
make use of 20 year old chips, so I do not worry. The consept
can be modernized too. The JTAG dongle will also look mostly the
same in 10 years. It is the SW that is the question for both cases.
But less so for the EPROM emulator. The JTAG implementation can as
you yourself claim, change from one core revision to the next.
Cost $15 in parts $$$
Let me guess at $30-50 for the 8 bit wide EPROM emulator.
Software roughly the same both ways
Not by a far shot. JTAG means commersial software given
current state of affairs. The EPROM emulator means GDB.
Do it, be rich and famous, but my professional opinion is that using JTAG
to program flash is going to be a much easier path to the same end goal.
I do not disagree. It is just that I am cut of from JTAG.
Which means I've got to stay at 8xx series with BDM. This pisses me off.
But of cause, if noone wants such an EPROM emulator then there
is no point in me designing and testing one, is there?
--
******************************************************
Never ever underestimate the power of human stupidity.
-Robert Anson Heinlein
GeirFRS@invalid.ed.ntnu.no
******************************************************
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Christian Pellegrin <hidden> Date: 2002-02-27 11:46:44
On Mon, 25 Feb 2002, Geir Frode Raanes wrote:
quoted
The software, which is the part covered by the NDA, you can download
from Macraigor for _FREE_ so quicherbitchin:
The first shot is, as we know, always free.
not true. I had to use JTAG on arm7tdmi project and the tool from
Macraigor it's not free. I mean the module and the .so that drives the
raven are propietary (object only, no warranty) software. I didn't managed
to make it working for parport problems, kernel symbols incompatibility
and such. I gave up, build a parport-jtag adaptor myself and wrote an
(open-source 100%) jtag downloader and basic debugger. Someday I hope to
have enough time to integrate it with gdb.
I do not disagree. It is just that I am cut of from JTAG.
Which means I've got to stay at 8xx series with BDM. This pisses me off.
I agree 100% with you.
But of cause, if noone wants such an EPROM emulator then there
is no point in me designing and testing one, is there?
Be aware that I read on an italian electronic magazine that eprom
emulation is patented ..... patents madness :-((((
Bye!
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/