custom mpc8240 student project (long)

custom mpc8240 student project (long)

[Dustin Byford]

Hi,

For purely academic purposes I am building an IP router based on an mpc8240
in my "capstone" EE class at NMSU.  I was wondering if someone who may have
done something similar could tell me if I'm working in the right direction.
I've done some research with the list archives and I think I have decided on
a basic hardware layout.  I'm just wondering if my ideas are sane and I have
a couple of questions.

I will be wire-wrapping the entire design (sockets have been acquired) and
and plan to use:

MPC8240 (At ~30MHz bus)
National 16550 UART connected to RCS1, etc...
2 16-bit flash ROMs (8MByte total) (Am29LV320D x2) connected toRCS0, etc...
128MB SDRAM in 1 DIMM
PCI (wire wrap board attached to a backplane) with 2 FA310TX netgear cards
There is also a reset circuit, a power supply, and I'm guessing I need a
buffer between the UART and the CPU and a MAX232 for serial line driving.

I also planned to start out by programming the ROMs through the BDM/JTAG port
on the CPU.  I'll start with the GDB target for MPCs and attempt to load a
program into RAM to program the 2 flashes, with--ppcboot.  Hopefully this
will allow me to run the 2.4_devel version of the ppc kernel, busybox/uclibc
as a distro and iptables as the "router".

I'm expecting many frustrations (I mean learning experiences) along the way
and I suppose I'll begin with sandpoint code for ppcboot and the kernel.

So, what do you think.  Will it work?  Also, is there maybe a different
kernel I should start out with.  Anybody see any major pitfalls?

Also, in the chance that this works I would love to PCB it and fire it up at
200 MHz/100MHz Memory/66MHz PCI and then hang it on my wall because I have to
give the 8240 back to my professor.  I can design the PCB but what is the
cheapest way to get a 4-6 layer board done.

Thanks for any and all advice!

			--Dustin

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Dustin Byford]

Thanks for your response.  I was hoping to use something I
 build myself to do the BDM programming.  Something similar
 to what people are doing for the LART project with JFlash.
  I understand a NDA is required for all the details about
 the JTAG/COP port on the MPC8240 but all I really need
 here is basic flash programming so I can bootstrap
 something that will load a real bootloader through the
 uart.  Is enough information about the BDM available to do
 this?  I'm not afraid of hacking something together if the
 information is there.

Thanks again.


      --Dustin


On Mon, 18 Feb 2002 21:17:26 +0100
 Langus Matevz    RDHW_EXT <langus@iskratel.si> wrote:
> Hi!
>
> I don't see any reasons to add buffers betwen UART and
>  CPU. Max232 does all
> driving usually.
>
> Programming Flash thru BDM is a good idea, just be
>  careful which BDM
> debugger you will buy. I have a lot of problems with
>  Windriver's
> visionProbe-II and visionICE-II. They do not work with
>  never versions of
> MPC8260 - I need to renew (and pay) licence in order to
>  get it working. And
> Windriver is responding very slowly...
> Choose another one.
>
> >but what is the cheapest way to get a 4-6 layer board
>  done.
>
> Try www.iskratel-electronics.si
>
> Matevz
>
> -----Original Message-----
> From: Dustin Byford [mailto:dustin@firein.net]
> Sent: Monday, February 18, 2002 11:34 AM
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: custom mpc8240 student project (long)
>
>
>
> Hi,
>
> For purely academic purposes I am building an IP router
>  based on an mpc8240
> in my "capstone" EE class at NMSU.  I was wondering if
>  someone who may have
> done something similar could tell me if I'm working in
>  the right direction.
> I've done some research with the list archives and I
>  think I have decided on
> a basic hardware layout.  I'm just wondering if my ideas
>  are sane and I have
> a couple of questions.
>
> I will be wire-wrapping the entire design (sockets have
>  been acquired) and
> and plan to use:
>
> MPC8240 (At ~30MHz bus)
> National 16550 UART connected to RCS1, etc...
> 2 16-bit flash ROMs (8MByte total) (Am29LV320D x2)
>  connected toRCS0, etc...
> 128MB SDRAM in 1 DIMM PCI (wire wrap board attached to a
>  backplane) with 2
> FA310TX netgear cards There is also a reset circuit, a
>  power supply, and I'm
> guessing I need a buffer between the UART and the CPU and
>  a MAX232 for
> serial line driving.
>
> I also planned to start out by programming the ROMs
>  through the BDM/JTAG
> port on the CPU.  I'll start with the GDB target for MPCs
>  and attempt to
> load a program into RAM to program the 2 flashes,
>  with--ppcboot.  Hopefully
> this will allow me to run the 2.4_devel version of the
>  ppc kernel,
> busybox/uclibc as a distro and iptables as the "router".
>
> I'm expecting many frustrations (I mean learning
>  experiences) along the way
> and I suppose I'll begin with sandpoint code for ppcboot
>  and the kernel.
>
> So, what do you think.  Will it work?  Also, is there
>  maybe a different
> kernel I should start out with.  Anybody see any major
>  pitfalls?
>
> Also, in the chance that this works I would love to PCB
>  it and fire it up at
> 200 MHz/100MHz Memory/66MHz PCI and then hang it on my
>  wall because I have
> to give the 8240 back to my professor.  I can design the
>  PCB but what is the
> cheapest way to get a 4-6 layer board done.
>
> Thanks for any and all advice!
>
> 			--Dustin
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Wolfgang Denk]

Dustin,

in message <web-8690106@zipmail.com> you wrote:
>
> Thanks for your response.  I was hoping to use something I
>  build myself to do the BDM programming.  Something similar

If it was just for the hardware, you could just use the parallel port
adapter of the BDM4GDB project.

But this is just the hardware, and you still need the software part...

>  to what people are doing for the LART project with JFlash.
>   I understand a NDA is required for all the details about
>  the JTAG/COP port on the MPC8240 but all I really need
>  here is basic flash programming so I can bootstrap

Forget it. The JTAG/COP is much more complicated than the BDM  inter-
face.  Even  if  you get he information (under NDA), you will spend a
lot of work implementing the stuff, and  getting  things  worling  is
probably anything else but fun.

>  something that will load a real bootloader through the
>  uart.  Is enough information about the BDM available to do
>  this?  I'm not afraid of hacking something together if the
>  information is there.

Even if you calculate just a very low hourly rate you will be  better
off with buying a BDI2000.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
See us @ Embedded Systems Nuremberg, Feb 19-21, Hall 12 K01 (with TQ)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Wolfgang Denk]

In message <auto-000008693306@zipmail.com> you 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?

In terms of time AND money AND power: definitely.

> 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.

OK, now you can program your boot device. You plug it in,  power  on,
and you are lucky: no magic smoke to be seen.

But your code doesn't run (and I guarantee you that it will  not  run
on first attempt).

I bet you'd like to have a debugger then...

> 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?

Yes, two: find some working hardware which already has  the  firmware
running, or get yourself the neccesary tools.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
See us @ Embedded Systems Nuremberg, Feb 19-21, Hall 12 K01 (with TQ)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Jerry Van Baren]

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
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: custom mpc8240 student project (long)

[Bob Piatek]

A good book on the subject:

The Boundary-Scan Handbook by Kenneth P. Parker
Kluwer Academic Publishers
http://www.wkap.nl/

Bob

fishcamp engineering
105 W. Clark Ave
Orcutt, CA  93455
TEL: 805-937-6365
FAX: 805-937-6252


-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org] On Behalf Of Jerry
Van Baren
Sent: Tuesday, February 19, 2002 3: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
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Greg Griffes]

>
> 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?
>

The removable device is a good idea.  Once you get the process down,
you should be able to build an image, program it into the part, install the
part on the board and boot it.  Make that image a serial loader that can
program the other flash part if you must, or just run from the EEPROM
during development.

I agree with Jerry, JTAG is horribly slow and your time would be spent
more wisely on a serial loader or the end application.  I have written a
couple of JTAG loaders that operate on the PC serial port using a
Xilinx Parallel III cable.  The last one requried 12 minutes to program
40Kb into flash.  We use that as a last resort to load a blank board
with a serial loader.

Greg Griffes


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: custom mpc8240 student project (long)

[Kerl, John]

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
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: custom mpc8240 student project (long)

[Jim Thompson]

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/

RE: custom mpc8240 student project (long)

[Ron Bianco]

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/

Re: custom mpc8240 student project (long)

[Dustin Byford]

Thank you all for the suggestions.  The BDI was simply too
 much for the school to spend on a small group of people.
  I did however contact Macraigor Systems and explain my
 situation.  They have donated a wiggler so it looks like
 I'm in business, thanks to Macraigor!

On Thu, 21 Feb 2002 14:40:05 -0800
 "Ron Bianco" <ronb@junction.net> wrote:
>
> My $.02:
>
> Why don't you just use a regular old EPROM to hold your
>  ppcboot monitor image.?

Haven't quite decided on the ROM exactly, still waiting on
 samples from AMD but a regular EPROM sounds like good idea
 for now.

> 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.

>From the hardware spec it looks like the PLL can be
 configured to 33Mhz/pci 33mhz/memory 100Mhz cpu.
  Hopefully the wirewrap can handle this.

>
> Good luck, Ron

It is starting to sound like I'm really going to need luck,
 so thanks.


     --Dustin

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Dustin Byford]

On Thu, 21 Feb 2002 14:32:32 -0600
 Jim Thompson <jim@musenki.com> wrote:
>
> 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.

Fortunately I found a little zif to pga socket that I can
 put in a wire wrap socket.  If the pins start oxidizing
 before this project is over I'm in trouble anyway.


     --Dustin

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: custom mpc8240 student project (long)

[Geir Frode Raanes]

On Thu, 21 Feb 2002, Kerl, John wrote:

>
> 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/

RE: custom mpc8240 student project (long)

[Jerry Van Baren]

[snip]

> > #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 :-).

> > #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/

RE: custom mpc8240 student project (long)

[Kerl, John]

> Now, the parallel port is as we all know parallel.
> JTAG is, as we all know, synchronous serial.

JTAG is a four-pin protocol -- test data in (TDI), test data out
(TDO), TMS (test mode select) and TCK (test clock).  TRESET
(asynchronous reset) is an optional fifth pin.  And of course you
need at least one ground pin; more for higher clock speeds.

What happens, in the software-only solution, is that those four
pins are connected to a ribbon cable which plugs into the PC's
parallel port.  Inside the software on the PC, you just set/clear
bits, reading and writing a few bits in the byte-wide LPT/parport
interface.  No auxiliary microcontroller is required (although I
suppose Corelis et al. probably have a micro on their expansion
card).

I guess you can call the parallel port "parallel" and the JTAG
pins "serial", but that's how it works -- in software you use
just a few pins on the parallel port, and bit-bang each of them
serially.

> To interface the former to the latter, one would normally
> place a shift register with clock control inbetween. But
> ...
> ...
> ...

You've lost me here; I lack the hardware background.  Are you
perhaps suggests ways to build a JTAG hardware device?

> 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.

I don't know what you mean by "trap" logic.  I know that JTAG
itself is an open standard, in the sense that you can get books
on it, and if you want the official protocol document, you can
get that from the IEEE at a nominal fee.  I don't think that the
JTAG standard can be considered closed.

As for the PPC debug logic (the kind of stuff a probe plugs
into), my experience is that that is documented in the Motorola
8xx manuals.  (On the other hand, I've never attempted to control
the debug header in software, so I don't know if the manuals are
complete.  Perhaps someone can correct me on this.)

> This is all about control - the manufactures should not be
> allowed to place a NDA on this information.

IMHO, I don't think it's the *information* that's so much being
held closed.  From my experience, I don't see JTAG being in an
NDA state.  The JTAG protocol is conceptually simple; BSDL files
are published; we've written bit-bang software to flash our
boards and it does work (of course the code is time-consuming to
write, and slow to run).

> 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...?

Agreed.  I don't think it's a closed-information problem, but I
do believe that the current state of the marketplace (again,
IMHO; I've been doing embedded stuff for just over a year, so I'm
no expert) is that there are a few vendors out there who build
these kinds of tools and get away with charging astronomical
prices -- not because of closed *specifications* (a` la Micro$oft
& their ilk) but because no one has come up with a cheaper,
viable alternative *implementation*.  The protocols are open, but
the source is closed.

Which raises the question:  Do JTAG-tool vendors' prices really
reflect their true cost?  If so, then I wouldn't want to even
*try* to compete with them.  If not (i.e. they're getting rich
off the rest of us), then yes, I would hope that someone,
someday, *could* open-source tools like these.  By "tools like
these" I, personally, mean (a) flash programming and (b) boundary
scan for hardware verification.  & by which Geir means (c) BDM
tools.  All three are important.

& I agree that these are precisely the same arguments made in the
software world:  For example, OS's were solid gold for software
vendors -- BSD was revolutionary for even *selling* you a license
to see their source.  Everyone else thought that operating
systems were far too precious intellectual property to give away,
or even give you the slightest peek at -- enter Torvalds, and of
course the rest is history.  & people like Stallman with GCC,
Wall with Perl, and so on.

Maybe the JTAG world is ready to be similarly shaken up.

The unique problem with JTAG is that the software-only solution
is, I believe, severely limited by parallel-port data rate.  If
someone were to write and open-source a very flexible, elegant,
general-purpose BSDL-and-netlist parser which would read in some
data files & start flash programming, all without the user having
to write a single line of code -- it would still be slow.
Efficiency (I believe) requires a hardware component.

The open-source community thrives on downloadable source.  But
how do you download an expansion card?  Either (a) you
open-source the schematics, BOM, Gerber files, etc. for your card
(leaving the non-trivial assembly step to the end user), or (b)
you build them in your garage & sell them on a mail-order basis
for a reasonable fee.

A third possibility is (c) maybe the efficiency isn't a problem
-- if all you want is to open-source a software-only, and slow,
solution which can flash a boot loader into a board, to the point
where TFTP can take over.  What I do at my job is to use a tool
like Corelis to store my debug monitor (~200KB) into flash.
(Again, we can afford only the flash-programming part of Corelis.)
Once the monitor is on a given board, I rarely need to do it again.
My debug monitor includes TFTP server code, and on-board flash
programming logic written in C.  So I can then TFTP up my
zvmlinux.initrd (> 2MB) in about 30-40 seconds and, if desired,
have my debug monitor store it into flash in about about 2
minutes.  Or TFTP up a new copy of my debug monitor itself, &
re-flash that, in even less time.  So, for me at least, a
Corelis-like tool is only needed for small programs, e.g. our
monitor, or PPCBoot.

So those are the two feasability issues: (1) Can the software &
hardware really be done more affordably that what's currently on
the market?  And (2) how do you open-source hardware?  Or do
you have to?

----------------------------------------------------------------

List members:

Please excuse my having gone on at some length on this subject,
if it's not your area of interest.  However, these issues drive
to the very heart of the deepest frustrations, the most
time-consuming problems and the biggest budget headaches I've run
into in my embedded career.  The issues Geir is bringing up,
I believe, are central.

I write software not for pre-verified boards such as RPX, but for
custom-built boards designed by my co-workers.  One of my tasks
is to *be* the guy who verifies the board, mainly using our
homegrown debug-and-test monitor software.  And I've found that
issues I encounter are as likely to be hardware bugs as software
bugs.  This is brand-new for me; when was the last time you
*expected* to encounter hardware bugs programming your PC?

I've found that peeky-pokey testing can reveal many outright
hardware problems, but flaky, intermittent or irreproducible
problems are outside my current ability to diagnose.  & if I tell
my hardware-designing co-workers that I have an intermittent
problem that I can't reproduce, typically what they do is go look
at their schematics and/or VHDL code for a half an hour, come
back, and shrug: "Looks OK to me."  This is precisely where we
need (but can't afford!) automated testing.  And I don't think
I'm the only embedded programmer out there having to work with
hardware which has not yet been verified.  Most importantly, what
if you think you have a problem with your OS port, or your device
driver -- what seems to be a software problem -- and really, it's
a hardware problem which you simply hadn't found?

Once a board is known to be solid, then (& only then) can one
start to port an OS, write applications, etc.  Boundary-scan
would be useful for the board-verification phase; BDM tools would
be nice for the application phase.  & flash programming is useful
in either case.

I've found that JTAG is a very powerful thing, which (I believe)
could have saved me a lot of headaches and weeks or months of
wasted time -- except for the prohibitive cost in terms of either
time or money.  And I suspect I'm not alone in that either.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Wolfgang Denk]

In message <C08678384BE7D311B4D70004ACA371050B7632EA@amer22.avnet.com>
John Kerl wrote:
>
> What happens, in the software-only solution, is that those four
> pins are connected to a ribbon cable which plugs into the PC's
> parallel port.  Inside the software on the PC, you just set/clear
> bits, reading and writing a few bits in the byte-wide LPT/parport
> interface.  No auxiliary microcontroller is required (although I

Right, and  this  is  how  simple  /  cheap  BDM  and  JTAG  debugger
("parallel port adapters") work. See for instance the BDM4GDB project
on Sourceforge.

> I don't know what you mean by "trap" logic.  I know that JTAG
> itself is an open standard, in the sense that you can get books
> on it, and if you want the official protocol document, you can
> get that from the IEEE at a nominal fee.  I don't think that the
> JTAG standard can be considered closed.

JTAG defines just HOW to exchange information  over  this  interface,
but  you  need additional information to actually be able to assemble
or understand the information you send or receive.

> As for the PPC debug logic (the kind of stuff a probe plugs
> into), my experience is that that is documented in the Motorola
> 8xx manuals.  (On the other hand, I've never attempted to control
> the debug header in software, so I don't know if the manuals are
> complete.  Perhaps someone can correct me on this.)

*xx is completely different. It uses a BDM  interface,  and  this  is
indeed  well  documented  -  which made it possible to come up with a
free GDB extension and a semi-free (if you  build  it  yourself;  but
it's still < $50 for the ready-to-run box) BDM4GDB design.

> IMHO, I don't think it's the *information* that's so much being
> held closed.  From my experience, I don't see JTAG being in an
> NDA state.  The JTAG protocol is conceptually simple; BSDL files
> are published; we've written bit-bang software to flash our
> boards and it does work (of course the code is time-consuming to
> write, and slow to run).

If you try to control a CPU (say, a MPC82xx) over the JTAG  (or  COP)
debug  port,  you need additional information; the JTAG specification
is not enough.

Motorola will provide this information,  but  only  under  NDA.  They
claim  that  one can learn intimate details about the inner design of
their CPUs from that document, so they need  to  keep  it  closed  to
protect their intellectual property. (Their worrds, not mine!)

That's the reason why BDM4GDB supports only BDM.  The  BDM4GDB  would
also  work  with  a  JTAG  interface  - in fact even the connector is
already there. We would like to provide a JTAG extension for BDM4GDB,
but since it's based on GDB it will be Open Source, and this does not
mix with Moto's NDA.

End of the story. I tried many times, through different channels, but
Moto will not give in.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A direct quote from the Boss: "We passed over a lot of good people to
get the ones we hired."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: custom mpc8240 student project (long)

[Dan Malek]

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/

RE: custom mpc8240 student project (long)

[Geir Frode Raanes]

On Fri, 22 Feb 2002, Jerry Van Baren wrote:

>
> [snip]
>
> >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.

> >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.


> Couple of reality checks:
>                  JTAG            SRAM
>                  ----            ----
> Pins            5               32 (possible 32x4)

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/

RE: custom mpc8240 student project (long)

[Christian Pellegrin]

On Mon, 25 Feb 2002, Geir Frode Raanes wrote:

>
>
> > 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/