Hi Matthias,
On Tue, 2009-08-18 at 11:04 +0200, Matthias Kaehlcke wrote:
> hi,
>
> El Wed, Aug 12, 2009 at 04:25:50AM +1000 Microbit_Ubuntu ha dit:
>
> > On Tue, 2009-08-11 at 13:03 -0400, Robert P. J. Day wrote:
> > > Kernel and module debugging with gdb: http://cli.gs/LHaA4a.
> >
> > The article is quite interesting, however it seems hard to scratch
> > together relevant (should read : not outdated thus wrong) on debugging
> > kernel modules on a *remote* target..
> >
> > I've been scouring away for yonks here and I don't seem to be getting
> > anywhere in a hurry :-(
> > I've recompiled my target's kernel with remote KGDB enabled, (sysfs et
> > al for possible manual configuration), full debug on the kernel - just
> > in case - but trying to pass kernel command argument using kgdbwait
> > (preceded with kgdboc=ttyS0,115200 eg. or kgdbcon etc) doesn't seem to
> > get the booting to halt and wait for the gdbmod debugger....
> > (I've also tried the sysrq-g break and consorts, no avail either).
> >
> > I've had a close look at the kernel/kgdb.c source - added some extra
> > temp debug messages to try to track code flow and it seems I'm not even
> > entering these funcs.
> >
> > Is there anyone here that can shed some more light on this black magic
> > cursed trick ? I'm using gdbmod-2.4 btw.
> >
> > So, basically : I'm continuing trying to find out if there is a way to
> > step through kernel module code invoked on a remote (ARM) target by
> > insmod/modprobe. (gdbmod 2.4 claims it automatically picks up when
> > module is inserted, but at this stage the kernel just happily boots up
> > and chugs away, ignoring the wait for remote debugger...?.)
> >
> > kgdb's URL has docs (kgdb_docu_full-2.4) but - as per usual - they're
> > either just plain wrong (eg. the syntax doesn't comply whatsoever with
> > the Documentation -> Docbook kgdb explained syntax) or others don't seem
> > to correlate with one another. It seems almost like a 'brute force' test
> > of all permutations of these various "solutions" is perhaps soon the
> > only way to remain sane.. :-)
> >
> > Googling other resources seems to just bring up unanswered posts on
> > forums here and there where people seem to be just as confused as I
> > am :-)
> >
> > In short, if anyone drops around here and has done this before (kernel =
> > 2.6.29.4, using built in remote kgdb), I would love to hear from them to
> > see if perhaps they've got a suggestion.
> > I don't mind doing the hard work to learn it properly - but it's always
> > more enjoyable when one is actually working towards something fruitful
> > in the end... !
>
> some time ago i had a similar (the same?) problem, trying to debug an
> ARM device using kgdb. in my case the problem was that the serial port
> driver (AMBA PL010) lacked the poll_get_char() and poll_put_char()
> operations, which seem to be necessary for debugging over console.
>
> if you happen to use a device with AMBA PL010 try again after applying
> the patch below. otherwise you might want to check if the driver of
> your serial port implements the poll functions
>
> diff --git a/drivers/serial/amba-pl010.c b/drivers/serial/amba-pl010.c
> index 58a4879..4b27537 100644
> --- a/drivers/serial/amba-pl010.c
> +++ b/drivers/serial/amba-pl010.c
> @@ -308,6 +308,32 @@ static void pl010_break_ctl(struct uart_port *port, int
> break_state)
> spin_unlock_irqrestore(&uap->port.lock, flags);
> }
>
> +#ifdef CONFIG_CONSOLE_POLL
> +static int pl010_get_poll_char(struct uart_port *port)
> +{
> + struct uart_amba_port *uap = (struct uart_amba_port *)port;
> + unsigned int status;
> +
> + do {
> + status = readb(uap->port.membase + UART01x_FR);
> + } while (!UART_RX_DATA(status))
> +
> + return readb(uap->port.membase + UART01x_DR);
> +}
> +
> +static void pl010_put_poll_char(struct uart_port *port,
> + unsigned char ch)
> +{
> + struct uart_amba_port *uap = (struct uart_amba_port *)port;
> +
> + while (!UART_TX_READY(readb(uap->port.membase + UART01x_FR)))
> + barrier();
> +
> + writeb(ch, uap->port.membase + UART01x_DR);
> +}
> +
> +#endif /* CONFIG_CONSOLE_POLL */
> +
> static int pl010_startup(struct uart_port *port)
> {
> struct uart_amba_port *uap = (struct uart_amba_port *)port;
> @@ -536,6 +562,10 @@ static struct uart_ops amba_pl010_pops = {
> .request_port = pl010_request_port,
> .config_port = pl010_config_port,
> .verify_port = pl010_verify_port,
> +#ifdef CONFIG_CONSOLE_POLL
> + .poll_get_char = pl010_get_poll_char,
> + .poll_put_char = pl010_put_poll_char,
> +#endif
> };
>
> static struct uart_amba_port *amba_ports[UART_NR];
>
After a bit of a study of the patch above (and also tty_io.c et al
files), I expanded my own file, which is atmel_serial.c as mentioned.
(PS : I noticed there is a amba-pl011.c file in 2.6.29 kernel..)
So I added this :
#ifdef CONFIG_CONSOLE_POLL
static int atmel_get_poll_char(struct uart_port *port)
{
unsigned int status;
do {
status = UART_GET_CSR(port);
} while (!(status & ATMEL_US_RXRDY));
return UART_GET_CHAR(port);
}
static void atmel_put_poll_char(struct uart_port *port,
unsigned char ch)
{
while (!(UART_GET_CSR(port) & ATMEL_US_TXRDY))
barrier();
UART_PUT_CHAR(port, ch);
}
#endif /* CONFIG_CONSOLE_POLL */
and the callbacks :
static struct uart_ops atmel_pops = {
.tx_empty = atmel_tx_empty,
.set_mctrl = atmel_set_mctrl,
.get_mctrl = atmel_get_mctrl,
.stop_tx = atmel_stop_tx,
.start_tx = atmel_start_tx,
.stop_rx = atmel_stop_rx,
.enable_ms = atmel_enable_ms,
.break_ctl = atmel_break_ctl,
.startup = atmel_startup,
.shutdown = atmel_shutdown,
.flush_buffer = atmel_flush_buffer,
.set_termios = atmel_set_termios,
.type = atmel_type,
.release_port = atmel_release_port,
.request_port = atmel_request_port,
.config_port = atmel_config_port,
.verify_port = atmel_verify_port,
.pm = atmel_serial_pm,
#ifdef CONFIG_CONSOLE_POLL
.poll_get_char = atmel_get_poll_char,
.poll_put_char = atmel_put_poll_char,
#endif
Well, at least I get the kgdb prompt now !!!! :
(and gdbmod gets the booting to continue)
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
kgdb: Registered I/O driver kgdboc.
kgdb: Waiting for connection from remote gdb...
Big SIGH.... :-)
Well, now it's off to figure a way to massage gdbmod-2.4 into the
Eclipse Galileo (debug) GUI....
If anyone's interested, let me know and I'll keep you posted.
Again, many thanks !! No wonder I kept trying till the proverbial cows
come home.... I did have the impression it was to do with polling
callbacks, but somehow didn't see the light.....
--
Best regards,
Kris
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
