Move kgdb init code?

Move kgdb init code?

[Matt Porter]

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.

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

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

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

Re: 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@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/

Re: Move kgdb init code?

[Matt Porter]

On Tue, Jun 25, 2002 at 09:19:08AM -0700, Frank Rowand wrote:
> 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?

Actually, some ports have no virtual mapping prior to
early_serial_init() so the current location of kgdb is
unsuitable (as a general purpose case).

> > 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).

That doesn't seem to be the general purpose case, though.  When
you have kgdb functionality in the kernel for functional board
ports, later debug seems to be the general use of it.

When doing a board bringup, one is always going to want to move
the init from even its current location.   Not a big deal, since
the developer is already adding progress messages, printks, etc
as he walks the thing into a running state.

It would seem that moving the default location has more general
usefulness for existing board ports.  IMHO, it is most important
to have features like kgdb functioning in a general purpose way
in the tree.

> > 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).

Is being expected to move kgdb_map_scc() to an earlier custom
location too much?  It only needs to be earlier until things
are functional past setup_arch.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: Move kgdb init code?

[Frank Rowand]

Matt Porter wrote:
>
> On Tue, Jun 25, 2002 at 09:19:08AM -0700, Frank Rowand wrote:
> > 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?
>
> Actually, some ports have no virtual mapping prior to
> early_serial_init() so the current location of kgdb is
> unsuitable (as a general purpose case).
>
> > > 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).
>
> That doesn't seem to be the general purpose case, though.  When
> you have kgdb functionality in the kernel for functional board
> ports, later debug seems to be the general use of it.
>
> When doing a board bringup, one is always going to want to move
> the init from even its current location.   Not a big deal, since
> the developer is already adding progress messages, printks, etc
> as he walks the thing into a running state.
>
> It would seem that moving the default location has more general
> usefulness for existing board ports.  IMHO, it is most important
> to have features like kgdb functioning in a general purpose way
> in the tree.
>
> > > 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).
>
> Is being expected to move kgdb_map_scc() to an earlier custom
> location too much?  It only needs to be earlier until things
> are functional past setup_arch.

It sounds like you are trying to move kgdb_map_scc() to a board
and processor independent place (just PPC dependent), which is
certainly easier than having a processor dependent implementation
that may need a lot of maintainance.

In older kernels, the call to ppc_md.setup_arch() isn't much
later than where kgdb was initialized...  Hopefully that is
still the case.  If so, your proposed change won't affect
the ability to debug early bringup much at all.  Sorry I didn't
dig deeper into exactly where you proposed moving to before
answering.

I'm just used to the common effort (in multiple OSs, in multiple
companies) to move kernel debugger initialization later and later
in the boot sequence, so I figured I would pipe up with a not too
loud voice.

I'm not trying to voice a strong opinion, just trying to give
some insight as someone who has used kgdb extensively.

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

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

Re: Move kgdb init code?

[Dan Malek]

Matt Porter wrote:

> Actually, some ports have no virtual mapping prior to
> early_serial_init()

Ummmm....something doesn't seem right then.  The kernel has
to be mapped in order for it to be running at this time,  and
the I/O can actually move around.

I did lots of this work to get kgdb, and more importantly xmon,
to initialize this early.  On the 8xx, the serial port is actually
moved at least three times as the VM and the driver initializations
are done.

Early in kgdb/xmon, they rely on the same mapping that is used by
the boot loader that brought the kernel to being.  If I can make this
work on 8xx, it should work on anything :-)  The 8xx can only do DMA
I/O, so it's particularly challenging to chase memory around that
can be used for these buffers.


> That doesn't seem to be the general purpose case, though.  When
> you have kgdb functionality in the kernel for functional board
> ports, later debug seems to be the general use of it.

You always want to start up kgdb as soon as possible.  It gives you
the opportunity to debug driver initialization.

> It would seem that moving the default location has more general
> usefulness for existing board ports.

Huh?  All of the existing board ports use it as it is today.  How
can you say removing a useful feature would be useful to existing
systems? :-)

> ....  IMHO, it is most important
> to have features like kgdb functioning in a general purpose way
> in the tree.

I don't know what that statement means.  All of the other architectures
use an early kgdb initialization, which is where we got the idea to
do the same a while back.  The kgdb/xmon used to initialize later, and
didn't make it very useful until a substantial amount of system initialization
was done.

> Is being expected to move kgdb_map_scc() to an earlier custom
> location too much?

Why don't you just use the normal serial port setup to enter kgdb
on those ports that have trouble, and do nothing in this early function?

>  ...  It only needs to be earlier until things
> are functional past setup_arch.

What board ports have trouble with the early initialization?  Any mostly
standard programmed I/O uart should work.  It's only the high performance
DMA only ports like 8xx and 8260 that seem to be the challenge.


Thanks.


	-- Dan


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

Re: Move kgdb init code?

[Matt Porter]

On Tue, Jun 25, 2002 at 06:05:39PM -0400, Dan Malek wrote:
> Matt Porter wrote:
>
> > Actually, some ports have no virtual mapping prior to
> > early_serial_init()
>
> Ummmm....something doesn't seem right then.  The kernel has
> to be mapped in order for it to be running at this time,  and
> the I/O can actually move around.

That should be "no serial port mapping prior to early_serial_init().

> I did lots of this work to get kgdb, and more importantly xmon,
> to initialize this early.  On the 8xx, the serial port is actually
> moved at least three times as the VM and the driver initializations
> are done.
>
> Early in kgdb/xmon, they rely on the same mapping that is used by
> the boot loader that brought the kernel to being.  If I can make this
> work on 8xx, it should work on anything :-)  The 8xx can only do DMA
> I/O, so it's particularly challenging to chase memory around that
> can be used for these buffers.
>
>
> > That doesn't seem to be the general purpose case, though.  When
> > you have kgdb functionality in the kernel for functional board
> > ports, later debug seems to be the general use of it.
>
> You always want to start up kgdb as soon as possible.  It gives you
> the opportunity to debug driver initialization.

The only thing I was talking about was moving it toward the end
of setup_arch.  All _driver_ init is after that.

> > It would seem that moving the default location has more general
> > usefulness for existing board ports.
>
> Huh?  All of the existing board ports use it as it is today.  How
> can you say removing a useful feature would be useful to existing
> systems? :-)

I think we are talking two different things.  Kgdb does not work on
the vast number of 7xx/74xx designs with 16550's all at arbitrary
locations.  The ppc4xx_kgdb.c binding is non-functional is _devel
(relying on the old COM_PORT structure that is gone).

You've got me confused Dan, where did I suggest removing a useful
feature?

> > ....  IMHO, it is most important
> > to have features like kgdb functioning in a general purpose way
> > in the tree.
>
> I don't know what that statement means.  All of the other architectures
> use an early kgdb initialization, which is where we got the idea to
> do the same a while back.  The kgdb/xmon used to initialize later, and
> didn't make it very useful until a substantial amount of system initialization
> was done.
>
> > Is being expected to move kgdb_map_scc() to an earlier custom
> > location too much?
>
> Why don't you just use the normal serial port setup to enter kgdb
> on those ports that have trouble, and do nothing in this early function?

I don't understand what you are suggesting.  I don't poke a static
serial port mapping in (to be used in STD_SERIAL_DEFS) because
early_serial_init()/ioremap() can do it dynamically for me.

> >  ...  It only needs to be earlier until things
> > are functional past setup_arch.
>
> What board ports have trouble with the early initialization?  Any mostly
> standard programmed I/O uart should work.  It's only the high performance
> DMA only ports like 8xx and 8260 that seem to be the challenge.

Hrm, so are you suggesting a do an early mapping (I use one for
early boot text support) init kgdb, and not use early_serial_setup()?
I think kgdb should be able to work with early_serial_setup().

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: Move kgdb init code?

[Dan Malek]

Matt Porter wrote:

> The only thing I was talking about was moving it toward the end
> of setup_arch.  All _driver_ init is after that.

Hmmm.....why doesn't kgdb_map_scc call early_serial_init() instead
of waiting for the 4xx platform setup to do that?  The purpose of
kgdb_map_scc() is to do everything necessary to make the serial
port accessible.  Is there something else done in platform specific
setup that is needed?


> I think we are talking two different things.  Kgdb does not work on
> the vast number of 7xx/74xx designs with 16550's all at arbitrary
> locations.  The ppc4xx_kgdb.c binding is non-functional is _devel
> (relying on the old COM_PORT structure that is gone).
>
> You've got me confused Dan, where did I suggest removing a useful
> feature?

Well, it used to be a useful feature :-)  If people keep breaking
kgdb by making changes it relies upon for proper operation, that
should get fixed :-)


> I don't understand what you are suggesting.  I don't poke a static
> serial port mapping in (to be used in STD_SERIAL_DEFS) because
> early_serial_init()/ioremap() can do it dynamically for me.

Well, that was one of the important changes (mapping the port
or using an existing mapping) to allow an early kgdb.  I guess if
you don't want to map it, that's a reason why it won't work.


> Hrm, so are you suggesting a do an early mapping (I use one for
> early boot text support) init kgdb, and not use early_serial_setup()?
> I think kgdb should be able to work with early_serial_setup().

:-)

The kgdb doesn't care how the port was set up, just that is has a
way to use it.  You could call early_serial_setup() several times,
depending upon how the mapping may change.  This is basically how
the 8xx and 8260 work.  I use an early trivial mapping that was set
up by the bootloader, then an intermediate mapping, then finally
something after rs_init() is called.

I guess if moving it to later in setup_arch() is enough.......


	-- Dan


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

Re: Move kgdb init code?

[Matt Porter]

On Tue, Jun 25, 2002 at 10:50:07PM -0400, Dan Malek wrote:
> Matt Porter wrote:
>
> > The only thing I was talking about was moving it toward the end
> > of setup_arch.  All _driver_ init is after that.
>
> Hmmm.....why doesn't kgdb_map_scc call early_serial_init() instead
> of waiting for the 4xx platform setup to do that?  The purpose of
> kgdb_map_scc() is to do everything necessary to make the serial
> port accessible.  Is there something else done in platform specific
> setup that is needed?

The kgdb_map_scc in my gen550_kgdb.c is currently relying on rs_table
to be filled out.  The reason for this approach is that I'm trying
to enable all those 7xx/74xx ports at the same time.  Those ports
all have 16550's at arbitrary locations.  Some use io_block_mapping
and fixed virtual mapping for the UARTs at compile time and a few
have been updated to do without io_block_mapping and use
early_serial_init to load rs_table at run-time.  At any rate, every
one of them is potentially different and so should be calling
early_serial_init from the <board>.c or <board>_setup.c to pass in
the board-specific UART values.

In short, gen550_kgdb.c:kgdb_map_scc has no board-specific knowledge.
It relies on the board-specific setup to map things so that all these
7xx/74xx boards can be more or less generically enabled.  It _could_
call early_serial_init but then would be a mess of per-board #ifdefs
in order to ioremap the proper UART phys addrs.  That defeats our
whole goal of abstracting generic stuff out of the <board>.c files
and having all board-specific support in one place.

> > I think we are talking two different things.  Kgdb does not work on
> > the vast number of 7xx/74xx designs with 16550's all at arbitrary
> > locations.  The ppc4xx_kgdb.c binding is non-functional is _devel
> > (relying on the old COM_PORT structure that is gone).
> >
> > You've got me confused Dan, where did I suggest removing a useful
> > feature?
>
> Well, it used to be a useful feature :-)  If people keep breaking
> kgdb by making changes it relies upon for proper operation, that
> should get fixed :-)

Damn people. :)

> > I don't understand what you are suggesting.  I don't poke a static
> > serial port mapping in (to be used in STD_SERIAL_DEFS) because
> > early_serial_init()/ioremap() can do it dynamically for me.
>
> Well, that was one of the important changes (mapping the port
> or using an existing mapping) to allow an early kgdb.  I guess if
> you don't want to map it, that's a reason why it won't work.
>
>
> > Hrm, so are you suggesting a do an early mapping (I use one for
> > early boot text support) init kgdb, and not use early_serial_setup()?
> > I think kgdb should be able to work with early_serial_setup().
>
> :-)
>
> The kgdb doesn't care how the port was set up, just that is has a
> way to use it.  You could call early_serial_setup() several times,
> depending upon how the mapping may change.  This is basically how
> the 8xx and 8260 work.  I use an early trivial mapping that was set
> up by the bootloader, then an intermediate mapping, then finally
> something after rs_init() is called.

I'm starting to see that the difference in approaches is due to
the difference in architecture forced by the 60x bus classic PPCs
which can/do have 16550's interfaced at a variety of addresses and
even reg shift offsets.  In your examples, 8xx and 8260 are both
SoCs with onboard specialized UARTs at known locations in which
you have your own uart driver.  Since the UART's configuration is
the same in all board implementations, your task is simplified
for kgdb mapping.

> I guess if moving it to later in setup_arch() is enough.......

Moving it later is a simple way to make it work by default on
existing embedded 7xx/74xx board ports (with the gen550_kgdb.c support).

So, my concern at the beginning is whether moving it from before
ppc_md.setup_arch to after that call would have adverse effects
on those using kgdb.  If it does, then we'll just have to get
the early mapping on all those board ports straightened out to
cooperate with the current calling location of kgdb_map_scc.

Thanks,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: Move kgdb init code?

[Dan Malek]

Matt Porter wrote:

> .... At any rate, every
> one of them is potentially different and so should be calling
> early_serial_init from the <board>.c or <board>_setup.c to pass in
> the board-specific UART values.

I see.  I was wondering if we should move the kgdb start up
back into the board specific setup again......That way we can
choose to start up kgdb at any point in there according to board
initialization.  Of course, I still like to use xmon, and it uses
the same serial port functions as kdgb, so if we move the kgdb
initialization we should also move xmon.


> Damn people. :)

My experience has been it usually gets fixed as the last required
feature before a product ships to a customer :-)


> So, my concern at the beginning is whether moving it from before
> ppc_md.setup_arch to after that call would have adverse effects
> on those using kgdb.

Let's move it back into the board specific setup.  IMHO, it doesn't
really affect what we can debug with kgdb/xmon.  I just didn't want it
to go all of the way back to the way it was........

I'm surprised more people don't use xmon.  That is the first debugger
I usually use, since you can make it easily understand some complex
kernel data structures and associations.

Thanks.


	-- Dan


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