Hi,
The console subsystem already has an idea of a boot console, using the
CON_BOOT flag. The implementation has some flaws though. The major
problem is that presence of a boot console makes register_console()
ignore any other console devices (unless explicitly specified on the
kernel command line).
This patch fixes the console selection code to *not* consider a boot
console a full-featured one, so the first "normal" console registering
will become the default boot console instead. This way the unregister
call for the boot console in register_console() actually triggers and
the handover from the boot console to the real console device works
smoothly.
The patch also changes the x86 early_printk code to use this. The early
console is simply tagged as boot console, the disable_early_printk()
call is gone as it isn't needed any more.
cheers,
Gerd
--
Gerd Hoffmann <[email protected]>
On 2/16/07, Gerd Hoffmann <[email protected]> wrote:
> The console subsystem already has an idea of a boot console, using the
> CON_BOOT flag. The implementation has some flaws though. The major
> problem is that presence of a boot console makes register_console()
> ignore any other console devices (unless explicitly specified on the
> kernel command line).
>
> This patch fixes the console selection code to *not* consider a boot
> console a full-featured one, so the first "normal" console registering
> will become the default boot console instead. This way the unregister
> call for the boot console in register_console() actually triggers and
> the handover from the boot console to the real console device works
> smoothly.
>
> The patch also changes the x86 early_printk code to use this. The early
> console is simply tagged as boot console, the disable_early_printk()
> call is gone as it isn't needed any more.
just notice console handover patch got into mainline 5/8.
for early_uart_console, I have some ideas:
1. merged that into early_serial_console in
arch/x86_64/kernel/early_printk.c, and
move early_printk.c to kernel/, --- make it understand
earlyprintk=uart,io,0x3f8,9600n8
earlyprintk=uart,mmio,0xff5e0000,115200n8
in addition to vga, ttyS, serial
2. or make early_uart_console to be another CON_BOOT, and get rid of
late_initcall(early_uart_console_switch).
actually with late_initcall early_uart_console_switch instead of
console handover, we will lose char output from serial drv init to
late_initcall stage.
in this case, we need to EARLY_SERIAL_CONSOLE to select
early_serial_console or early_uart_console for x86_64 platform.
YH
On Tuesday 15 May 2007 10:17:50 pm Yinghai Lu wrote:
> for early_uart_console, I have some ideas:
> 1. merged that into early_serial_console in
> arch/x86_64/kernel/early_printk.c, and
> move early_printk.c to kernel/, --- make it understand
> earlyprintk=uart,io,0x3f8,9600n8
> earlyprintk=uart,mmio,0xff5e0000,115200n8
> in addition to vga, ttyS, serial
I would rather try to merge 8250_early and early_printk.
"console=uart,io,0x3f8" is already pretty similar to
"earlyprintk=serial", and it would be nice to have only one.
"console=uart" does have the disadvantage that you have to know the
port address. But it has the advantage that it doesn't depend on
compiled-in legacy serial port names. If you need early console
output, you're probably a developer and can come up with the address.
I think it would be nice to have a "console=vga". That could use
the current "earlyprintk=vga" implementation, and automatically
hand off to tty0.
Then we could remove "earlyprintk=" and always use "console=uart"
or "console=vga".
Bjorn
On 5/16/07, Bjorn Helgaas <[email protected]> wrote:
> On Tuesday 15 May 2007 10:17:50 pm Yinghai Lu wrote:
> > for early_uart_console, I have some ideas:
> > 1. merged that into early_serial_console in
> > arch/x86_64/kernel/early_printk.c, and
> > move early_printk.c to kernel/, --- make it understand
> > earlyprintk=uart,io,0x3f8,9600n8
> > earlyprintk=uart,mmio,0xff5e0000,115200n8
> > in addition to vga, ttyS, serial
>
> I would rather try to merge 8250_early and early_printk.
> "console=uart,io,0x3f8" is already pretty similar to
> "earlyprintk=serial", and it would be nice to have only one.
>
> "console=uart" does have the disadvantage that you have to know the
> port address. But it has the advantage that it doesn't depend on
> compiled-in legacy serial port names. If you need early console
> output, you're probably a developer and can come up with the address.
>
> I think it would be nice to have a "console=vga". That could use
> the current "earlyprintk=vga" implementation, and automatically
> hand off to tty0.
>
> Then we could remove "earlyprintk=" and always use "console=uart"
> or "console=vga".
earlyprintk= is needed for seeting bootconsole, or setting CON_BOOT,
and it is could be loaded earlier with early_param than console_init.
in the console_init (via register_console), the console is handed over
from bootconsole to normal console.
also console_init could be moved to quite late than current, and till
some subsystem is initialized like pci and usb.
YH
On Wednesday 16 May 2007 10:29:11 am Yinghai Lu wrote:
> On 5/16/07, Bjorn Helgaas <[email protected]> wrote:
> > On Tuesday 15 May 2007 10:17:50 pm Yinghai Lu wrote:
> > > for early_uart_console, I have some ideas:
> > > 1. merged that into early_serial_console in
> > > arch/x86_64/kernel/early_printk.c, and
> > > move early_printk.c to kernel/, --- make it understand
> > > earlyprintk=uart,io,0x3f8,9600n8
> > > earlyprintk=uart,mmio,0xff5e0000,115200n8
> > > in addition to vga, ttyS, serial
> >
> > I would rather try to merge 8250_early and early_printk.
> > "console=uart,io,0x3f8" is already pretty similar to
> > "earlyprintk=serial", and it would be nice to have only one.
> >
> > "console=uart" does have the disadvantage that you have to know the
> > port address. But it has the advantage that it doesn't depend on
> > compiled-in legacy serial port names. If you need early console
> > output, you're probably a developer and can come up with the address.
> >
> > I think it would be nice to have a "console=vga". That could use
> > the current "earlyprintk=vga" implementation, and automatically
> > hand off to tty0.
> >
> > Then we could remove "earlyprintk=" and always use "console=uart"
> > or "console=vga".
>
> earlyprintk= is needed for seeting bootconsole, or setting CON_BOOT,
> and it is could be loaded earlier with early_param than console_init.
8250_early.c does basically the same thing as the serial part of
early_printk.c, so we should be able to make it work just as early.
I don't remember why I didn't use early_param() for 8250_early;
I probably should have. On ia64, it doesn't matter because we call
early_serial_console_init() explicitly at about the time of
parse_early_param().
8250_early and early_printk are so similar, I just don't see the
need for both.
Bjorn
On Wed, 16 May 2007, Bjorn Helgaas wrote:
> > for early_uart_console, I have some ideas:
> > 1. merged that into early_serial_console in
> > arch/x86_64/kernel/early_printk.c, and
> > move early_printk.c to kernel/, --- make it understand
> > earlyprintk=uart,io,0x3f8,9600n8
> > earlyprintk=uart,mmio,0xff5e0000,115200n8
> > in addition to vga, ttyS, serial
>
> I would rather try to merge 8250_early and early_printk.
> "console=uart,io,0x3f8" is already pretty similar to
> "earlyprintk=serial", and it would be nice to have only one.
>
> "console=uart" does have the disadvantage that you have to know the
> port address. But it has the advantage that it doesn't depend on
> compiled-in legacy serial port names. If you need early console
> output, you're probably a developer and can come up with the address.
Given the generic name of "uart" I am assuming this will work with any
UART driver making use of the serial_core.c core -- am I correct?
Maciej
On Wednesday 16 May 2007 11:09:14 am Maciej W. Rozycki wrote:
> On Wed, 16 May 2007, Bjorn Helgaas wrote:
>
> > > for early_uart_console, I have some ideas:
> > > 1. merged that into early_serial_console in
> > > arch/x86_64/kernel/early_printk.c, and
> > > move early_printk.c to kernel/, --- make it understand
> > > earlyprintk=uart,io,0x3f8,9600n8
> > > earlyprintk=uart,mmio,0xff5e0000,115200n8
> > > in addition to vga, ttyS, serial
> >
> > I would rather try to merge 8250_early and early_printk.
> > "console=uart,io,0x3f8" is already pretty similar to
> > "earlyprintk=serial", and it would be nice to have only one.
> >
> > "console=uart" does have the disadvantage that you have to know the
> > port address. But it has the advantage that it doesn't depend on
> > compiled-in legacy serial port names. If you need early console
> > output, you're probably a developer and can come up with the address.
>
> Given the generic name of "uart" I am assuming this will work with any
> UART driver making use of the serial_core.c core -- am I correct?
I knew somebody would ask that eventually :-)
Unfortunately, the answer is "no." "console=uart" only works with
8250-compatible devices.
On Wed, 16 May 2007, Bjorn Helgaas wrote:
> > Given the generic name of "uart" I am assuming this will work with any
> > UART driver making use of the serial_core.c core -- am I correct?
>
> I knew somebody would ask that eventually :-)
>
> Unfortunately, the answer is "no." "console=uart" only works with
> 8250-compatible devices.
But is it a design limitation or is it just that other UART drivers have
to be modified to work with this option? My point is if the former, then
the option should be something like "console=8250" (the right-hand side
being the name of the driver involved; others may want to add support for
other drivers). If the latter, then it's fine as is as other UART drivers
may be wired to this code as a need arises.
Maciej
On 5/17/07, Maciej W. Rozycki <[email protected]> wrote:
> On Wed, 16 May 2007, Bjorn Helgaas wrote:
>
> > > Given the generic name of "uart" I am assuming this will work with any
> > > UART driver making use of the serial_core.c core -- am I correct?
> >
> > I knew somebody would ask that eventually :-)
> >
> > Unfortunately, the answer is "no." "console=uart" only works with
> > 8250-compatible devices.
>
> But is it a design limitation or is it just that other UART drivers have
> to be modified to work with this option? My point is if the former, then
> the option should be something like "console=8250" (the right-hand side
> being the name of the driver involved; others may want to add support for
> other drivers). If the latter, then it's fine as is as other UART drivers
> may be wired to this code as a need arises.
>
> Maciej
>
Actually that early_uart is not real early one.
it is called via console_initcall.
for IA64, Bjom is calling that directly in setup_arch.
Please check my patch to make it to be called via early_param, that
will be good to other platform.
also you may extend to support other early_uart.
YH
On Thursday 17 May 2007 03:45:36 am Maciej W. Rozycki wrote:
> On Wed, 16 May 2007, Bjorn Helgaas wrote:
> > > Given the generic name of "uart" I am assuming this will work with any
> > > UART driver making use of the serial_core.c core -- am I correct?
> >
> > I knew somebody would ask that eventually :-)
> >
> > Unfortunately, the answer is "no." "console=uart" only works with
> > 8250-compatible devices.
>
> But is it a design limitation or is it just that other UART drivers have
> to be modified to work with this option? My point is if the former, then
> the option should be something like "console=8250" (the right-hand side
> being the name of the driver involved; others may want to add support for
> other drivers). If the latter, then it's fine as is as other UART drivers
> may be wired to this code as a need arises.
"console=8250" probably would have been a better choice. I think
this could be changed without too much hassle.
It might be possible to extend "console=uart" so one could do
"console=uart,io,0x3f8,9600n8,21285" (where "21285" is a non-8250
UART type). But that seems ugly to me. I'd rather have
"console=21285", "console=68328", etc.
I just want the "console=<tag>" to explicitly identify the UART
type so we don't have to poke at the thing and guess what it is.
Bjorn