[U-Boot-Users] U-Boot on MPC8280

[U-Boot-Users] U-Boot on MPC8280

[Rod Boyce]

This is just my $0.02 worth but I have used our BDI2000 to debug User land
application, Kernel, and device drivers at the same time.  It is an
invaluable tool when tracking down both software and hardware bugs.  In fact
I will start hardware debugging with our BDI before cabling up a Logic
analyzer.  
I can say that without a doubt if we had not use the BDI2000 in this way we
would have ended up redesigning the hardware to get around some perceived
limitations.  Instead I found the software bug and fixed it.  I did all this
in about 3-hours work as well.

I don't use the BDI all the time to debug user mode applications but when
you want to stop the hole processor it is invaluable.  To be able to step
through user code and then jump into the kernel on system calls is just
great.

I cannot tell you how much time our BDI has saved us.  We also have a Vision
ICE in another office I am not completely familiar with the Vision Ice but
compared to the functionality I get from a BDI the Vision Ice is a very poor
second.


Regards,
Rod

-----Original Message-----
From: Wolfgang Denk [mailto:wd at denx.de]
Sent: Thursday, January 08, 2004 4:46 AM
To: David Aldrich
Cc: Matias Sundman (AL/EAB); u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] U-Boot on MPC8280 


Dear David,

in message
<0E8A20F2EB7BD7119C1F00508BB333780E5D7B@tmservermail02.t-modus.nec.co.uk>
you wrote:
> 
> Is it true that the BDI is not suitable for user app debug?  Is this a

Yes, this is true. Well, you _can_ use  it,  but  you  have  manually
navigate  through  the  kernel virtual address space to find what you
are looking for. Sometimes  this  is  necessary  (typically  to  find
kernel  bugs),  but  this is definitely nothing to do for the average
user.

> problem in practice?

No, it is not.

Kernel debugging and application debugging are two separate  weorlds,
like  kernel  address  space  and  user  address  space  are  clearly
separated. There is tools for both of them: for the firmware,  device
drivers  and  kernel  debugging  you  use  the  BDI2000, and for user
applications you use gdbserver or gdb.

Note that this does not mean  any  loss  of  productivity:  both  the
BDI2000  and  gdbserver  "speak" GDB remote protocol, so you will see
absolutely the same user interface.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"If the code and  the  comments  disagree,  then  both  are  probably
wrong."                                                - Norm Schryer


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] U-Boot on MPC8280

[John W. Linville]

Rod Boyce wrote:

>This is just my $0.02 worth but I have used our BDI2000 to debug User land
>application, Kernel, and device drivers at the same time.  It is an
>  
>
Rod,

We, too, have used the BDI2000 in such a fashion.  I agree that it can 
be invaluable when debugging the interaction between a userland 
application and a kernel driver.

Can you describe the method you use to do this?  Our process is a bit 
cumbersome, involving putting a breakpoint in a driver's ioctl() 
function that will only be called by our application.  Once it is hit, 
we use add-symbol-file to get the information for our application's 
binary, and we are able to proceed.  This is on a PowerPC chip, with the 
special "BDI2000 support" hack turned-on.

Is your method any "cleaner"?

Thanks,

John

-- 
John W. Linville
LVL7 Systems, Inc.

[U-Boot-Users] BDI2000 vs Vision-ICE

[Mike Wellington]

People at my place of work are telling me that the
Vision-Ice supports "backtrace" and the BDI2000 does
not.   I looked on the Abatron website and it doesn't
say.  Can anyone confirm or deny this?

By "backtrace", I mean the ability to set a breakpoint,
hit that breakpoint, and be able to see the last N
instructions executed.

-mike wellington
  wellington at lucent.com



John W. Linville wrote:

> Rod Boyce wrote:
> 
>> This is just my $0.02 worth but I have used our BDI2000 to debug User 
>> land
>> application, Kernel, and device drivers at the same time.  It is an
>>  
>>
> Rod,
> 
> We, too, have used the BDI2000 in such a fashion.  I agree that it can 
> be invaluable when debugging the interaction between a userland 
> application and a kernel driver.
> 
> Can you describe the method you use to do this?  Our process is a bit 
> cumbersome, involving putting a breakpoint in a driver's ioctl() 
> function that will only be called by our application.  Once it is hit, 
> we use add-symbol-file to get the information for our application's 
> binary, and we are able to proceed.  This is on a PowerPC chip, with the 
> special "BDI2000 support" hack turned-on.
> 
> Is your method any "cleaner"?
> 
> Thanks,
> 
> John
> 


-- 

=mike wellington
wellington at lucent.com
303.920.6412  Desk
720.434.7559  Cell

[U-Boot-Users] BDI2000 vs Vision-ICE

[Wolfgang Denk]

Dear Mike,

in message <3FFDC547.3010302@lucent.com> you wrote:
> People at my place of work are telling me that the
> Vision-Ice supports "backtrace" and the BDI2000 does
> not.   I looked on the Abatron website and it doesn't
> say.  Can anyone confirm or deny this?
> 
> By "backtrace", I mean the ability to set a breakpoint,
> hit that breakpoint, and be able to see the last N
> instructions executed.

I don't know about the Vision-Ice; but  I've  been  working  (several
years  ago) in a project were we spent a lot of $$$ to buy a SuperTAP
ICE by  Applied  Microsystems  exactly  because  they  promised  this
feature.  It  never  worked  for us. It didn't work at full processor
speed, and the problems where we really wanted a trace did  not  show
up  at  lower  clock  speeds.  The other setup used a MPC8xx with bus
divider  enabled  (CPU  clock  =  2  x  bus  clock).  With   such   a
configuration,  the  CPU does not output the signals you need for the
trace on any pins, so you cannot  get  any  trace  (no  matter  which
vendor's box you buy).

In my experience, this is marketing babble. For the low  level  stuff
("simple  problems"),  a  good logic analyzer is at least as capable,
and for  the  highlevel  ("complicated")  problems  it  doesn't  work
anyway,  and  a plain BDM/JTAG debugger plus a little brain and a lot
of experience gives beter results.

Just my $ 0.02 - ymmv.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.

[U-Boot-Users] BDI2000 vs Vision-ICE

[Richard Danter]

Mike Wellington wrote:
> People at my place of work are telling me that the
> Vision-Ice supports "backtrace" and the BDI2000 does
> not.   I looked on the Abatron website and it doesn't
> say.  Can anyone confirm or deny this?

I can't talk about the Abatron, but for vICE there are a couple of 
options which are/were available.

 >
 > By "backtrace", I mean the ability to set a breakpoint,
 > hit that breakpoint, and be able to see the last N
 > instructions executed.

In the old days there was vEVENT. It was a bus trace system which 
captured all accesses from the CPU to any/all peripherals. It was 
available for most of the architectures WR/EST supported. This was EOL'd 
in favour of the LA-Trace.

LA-Trace is a combination of a vPROBE or vICE with a full logic 
analyser. The reason for switching to this was that the old vEVENT could 
not keep up with the newer CPU's running at high (>50MHz) bus speeds.

The problem with both of these options, and any other system using bus 
capture, is that they don't see everything. When the CPU is executing 
code from cache there is nothing visible outside so all you see are the 
code and data read/writes associated with a cache miss. Worse still is 
that when a read occurs the cache will usually get a complete cache 
line, not just the word required. Somtimes the whole line will be used 
(as in sequential code) but not always. It's tricky working out what is 
relevant and what is not. As caches get bigger so this problem gets worse.

The best option is vTRACE, but it is available only on a limited number 
of CPU's. This is beacuse vTrace uses the trace capability built in to 
some CPU's. The best trace capabilities are in the ColdFIRE range - they 
all support data tracing as well as code, but on PowerPC you can get 
code trace on the 405x, 440GP and 56x (NEXUS). There are also some MIPS 
processors which have this capability.

Whilst we are talking about vICE, thought I would just mention that it 
now supports Linux debugging too on some CPUs. That is, it has MMU 
awareness for the 82xx and 405x CPUs so you can debug the kernel and 
loadable modules with full source code. More than that though, they now 
also support some user-land debugging. I spose this is more relevant to 
the linux mailing list though...

Rich

[U-Boot-Users] BDI2000 vs Vision-ICE

[Wells, Charles]

Mike,

> People at my place of work are telling me that the
> Vision-Ice supports "backtrace" and the BDI2000 does
> not.

I don't believe visionICE supports what you describe, but visionEVENT
(another WRS/EST product) does.  visionEVENT behaves like a classic "bus
capture" analyzer.  It's no longer a "10-bin BDM port connected device."
visionEVENT is housed in a seperate box that attaches to the bottom of the
visionICE case and requires two 80-pin high-density connectors on your
target for its connection.  Further, visionEVENT imposes some nasty
restrictions on the target (e.g. not being able to run the CPU clock at 2x
bus clock).

We bought the visionICE/visionEVENT stuff a couple of years ago.  I use
visionICE regularly and it works adequately for bringing up new targets and
debugging startup code.  We haven't use visionEVENT much at all.  We've just
never needed its capabilities.  I've never used the BDI2000, but it sounds
like its Linux integration is better than either visionICE or visionEVENT
(although WRS may have improved this since we took delivery of ours).  

BTW, I agree with Wolfgang's earlier point.  What really matters is the
capabilities of the debugger software front-end.  One of these days, I need
to get someone around here to approve the purchase of a BDI2000 and see how
it compares.

Regards,
Charlie

[U-Boot-Users] BDI2000 vs Vision-ICE

[VanBaren, Gerald]

I've used both VisionICE and BDI2000 (we bought two VisionICEs initially and only BDI2000s since then :-).  Both connect via the JTAG port and neither support traceback.  As Charlie points out, traceback requires capturing the address and data bus which is bloody tricky on todays processors.

With a JTAG or a software only debugger you could theoretically enable the "trace on branch" PPC exception and run at full speed in (very short :-) bursts, saving each branch location and then rebuild the traceback using the saved the branches, but that would still cause a significant speed degradation because of all the exceptions.  I don't know if anyone does this.  I have my doubts whether this would be useful due to the speed slowdown.

gvb


> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wells,
> Charles
> Sent: Thursday, January 08, 2004 5:57 PM
> To: u-boot-users at lists.sourceforge.net
> Cc: 'Mike Wellington'
> Subject: RE: [U-Boot-Users] BDI2000 vs Vision-ICE
> 
> 
> Mike,
> 
> > People at my place of work are telling me that the
> > Vision-Ice supports "backtrace" and the BDI2000 does
> > not.
> 
> I don't believe visionICE supports what you describe, but visionEVENT
> (another WRS/EST product) does.  visionEVENT behaves like a 
> classic "bus
> capture" analyzer.  It's no longer a "10-bin BDM port 
> connected device."
> visionEVENT is housed in a seperate box that attaches to the 
> bottom of the
> visionICE case and requires two 80-pin high-density connectors on your
> target for its connection.  Further, visionEVENT imposes some nasty
> restrictions on the target (e.g. not being able to run the 
> CPU clock at 2x
> bus clock).
> 
> We bought the visionICE/visionEVENT stuff a couple of years 
> ago.  I use
> visionICE regularly and it works adequately for bringing up 
> new targets and
> debugging startup code.  We haven't use visionEVENT much at 
> all.  We've just
> never needed its capabilities.  I've never used the BDI2000, 
> but it sounds
> like its Linux integration is better than either visionICE or 
> visionEVENT
> (although WRS may have improved this since we took delivery 
> of ours).  
> 
> BTW, I agree with Wolfgang's earlier point.  What really 
> matters is the
> capabilities of the debugger software front-end.  One of 
> these days, I need
> to get someone around here to approve the purchase of a 
> BDI2000 and see how
> it compares.
> 
> Regards,
> Charlie
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] BDI2000 vs Vision-ICE

[Mike Wellington]

Guys-
   My replies are in post.

-thanks

mike wellington
wellington at lucent.com


VanBaren, Gerald (AGRE) wrote:

> I've used both VisionICE and BDI2000 (we bought two 
VisionICEs initially and only BDI2000s since then :-).
Both connect via the JTAG port and neither support traceback.
As Charlie points out, traceback requires capturing the
address and data bus which is bloody tricky on todays processors.
> 
my project lead thinks visionIce/visionEvent has solved that
problem.   Since our CPU core is inside an FPGA I guess I could
conceivably watch the bus with ChipScope - an FPGA-based
logic analyzer which would give me raw bus cycles.

> With a JTAG or a software only debugger you could theoretically 
enable the "trace on branch" PPC exception and run at full
speed in (very short :-) bursts, saving each branch location
and then rebuild the traceback using the saved the branches,
but that would still cause a significant speed degradation
because of all the exceptions.  I don't know if anyone does this.

I don't know if anyone does this either, but I think it is
an excellent idea.

I have my doubts whether this would be useful due to the speed slowdown.
> 

I think my application can handle the speed slowdown.

>>-----Original Message-----
>>From: u-boot-users-admin at lists.sourceforge.net
>>[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wells,
>>Charles
>>Sent: Thursday, January 08, 2004 5:57 PM
>>To: u-boot-users at lists.sourceforge.net
>>Cc: 'Mike Wellington'
>>Subject: RE: [U-Boot-Users] BDI2000 vs Vision-ICE
>>
>>
>>Mike,
>>
>>
>>>People at my place of work are telling me that the
>>>Vision-Ice supports "backtrace" and the BDI2000 does
>>>not.
>>
>>I don't believe visionICE supports what you describe, but visionEVENT
>>(another WRS/EST product) does.  visionEVENT behaves like a 
>>classic "bus
>>capture" analyzer.  It's no longer a "10-bin BDM port 
>>connected device."
>>visionEVENT is housed in a seperate box that attaches to the 
>>bottom of the
>>visionICE case and requires two 80-pin high-density connectors on your
>>target for its connection.  Further, visionEVENT imposes some nasty
>>restrictions on the target (e.g. not being able to run the 
>>CPU clock at 2x
>>bus clock).
>>
>>We bought the visionICE/visionEVENT stuff a couple of years 
>>ago.  I use
>>visionICE regularly and it works adequately for bringing up 
>>new targets and
>>debugging startup code.  We haven't use visionEVENT much at 
>>all.  We've just
>>never needed its capabilities.  I've never used the BDI2000, 
>>but it sounds
>>like its Linux integration is better than either visionICE or 
>>visionEVENT
>>(although WRS may have improved this since we took delivery 
>>of ours).

Some think the visionICE, visionEVENT stuff has improved.  I'll
find out soon enough since management went ahead and bought it.

>>
>>BTW, I agree with Wolfgang's earlier point.  What really 
>>matters is the
>>capabilities of the debugger software front-end.  One of 
>>these days, I need
>>to get someone around here to approve the purchase of a 
>>BDI2000 and see how
>>it compares.
>>

Our debugger front-end is supposed to be great.  I haven't
fired it up yet for real.  I kinda need a U-Boot bootloader
for the Xilinx ML300/PPC405 first.   Or I could use Redboot ( part
of eCos Real-Time OS ) which I already have sorce for a ML300/PPC405
but I haven't figured out how to build it yet.


-EOF-