All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Rowand <frowand@mvista.com>
To: Matt Porter <mmporter@cox.net>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: Move kgdb init code?
Date: Tue, 25 Jun 2002 09:19:08 -0700	[thread overview]
Message-ID: <3D1897FC.D7D7C5B2@mvista.com> (raw)
In-Reply-To: 20020624221020.A14330@home.com


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@cox.net
> This is Linux Country. On a quiet night, you can hear Windows reboot.


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

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

  reply	other threads:[~2002-06-25 16:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-25  5:10 Move kgdb init code? Matt Porter
2002-06-25 16:19 ` Frank Rowand [this message]
2002-06-25 20:50   ` Matt Porter
2002-06-25 21:02     ` Frank Rowand
2002-06-25 22:05     ` Dan Malek
2002-06-25 22:39       ` Matt Porter
2002-06-26  2:50         ` Dan Malek
2002-06-26  8:25           ` Matt Porter
2002-06-26 14:47             ` Dan Malek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D1897FC.D7D7C5B2@mvista.com \
    --to=frowand@mvista.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=mmporter@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.