Nicolas Pitre writes: > The best strategy is still probably to have a solid knowledge of what > should be going on and carefully placed printk's to a serial port. Indeed yes. Over the 4 complete machine architecture ports that I have personnally done myself (A5000, EBSA110, RiscPC, EBSA285), I have not had to resort to any other equipment other than a separate machine to log stuff that can be printed out from the serial port. My general reasoning is this: A serial port is a very simple thing to talk to. You can talk properly to a serial port in just 6 instructions, and therefore it is very easy to prove that code correct. Once you've done that, you can build other routines to print hex numbers etc around that, which can be run independent of the target system to ensure correctness. You then place the two together, and you have a way of getting binary information out of the target system, as well as strings. As a result, with some strategically placed "debugging points" to trigger messages, you can quickly get a good idea where something is not working correctly during bootup of the Linux kernel. One thing that I have commonly done when faced with a kernel which won't boot is to place a series of these throughout start_kernel(), and then progressed down through the code until I find the bit of code which is hanging the kernel. Of course, once the kernel has booted up and you have a functional printk, you can use the normal printk() instead of the above routines to display your debug messages. Obviously, there are other ways to debug a kernel, but something like kdb, remote gdb or a logic analyser, I don't think would be as good as the above method for a kernel which locks solid on boot. However, I would agree with anyone who says that the above isn't particularly a "good way" of debugging. I hope this gives a few useful pointers. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King [EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/ / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED] ++ Please use [EMAIL PROTECTED] for ++ ++ kernel-related discussions. ++
Re: Debugger / Emulator / Logic Analyzer for EBSA285 clone board
Russell King - ARM Linux Admin Tue, 04 Apr 2000 12:44:01 -0700
- Debugger / Emulator / Logic Analyzer for EB... Gaixia Zhang
- Re: Debugger / Emulator / Logic Analyz... Nicolas Pitre
- Re: Debugger / Emulator / Logic An... Russell King - ARM Linux Admin
- Re: Debugger / Emulator / Logi... David Rusling
- RE: Debugger / Emulator / Logic Analyz... George France
- RE: Debugger / Emulator / Logic Analyz... George France
- RE: Debugger / Emulator / Logic An... Erik Mouw
- Re: Debugger / Emulator / Logic An... Russell King - ARM Linux Admin
- Re: Debugger / Emulator / Logic Analyz... Jim Fischer
- Re: Debugger / Emulator / Logic An... Paul Koning
- RE: Debugger / Emulator / Logic Analyz... George France
