Some udbg questions

Some udbg questions

[Timur Tabi]

I'm adding udbg support to my console driver, and I've noticed that
there is not much consistency on how the various platforms implement
udbg support.  So I have a few questions:

1. What is the point of implementing udbg_getc?  What does the console
do with any characters it receives this early?
2. In my driver's udbg initialization function, should I be able to
parse the device tree to get parameters?
3. What about command-line parameters?
4. The LPAR and PMAC platforms call register_early_udbg_console (in
the udbg_init_debug_lpar and pmac_init_early functions, respectively),
but none of the other platforms do.  It appears that the other
platforms rely on setup_32.c and setup_64.c to call this function.
What's so special about LPAR and PMAC?
5. Some platforms (like mv64x60) use the ppc_md.init_early function to
initialize the early console.  Others update function
udbg_early_init() in udbg.c instead.  Why do some platforms do it one
way, and other platforms do it the other way?  Which way is preferred?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Some udbg questions

[Benjamin Herrenschmidt]

On Mon, 2008-11-17 at 18:56 -0600, Timur Tabi wrote:
> I'm adding udbg support to my console driver, and I've noticed that
> there is not much consistency on how the various platforms implement
> udbg support.  So I have a few questions:
> 
> 1. What is the point of implementing udbg_getc?  What does the console
> do with any characters it receives this early?

It's for xmon (and possibly kgdb if we ever hook that up again).

> 2. In my driver's udbg initialization function, should I be able to
> parse the device tree to get parameters?

You can. It depends how late. In many cases, we have 2 stage of udbg,
one very very early that depends on CONFIG_EARLY_DBG_*, and is hard
wired for a given board and config (ie, when enabled, the kernel will
probably not even boot on anything else) and is useful for debugging
very early boot code.

Some stuff also initializes udbg slightly later using the device-tree
etc... to provide a level of console output before the tty drivers are
loaded. This can be left enabled and doesn't conflict with anything.

> 3. What about command-line parameters?

No point. As I said, either hard wire for early debugging or use the
device-tree.

> 4. The LPAR and PMAC platforms call register_early_udbg_console (in
> the udbg_init_debug_lpar and pmac_init_early functions, respectively),
> but none of the other platforms do.  It appears that the other
> platforms rely on setup_32.c and setup_64.c to call this function.
> What's so special about LPAR and PMAC?

That's probably some mess left over from history, we should probably
clean that up. We could probably even make it a console_initcall (that's
currently commented out).

Another reason is it's useful if you install your udbg_putc callback
after register_early_udbg_console was already called, since it won't do
anything, so it needs to be called again.

> 5. Some platforms (like mv64x60) use the ppc_md.init_early function to
> initialize the early console.  Others update function
> udbg_early_init() in udbg.c instead.  Why do some platforms do it one
> way, and other platforms do it the other way?  Which way is preferred?

We should probably clean that up a bit.

udbg_early_init() is called before the device-tree is expanded and
shouldn't realy on anything. it's purely means for debug stuff to be
hard wired for your platform and removed in production.

Some platforms enable udbg in a more "normal" way as a way to have a
console before the main fbdev or tty kicks in.

Cheers,
Ben.

Re: Some udbg questions

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]

On Tue, 2008-11-18 at 16:37 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2008-11-17 at 18:56 -0600, Timur Tabi wrote:
> > I'm adding udbg support to my console driver, and I've noticed that
> > there is not much consistency on how the various platforms implement
> > udbg support.  So I have a few questions:
> > 
> > 1. What is the point of implementing udbg_getc?  What does the console
> > do with any characters it receives this early?
> 
> It's for xmon (and possibly kgdb if we ever hook that up again).
> 
> > 2. In my driver's udbg initialization function, should I be able to
> > parse the device tree to get parameters?
> 
> You can. It depends how late. In many cases, we have 2 stage of udbg,
> one very very early that depends on CONFIG_EARLY_DBG_*, and is hard
> wired for a given board and config (ie, when enabled, the kernel will
> probably not even boot on anything else) and is useful for debugging
> very early boot code.
> 
> Some stuff also initializes udbg slightly later using the device-tree
> etc... to provide a level of console output before the tty drivers are
> loaded. This can be left enabled and doesn't conflict with anything.
> 
> > 3. What about command-line parameters?
> 
> No point. As I said, either hard wire for early debugging or use the
> device-tree.
> 
> > 4. The LPAR and PMAC platforms call register_early_udbg_console (in
> > the udbg_init_debug_lpar and pmac_init_early functions, respectively),
> > but none of the other platforms do.  It appears that the other
> > platforms rely on setup_32.c and setup_64.c to call this function.
> > What's so special about LPAR and PMAC?
> 
> That's probably some mess left over from history, we should probably
> clean that up. We could probably even make it a console_initcall (that's
> currently commented out).

The pseries code does it because it knows that at that early stage it's
safe to call the udbg routines and have them hooked up to printk, and
they'll actually produce output on the console.

If you register the console before the udbg routines actually work, then
you'll loose any printks that happen before you udbg routine starts
working. On the other hand if you hook up udbg_putc() but don't register
the console, then when you do register the udbg console you'll get all
the printks spat out at you. Which is good.

So it's up to each platform, or udbg implementation, to decide if it
should register the console at the same time it registers the udbg
hooks, or if it's better to do it later.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]