Move kgdb init code?

[Frank Rowand]

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
else?


>
> 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?

yes (objection).

>
> Thanks,
> --
> Matt "I use a BDI2000" Porter
> porter at cox.net
> This is Linux Country. On a quiet night, you can hear Windows reboot.


-Frank
--
Frank Rowand <frank_rowand at mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/