Re: How the kernel printk works before do console_setup.

2009-06-29 Thread Freeman
Johnny Hung johnny.hacking at gmail.com writes:

 
 Hi All:
 I have a powerpc arch platform. The default console is ttyS1 not
 ttyS0 in the platform. My question is how the kernel print debug
 message
 like DBG before parse kernel command line and do console_setup
 function. The command line passed to kernel about console info is
 console=ttyS1.
 So kernel can not print anything before parse cmd line and initial
 console but the result is against. Anyone point me or give me a clue
 is appreciate.
 
 BR, H. Johnny
 

Don't worry, printk uses a ring buffer so it allows the kernel to print some, 
hopefully enough, out before console is registered/initialized. This is from 
printk.c

197 /*
198  * The console driver calls this routine during kernel initialization
199  * to register the console printing procedure with printk() and to
200  * print any messages that were printed by the kernel before the
201  * console driver was initialized.
202  */
203 void register_console(void (*proc)(const char *))

Freeman

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: How the kernel printk works before do console_setup.

2009-06-25 Thread Johnny Hung
2009/6/25 Benjamin Herrenschmidt b...@kernel.crashing.org:

 Before the console is set up, the printk data is formatted
 and put into the kernel log buffer, but not sent to any console.
 Any messages printk'ed before that are buffered but do not
 appear.  When the console is initialized, then all buffered
 messages are sent to the console, and subsequent printks cause
 the message to go to the log buffer, but then immediately
 get sent from there to the console.

 Under certain conditions you can examine the log buffer of
 a kernel that failed to initialize it's console, after a
 warm reset of the machine, using the firmware memory dump
 command.

 On ppc, we have tricks to display things earlier :-)

 We can initialize the serial ports way before console_setup() (and we do
 in most cases) and we use what we call the udbg console until the real
 one takes over. The udbg console is a very small layer which outputs
 via a provided putc routine. Platforms can provide their own here, we
 have a collection of standard ones for legacy UARTs (it should be
 automatically setup in that case by the code in legacy_serial), Apple
 ESCCs, etc... We even have compile time options that allow that stuff to
 be initialized before start_kernel...

Thank you. This is what I described and want to understand. The
arch/powerpc/kernel/legacy_serial.c
do find_legacy_serial_ports then take a default serial port by using
open firmware device tree
information. The find_legacy_serial_ports() called form setup_arch but
I don't know who call
setup_arch (setup_32.c)function. Can you give me a hint ? Thanks in advanced.

BRs, H. Johnny
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: How the kernel printk works before do console_setup.

2009-06-25 Thread Michael Ellerman
On Thu, 2009-06-25 at 14:27 +0800, Johnny Hung wrote:
 2009/6/25 Benjamin Herrenschmidt b...@kernel.crashing.org:
 
  Before the console is set up, the printk data is formatted
  and put into the kernel log buffer, but not sent to any console.
  Any messages printk'ed before that are buffered but do not
  appear.  When the console is initialized, then all buffered
  messages are sent to the console, and subsequent printks cause
  the message to go to the log buffer, but then immediately
  get sent from there to the console.
 
  Under certain conditions you can examine the log buffer of
  a kernel that failed to initialize it's console, after a
  warm reset of the machine, using the firmware memory dump
  command.
 
  On ppc, we have tricks to display things earlier :-)
 
  We can initialize the serial ports way before console_setup() (and we do
  in most cases) and we use what we call the udbg console until the real
  one takes over. The udbg console is a very small layer which outputs
  via a provided putc routine. Platforms can provide their own here, we
  have a collection of standard ones for legacy UARTs (it should be
  automatically setup in that case by the code in legacy_serial), Apple
  ESCCs, etc... We even have compile time options that allow that stuff to
  be initialized before start_kernel...
 
 Thank you. This is what I described and want to understand. The
 arch/powerpc/kernel/legacy_serial.c
 do find_legacy_serial_ports then take a default serial port by using
 open firmware device tree
 information. The find_legacy_serial_ports() called form setup_arch but
 I don't know who call
 setup_arch (setup_32.c)function. Can you give me a hint ? Thanks in advanced.

setup_arch() is called from start_kernel() in init/main.c

cheers


signature.asc
Description: This is a digitally signed message part


Re: How the kernel printk works before do console_setup.

2009-06-24 Thread Benjamin Herrenschmidt

 Before the console is set up, the printk data is formatted
 and put into the kernel log buffer, but not sent to any console.
 Any messages printk'ed before that are buffered but do not
 appear.  When the console is initialized, then all buffered
 messages are sent to the console, and subsequent printks cause
 the message to go to the log buffer, but then immediately
 get sent from there to the console.
 
 Under certain conditions you can examine the log buffer of
 a kernel that failed to initialize it's console, after a
 warm reset of the machine, using the firmware memory dump
 command.

On ppc, we have tricks to display things earlier :-)

We can initialize the serial ports way before console_setup() (and we do
in most cases) and we use what we call the udbg console until the real
one takes over. The udbg console is a very small layer which outputs
via a provided putc routine. Platforms can provide their own here, we
have a collection of standard ones for legacy UARTs (it should be
automatically setup in that case by the code in legacy_serial), Apple
ESCCs, etc... We even have compile time options that allow that stuff to
be initialized before start_kernel...

Cheers,
Ben.


 See 
 http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot
 for some tips on accessing the log buffer of a previous boot.
 
 Note also, that if the serial console does not come up,
 but the kernel successfully boots, and you can get a network
 login on the machine, you can always print out the kernel log
 buffer messages using 'dmesg' at a user-space shell prompt.
 
 Hope this helps!
  -- Tim
 
 =
 Tim Bird
 Architecture Group Chair, CE Linux Forum
 Senior Staff Engineer, Sony Corporation of America
 =
 
 ___
 Linuxppc-dev mailing list
 linuxppc-...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: How the kernel printk works before do console_setup.

2009-06-23 Thread Tim Bird
Johnny Hung wrote:
 Hi All:
 I have a powerpc arch platform. The default console is ttyS1 not
 ttyS0 in the platform. My question is how the kernel print debug
 message
 like DBG before parse kernel command line and do console_setup
 function. The command line passed to kernel about console info is
 console=ttyS1.
 So kernel can not print anything before parse cmd line and initial
 console but the result is against. Anyone point me or give me a clue
 is appreciate.

Before the console is set up, the printk data is formatted
and put into the kernel log buffer, but not sent to any console.
Any messages printk'ed before that are buffered but do not
appear.  When the console is initialized, then all buffered
messages are sent to the console, and subsequent printks cause
the message to go to the log buffer, but then immediately
get sent from there to the console.

Under certain conditions you can examine the log buffer of
a kernel that failed to initialize it's console, after a
warm reset of the machine, using the firmware memory dump
command.

See 
http://elinux.org/Kernel_Debugging_Tips#Accessing_the_printk_buffer_after_a_silent_hang_on_boot
for some tips on accessing the log buffer of a previous boot.

Note also, that if the serial console does not come up,
but the kernel successfully boots, and you can get a network
login on the machine, you can always print out the kernel log
buffer messages using 'dmesg' at a user-space shell prompt.

Hope this helps!
 -- Tim

=
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html