Re: How the kernel printk works before do console_setup.
Johnny Hung 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.
On Thu, 2009-06-25 at 14:27 +0800, Johnny Hung wrote: > 2009/6/25 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... > > 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/6/25 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... 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.
> 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.
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
