RE: [U-Boot-Users] U-Boot on MPC8280
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@denx.de] Sent: Thursday, January 08, 2004 4:46 AM To: David Aldrich Cc: Matias Sundman (AL/EAB); u-boot-users@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
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
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@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
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
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
participants (5)
-
John W. Linville -
Mike Wellington -
Richard Danter -
Rod Boyce -
Wolfgang Denk