Move kgdb init code?
porter at cox.net
Wed Jun 26 08:39:00 EST 2002
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
> > .... 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().
porter at 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/
More information about the Linuxppc-dev