On 1/20/06, satheesh paul <satheesh_kernel@xxxxxxxxxxx> wrote:
i think what Bernd meant is that you won't need the JTAG debugging if you already have the bootloader that will boot your compiled kernel .. once the kernel is up and running you can use the traditional ways
but if you don't have the bootloader for your board and you wanna write a new one then this is the case that Bernd said you will need JTAG ... Bernd CMIIW please
by the way there are many bootloaders to load and run the kernel on your arm board .. check this:
http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Bernd,
Thanks a lot. I have another question.
What is the case with bootloaders? (board bringup is the term used for
getting the bootloader working. right?) Can they be done without JTAG?
i think what Bernd meant is that you won't need the JTAG debugging if you already have the bootloader that will boot your compiled kernel .. once the kernel is up and running you can use the traditional ways
but if you don't have the bootloader for your board and you wanna write a new one then this is the case that Bernd said you will need JTAG ... Bernd CMIIW please
by the way there are many bootloaders to load and run the kernel on your arm board .. check this:
http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
With Regards,
Satheesh.
>From: Bernd Petrovitsch <bernd@xxxxxxxxx>
>To: satheesh paul <satheesh_kernel@xxxxxxxxxxx >
>CC: idoit.ief@xxxxxxxxx, fawadlateef@xxxxxxxxx, rabhagat@xxxxxxxxxx,
> kernelnewbies@xxxxxxxxxxxx
>Subject: Re: kernel development environment
>Date: Fri, 20 Jan 2006 12:26:24 +0100
>
>On Fri, 2006-01-20 at 16:21 +0530, satheesh paul wrote:
> > Bernd,
> > Even if I don't touch the bootloader, what kind of debugging tools will
>I
> > need to debug the kernel? Or a device driver? Just printk() :) ? For
>things
>
>printk() is state of the art. You could try to use kdb.
>
> > like single stepping or examining registers or memory?
>
>Single stepping has the problem that it inherently assumes that
>speed/time is not an issue and that you are on a (more or less)
>sequential way through the to-be-debugged program.
>
>Both of this hold in typical applications (e.g. a mail reader) but in a
>kernel you have
>- hardware interrupts which must be handled even if in single step mode
> (e.g. the timer).
> Forget single stepping in a timer routine (except you want to reboot
> afterwards).
>- You have the possibility that the actually debugged code path is used
> by several instances of the same "task" (think of an opened char
> device after a fork(2) [or dup2(2)] - your driver doesn't actually
> know (and must not care) how many file desriptors are created after
> one(!) open(2) call (which your driver will probably handle).
>and there are probably other similar issues.
>
> > And explain me a little more about JTAG. I tried google, but info on
>JTAG is
> > so disoriented on the web that I could'nt come to a conclusion. What
>exactly
> > does JTAG consist of? Is it a hardware probe which, on the host is
>connected
>
>JTAG as such is a standardized plug + the interface on the board to
>disrupt the CPU for debugging. You can also upload firmware and peek
>into RAM.
>
> > to parallel port and to the JTAG interface on the board? What software
>do I
>
>Yes. And it must be supported by the board and CPU AFAIK (so you have it
>on prototype/development boards but not necessarily on the production
>board).
>
> > need to debug with it? Does gdb work with it? IS IT CHEAP??
>
>You need for the access a BDI or similar product which also knows you
>OS, MM, etc. on that board, so - at last for BDIs - you have different
>software on the BDI for different CPUs and OSs (and possibly boards
>too).
>
> > Again how do you do your kernel debugging without JTAG or BDI?
>
>printk(), boilerplate checks (i.e . BUG_ON()), studying source code (mine
>and others).
>Another problem in kernel development is a/the usual aplication ways of
>coding:
>- "test it until it runs": You have lots of code paths (esp. for error
> cases) which are not trivial to trigger for testing (how behaves
> this file system if double faults are failing under low mem
> conditions).
> And how can you estimate (let alone measure) the code coverage of
> such tests.
>- "write the code, single step it until it works, done".
> How do you do this seriously with asynchronous events (even in
> user-space apps)?
> And the Kernel is a actually single huge async application - IRQs
> from the hardware, sys-calls from user-space, timer, ...
>
>So you absolutely need a quite good idea of your design and conditions
>which is enforced with BUG_ON() to immediately identify b0rken behaviour
>(and not stumble over errors in completely unrelated drivers just
>because a - probably your - driver writes at the wrong address because
>you fucked up some index calculation).
>
> Bernd
>
>
_________________________________________________________________
Spice up your IM conversations. New, colorful and animated emoticons. Get
chatting! http://server1.msn.co.in/SP05/emoticons/
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
