Move kgdb init code?
frowand at mvista.com
Wed Jun 26 02:19:08 EST 2002
Matt Porter wrote:
> Hi all,
> I've created a generic ns16550 binding to kgdb in hopes of making
> enabling kgdb support less of a per-board hack. It utilizes the
> information populated in rs_table to configure the UARTs (code
> stolen from a number of our other polled 16550 code areas). The
> only problem is that for systems that use early_serial_init() to
> configure serial port usage, the current location of the kgdb
> init code is not suitable. early_serial_init() is run during
> during a port's ppc_md.setup_arch if it is being used and so
> requires the the kgdb initialization be performed after
> ppc_md.setup_arch runs.
Is the concern that early_serial_init() will change the UART's
configuration, if kgdb initializes it earlier? Or something
> Since I don't personally use kgdb on a day-to-day basis, I'm
> wondering what most people use it for. I would guess that it
> is not typically used for board bringup since it is available
> so late in init code (and progress messages are available even
> earlier if one can't/won't use a hardware debugger). If most
When I was doing board bringups, I used kgdb for 95% of my debugging.
It has always been a struggle (in various OSs that I have worked
on) to get a software based kernel debugger initialized as early
as possible in the boot sequence. For 4xx and 8xx, kgdb is
available fairly early (very soon after going virtual).
> people are using it for device driver debug, then it doesn't
> seem that moving the init code after ppc_md.setup_arch would
> be a problem. It would enable kgdb in a more general purpose
> way with the generic 16550 support, and somebody doing new
> bringup could always move the init code earlier for their
> specific case.
> Any objections or alternatives?
> Matt "I use a BDI2000" Porter
> porter at cox.net
> This is Linux Country. On a quiet night, you can hear Windows reboot.
Frank Rowand <frank_rowand at mvista.com>
MontaVista Software, Inc
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev