Hi Peter,
with 4.1-rc1, my boxes with early console enabled show something like
this (the example is vexpress, but it for example also happens on an
AM335x board):
earlycon: no match for ttyAMA0,38400n8
The box was booted with "console=ttyAMA0,38400n8" on the commandline.
If I understand this right, the code in drivers/tty/serial/earlycon.c
calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
fails to find that string in the "names" part of the __earlycon_table,
because for the pl011 component on vexpress, the early console was
registered in drivers/tty/serial/amba-pl011.c with:
OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
^^^^^ name
So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
feeling that I didn't understand the logic behind that.
Can you elaborate about how this is supposed to work correctly?
Thanks,
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Robert,
On 05/03/2015 05:10 PM, Robert Schwebel wrote:
> Hi Peter,
>
> with 4.1-rc1, my boxes with early console enabled show something like
> this (the example is vexpress, but it for example also happens on an
> AM335x board):
>
> earlycon: no match for ttyAMA0,38400n8
This shouldn't impact any previous earlycon setup. Are you saying
you're seeing a regression?
How do you have early console enabled, via the command line or via DT?
> The box was booted with "console=ttyAMA0,38400n8" on the commandline.
> If I understand this right, the code in drivers/tty/serial/earlycon.c
> calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
> fails to find that string in the "names" part of the __earlycon_table,
> because for the pl011 component on vexpress, the early console was
> registered in drivers/tty/serial/amba-pl011.c with:
>
> OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
> ^^^^^ name
>
> So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
> feeling that I didn't understand the logic behind that.
>
> Can you elaborate about how this is supposed to work correctly?
Yeah, I've been meaning to write about this but simply haven't had the
time yet; apologies for that.
The facility is hopefully best explained by the existing 8250 exemplar.
Normally, an 8250 early console is started via command line with a
command line parameter like:
earlycon=uart,io,0x2f8,115200n8
Since 2007, an 8250 early console can also be started via command line
using console= instead, like:
console=uart,io,0x2f8,115200n8
In this alternate form, this early console will go on to become the
corresponding ttyS console.
However, that functionality was exclusive to 8250 console/earlycon.
To get this same behavior for the amba-pl011 console would look
something like:
/* drivers/tty/serial/amba-pl011.c */
/* returns 0 if the console matches; otherwise, non-zero to use default matching */
static int pl011_console_match(struct console *co, char *name, int idx, char *options)
{
unsigned char iotype;
unsigned long addr;
if (strncmp(name, "pl" 2) != 0 || idx != 11)
return -ENODEV;
if (uart_parse_earlycon(options, &iotype, &addr, &options))
return -ENODEV;
/* find the port from the addr */
for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
if (amba_ports[i] == NULL)
continue;
if (port->mapbase != addr)
continue;
co->index = i;
return pl011_console_setup(co, options);
}
return -ENODEV;
}
...
static struct console amba_console = {
...
.match = pl011_console_match,
...
};
Regards,
Peter Hurley
On 05/04/2015 10:01 AM, Peter Hurley wrote:
> Hi Robert,
>
> On 05/03/2015 05:10 PM, Robert Schwebel wrote:
>> Hi Peter,
>>
>> with 4.1-rc1, my boxes with early console enabled show something like
>> this (the example is vexpress, but it for example also happens on an
>> AM335x board):
>>
>> earlycon: no match for ttyAMA0,38400n8
>
> This shouldn't impact any previous earlycon setup. Are you saying
> you're seeing a regression?
>
> How do you have early console enabled, via the command line or via DT?
>
>
>> The box was booted with "console=ttyAMA0,38400n8" on the commandline.
>> If I understand this right, the code in drivers/tty/serial/earlycon.c
>> calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
>> fails to find that string in the "names" part of the __earlycon_table,
>> because for the pl011 component on vexpress, the early console was
>> registered in drivers/tty/serial/amba-pl011.c with:
>>
>> OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
>> ^^^^^ name
>>
>> So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
>> feeling that I didn't understand the logic behind that.
>>
>> Can you elaborate about how this is supposed to work correctly?
>
> Yeah, I've been meaning to write about this but simply haven't had the
> time yet; apologies for that.
>
> The facility is hopefully best explained by the existing 8250 exemplar.
> Normally, an 8250 early console is started via command line with a
> command line parameter like:
>
> earlycon=uart,io,0x2f8,115200n8
>
> Since 2007, an 8250 early console can also be started via command line
> using console= instead, like:
>
> console=uart,io,0x2f8,115200n8
>
> In this alternate form, this early console will go on to become the
> corresponding ttyS console.
>
> However, that functionality was exclusive to 8250 console/earlycon.
> To get this same behavior for the amba-pl011 console would look
> something like:
>
> /* drivers/tty/serial/amba-pl011.c */
>
> /* returns 0 if the console matches; otherwise, non-zero to use default matching */
> static int pl011_console_match(struct console *co, char *name, int idx, char *options)
> {
> unsigned char iotype;
> unsigned long addr;
>
> if (strncmp(name, "pl" 2) != 0 || idx != 11)
^
,
Sorry, missed that.
> return -ENODEV;
>
> if (uart_parse_earlycon(options, &iotype, &addr, &options))
> return -ENODEV;
>
> /* find the port from the addr */
> for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
> if (amba_ports[i] == NULL)
> continue;
> if (port->mapbase != addr)
> continue;
>
> co->index = i;
> return pl011_console_setup(co, options);
> }
>
> return -ENODEV;
> }
>
> ...
>
> static struct console amba_console = {
> ...
> .match = pl011_console_match,
> ...
> };
>
>
> Regards,
> Peter Hurley
>
Hi Peter,
On Mon, May 04, 2015 at 10:01:37AM -0400, Peter Hurley wrote:
> > with 4.1-rc1, my boxes with early console enabled show something like
> > this (the example is vexpress, but it for example also happens on an
> > AM335x board):
> >
> > earlycon: no match for ttyAMA0,38400n8
>
> This shouldn't impact any previous earlycon setup. Are you saying
> you're seeing a regression?
Well, it is a warning, and the system was warning-free on mainline with
the last kernels. People assume something is wrong if they read such a
message, so I'm searching for a way to do it right and get rid of the
warning again.
> How do you have early console enabled, via the command line or via DT?
Neither nor: the same SD card image runs on qemu (vexpress) and on an
AM335x. It has its primary console on the serial console:
- console=ttyAMA0,38400 (amba-pl011.c, vexpress)
- console=ttyO2,115200n8 (omap-serial.c, AM335x)
There is no "earlycon" on the commandline and nothing earlycon related I
did on purpose in the oftree.
My expectation would be to configure the system in a way that I have
everything necessary for earlecon usage compiled into the kernel, so I
can enable it manually from the bootloader whenever I need it (i.e. by
adding 'earlycon' to the kernel commandline, or by modifying the oftree
before it is handled over to the kernel).
> > The box was booted with "console=ttyAMA0,38400n8" on the commandline.
> > If I understand this right, the code in drivers/tty/serial/earlycon.c
> > calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
> > fails to find that string in the "names" part of the __earlycon_table,
> > because for the pl011 component on vexpress, the early console was
> > registered in drivers/tty/serial/amba-pl011.c with:
> >
> > OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
> > ^^^^^ name
> >
> > So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
> > feeling that I didn't understand the logic behind that.
> >
> > Can you elaborate about how this is supposed to work correctly?
>
> Yeah, I've been meaning to write about this but simply haven't had the
> time yet; apologies for that.
>
> The facility is hopefully best explained by the existing 8250 exemplar.
> Normally, an 8250 early console is started via command line with a
> command line parameter like:
>
> earlycon=uart,io,0x2f8,115200n8
What happens if you don't have this parameter on the kernel commandline,
but use the same port for your serial console? i.e. 'console=ttyS0'?
I would expect the same warning I see on my boxes.
> Since 2007, an 8250 early console can also be started via command line
> using console= instead, like:
>
> console=uart,io,0x2f8,115200n8
No: "console=..." puts the console on that port, not the early console.
The semantic for console= was always to specify the name of the device
there, so "console=ttyS0...", not "console=uart...", right?
> In this alternate form, this early console will go on to become the
> corresponding ttyS console.
>
> However, that functionality was exclusive to 8250 console/earlycon.
> To get this same behavior for the amba-pl011 console would look
> something like:
>
> /* drivers/tty/serial/amba-pl011.c */
>
> /* returns 0 if the console matches; otherwise, non-zero to use default matching */
> static int pl011_console_match(struct console *co, char *name, int idx, char *options)
> {
> unsigned char iotype;
> unsigned long addr;
>
> if (strncmp(name, "pl" 2) != 0 || idx != 11)
> return -ENODEV;
>
> if (uart_parse_earlycon(options, &iotype, &addr, &options))
> return -ENODEV;
>
> /* find the port from the addr */
> for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
> if (amba_ports[i] == NULL)
> continue;
> if (port->mapbase != addr)
> continue;
>
> co->index = i;
> return pl011_console_setup(co, options);
> }
>
> return -ENODEV;
> }
>
> ...
>
> static struct console amba_console = {
> ...
> .match = pl011_console_match,
> ...
> };
pl011 already has:
----------8<----------8<----------8<----------8<----------8<----------8<----------
static void pl011_early_write(struct console *con, const char *s, unsigned n)
{
struct earlycon_device *dev = con->data;
uart_console_write(&dev->port, s, n, pl011_putc);
}
static int __init pl011_early_console_setup(struct earlycon_device *device,
const char *opt)
{
if (!device->port.membase)
return -ENODEV;
device->con->write = pl011_early_write;
return 0;
}
EARLYCON_DECLARE(pl011, pl011_early_console_setup);
OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
----------8<----------8<----------8<----------8<----------8<----------8<----------
So on oftree based systems it registers an __earlycon_table with name=pl011 and
compatible=arm,pl011. In order to see something, I need to add
console=ttyAMA0
In that case, it doesn't matter if I add an earlycon= parameter on the
commandline or not. The system takes the console= entry and hands it over to
setup_earlycon(), which tries to match it against the __earlycon_table, where
it doesn't find anything. Simply because it is pl011 there.
So switching earlycon on is broken.
If I leave out earlycon, I'd expect to switch off earlycon, which doesn't work,
because exactly the same as above happens.
So switching earlycon off is also broken.
This is either buggy or I didn't understand how it is supposed to be used.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 05/04/2015 03:42 PM, Robert Schwebel wrote:
> Hi Peter,
>
> On Mon, May 04, 2015 at 10:01:37AM -0400, Peter Hurley wrote:
>>> with 4.1-rc1, my boxes with early console enabled show something like
>>> this (the example is vexpress, but it for example also happens on an
>>> AM335x board):
>>>
>>> earlycon: no match for ttyAMA0,38400n8
>>
>> This shouldn't impact any previous earlycon setup. Are you saying
>> you're seeing a regression?
>
> Well, it is a warning, and the system was warning-free on mainline with
> the last kernels. People assume something is wrong if they read such a
> message, so I'm searching for a way to do it right and get rid of the
> warning again.
It's not a warning; it's simply a diagnostic in case the earlycon was
misspelled. Since 2007, 'console=' is a early param synonym for 'earlycon=';
IOW, the message is new but not the behavior.
>> How do you have early console enabled, via the command line or via DT?
>
> Neither nor: the same SD card image runs on qemu (vexpress) and on an
> AM335x. It has its primary console on the serial console:
>
> - console=ttyAMA0,38400 (amba-pl011.c, vexpress)
> - console=ttyO2,115200n8 (omap-serial.c, AM335x)
>
> There is no "earlycon" on the commandline and nothing earlycon related I
> did on purpose in the oftree.
Ok. In your first email, you said "my boxes with early console enabled",
so I thought you meant that you were starting an earlycon. I see now
you meant enabled, as in built-in (not enabled as in started).
> My expectation would be to configure the system in a way that I have
> everything necessary for earlecon usage compiled into the kernel, so I
> can enable it manually from the bootloader whenever I need it (i.e. by
> adding 'earlycon' to the kernel commandline, or by modifying the oftree
> before it is handled over to the kernel).
Ok.
>>> The box was booted with "console=ttyAMA0,38400n8" on the commandline.
>>> If I understand this right, the code in drivers/tty/serial/earlycon.c
>>> calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
>>> fails to find that string in the "names" part of the __earlycon_table,
>>> because for the pl011 component on vexpress, the early console was
>>> registered in drivers/tty/serial/amba-pl011.c with:
>>>
>>> OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
>>> ^^^^^ name
>>>
>>> So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
>>> feeling that I didn't understand the logic behind that.
>>>
>>> Can you elaborate about how this is supposed to work correctly?
The facility I describe below is to enable earlycon->console handoff.
If you're not interested in that, please disregard.
I provided the description because it wasn't clear to me from your
original email if that was something you were trying to implement and
couldn't get working.
>> Yeah, I've been meaning to write about this but simply haven't had the
>> time yet; apologies for that.
>>
>> The facility is hopefully best explained by the existing 8250 exemplar.
>> Normally, an 8250 early console is started via command line with a
>> command line parameter like:
>>
>> earlycon=uart,io,0x2f8,115200n8
>
> What happens if you don't have this parameter on the kernel commandline,
> but use the same port for your serial console? i.e. 'console=ttyS0'?
>
> I would expect the same warning I see on my boxes.
The diagnostic was added in commit 470ca0de69feaba5df215ad804cec1859883a5ed
("serial: earlycon: Enable earlycon without command line param").
Previously, if earlycon failed to start because of an error, such as because the
earlycon name was misspelled, there was no diagnostic.
>> Since 2007, an 8250 early console can also be started via command line
>> using console= instead, like:
>>
>> console=uart,io,0x2f8,115200n8
>
> No: "console=..." puts the console on that port, not the early console.
> The semantic for console= was always to specify the name of the device
> there, so "console=ttyS0...", not "console=uart...", right?
>From Documentation/kernel-parameters:
console= [KNL] Output console device and options.
....
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
uart[8250],mmio32,<addr>[,options]
uart[8250],0x<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later.
MMIO inter-register address stride is either 8-bit
(mmio) or 32-bit (mmio32).
If none of [io|mmio|mmio32], <addr> is assumed to be
equivalent to 'mmio'. 'options' are specified in the
same format described for ttyS above; if unspecified,
the h/w is not re-initialized.
This behavior was added in Jul 2007 with commit 18a8bd949d6adb311
("serial: convert early_uart to earlycon for 8250").
>> In this alternate form, this early console will go on to become the
>> corresponding ttyS console.
>>
>> However, that functionality was exclusive to 8250 console/earlycon.
>> To get this same behavior for the amba-pl011 console would look
>> something like:
>>
>> /* drivers/tty/serial/amba-pl011.c */
>>
>> /* returns 0 if the console matches; otherwise, non-zero to use default matching */
>> static int pl011_console_match(struct console *co, char *name, int idx, char *options)
>> {
>> unsigned char iotype;
>> unsigned long addr;
>>
>> if (strncmp(name, "pl" 2) != 0 || idx != 11)
>> return -ENODEV;
>>
>> if (uart_parse_earlycon(options, &iotype, &addr, &options))
>> return -ENODEV;
>>
>> /* find the port from the addr */
>> for (i = 0; i < ARRAY_SIZE(amba_ports); i++) {
>> if (amba_ports[i] == NULL)
>> continue;
>> if (port->mapbase != addr)
>> continue;
>>
>> co->index = i;
>> return pl011_console_setup(co, options);
>> }
>>
>> return -ENODEV;
>> }
>>
>> ...
>>
>> static struct console amba_console = {
>> ...
>> .match = pl011_console_match,
>> ...
>> };
>
> pl011 already has:
>
> ----------8<----------8<----------8<----------8<----------8<----------8<----------
>
> static void pl011_early_write(struct console *con, const char *s, unsigned n)
> {
> struct earlycon_device *dev = con->data;
>
> uart_console_write(&dev->port, s, n, pl011_putc);
> }
>
> static int __init pl011_early_console_setup(struct earlycon_device *device,
> const char *opt)
> {
> if (!device->port.membase)
> return -ENODEV;
>
> device->con->write = pl011_early_write;
> return 0;
> }
> EARLYCON_DECLARE(pl011, pl011_early_console_setup);
> OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
>
> ----------8<----------8<----------8<----------8<----------8<----------8<----------
>
> So on oftree based systems it registers an __earlycon_table with name=pl011 and
> compatible=arm,pl011. In order to see something, I need to add
>
> console=ttyAMA0
>
> In that case, it doesn't matter if I add an earlycon= parameter on the
> commandline or not. The system takes the console= entry and hands it over to
> setup_earlycon(), which tries to match it against the __earlycon_table, where
> it doesn't find anything. Simply because it is pl011 there.
>
> So switching earlycon on is broken.
>
> If I leave out earlycon, I'd expect to switch off earlycon, which doesn't work,
> because exactly the same as above happens.
>
> So switching earlycon off is also broken.
>
> This is either buggy or I didn't understand how it is supposed to be used.
AFAICT nothing is broken; you're only seeing a new diagnostic from code that
was always running.
Regards,
Peter Hurley
On Mon, May 04, 2015 at 10:01:37AM -0400, Peter Hurley wrote:
> Hi Robert,
>
> On 05/03/2015 05:10 PM, Robert Schwebel wrote:
> > Hi Peter,
> >
> > with 4.1-rc1, my boxes with early console enabled show something like
> > this (the example is vexpress, but it for example also happens on an
> > AM335x board):
> >
> > earlycon: no match for ttyAMA0,38400n8
>
> This shouldn't impact any previous earlycon setup. Are you saying
> you're seeing a regression?
>
> How do you have early console enabled, via the command line or via DT?
What happens here is that Robert has console=ttyAMA0,38400n8 in his
command line. In init/main.c we have:
static int __init do_early_param(char *param, char *val, const char *unused)
{
const struct obs_kernel_param *p;
for (p = __setup_start; p < __setup_end; p++) {
if ((p->early && parameq(param, p->str)) ||
(strcmp(param, "console") == 0 &&
strcmp(p->str, "earlycon") == 0)
) {
if (p->setup_func(val) != 0)
pr_warn("Malformed early option '%s'\n", param);
}
}
/* We accept everything at this stage. */
return 0;
}
This means that param_setup_earlycon() gets called with the arguments
passed to the console= parameter which makes no sense in this context
and leads to the "no match for" message.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 05/04/2015 04:22 PM, Sascha Hauer wrote:
> On Mon, May 04, 2015 at 10:01:37AM -0400, Peter Hurley wrote:
>> Hi Robert,
>>
>> On 05/03/2015 05:10 PM, Robert Schwebel wrote:
>>> Hi Peter,
>>>
>>> with 4.1-rc1, my boxes with early console enabled show something like
>>> this (the example is vexpress, but it for example also happens on an
>>> AM335x board):
>>>
>>> earlycon: no match for ttyAMA0,38400n8
>>
>> This shouldn't impact any previous earlycon setup. Are you saying
>> you're seeing a regression?
>>
>> How do you have early console enabled, via the command line or via DT?
>
> What happens here is that Robert has console=ttyAMA0,38400n8 in his
> command line.
Yeah, thanks, that much is now clear from his second email.
> In init/main.c we have:
>
> static int __init do_early_param(char *param, char *val, const char *unused)
> {
> const struct obs_kernel_param *p;
>
> for (p = __setup_start; p < __setup_end; p++) {
> if ((p->early && parameq(param, p->str)) ||
> (strcmp(param, "console") == 0 &&
> strcmp(p->str, "earlycon") == 0)
> ) {
> if (p->setup_func(val) != 0)
> pr_warn("Malformed early option '%s'\n", param);
> }
> }
> /* We accept everything at this stage. */
> return 0;
> }
>
> This means that param_setup_earlycon() gets called with the arguments
> passed to the console= parameter which makes no sense in this context
> and leads to the "no match for" message.
Right, except that "the context" has insufficient information to differentiate
an error, such as a misspelled earlycon name, from any other use.
Regards,
Peter Hurley
On Mon, May 04, 2015 at 04:21:47PM -0400, Peter Hurley wrote:
> >>> earlycon: no match for ttyAMA0,38400n8
> >>
> >> This shouldn't impact any previous earlycon setup. Are you saying
> >> you're seeing a regression?
> >
> > Well, it is a warning, and the system was warning-free on mainline with
> > the last kernels. People assume something is wrong if they read such a
> > message, so I'm searching for a way to do it right and get rid of the
> > warning again.
>
> It's not a warning; it's simply a diagnostic in case the earlycon was
> misspelled.
Just that in my case nothing is misspelled...?
The message is on the same level as "firmware not found" or any other
message that tells the casual observer that something unexpected is
going on, which is bad behaviour if the system really wants to say that
everything is ok.
I enabled all necessary drivers, I configure the system console to be on
ttyAMA0, and still it tells me about "no match".
And, as I wrote in my last mail, there is nothing I can do to actually
*make* it match.
> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
> the message is new but not the behavior.
"console=" had nothing to do with early param before.
> > > How do you have early console enabled, via the command line or via DT?
> >
> > Neither nor: the same SD card image runs on qemu (vexpress) and on an
> > AM335x. It has its primary console on the serial console:
> >
> > - console=ttyAMA0,38400 (amba-pl011.c, vexpress)
> > - console=ttyO2,115200n8 (omap-serial.c, AM335x)
> >
> > There is no "earlycon" on the commandline and nothing earlycon related I
> > did on purpose in the oftree.
>
> Ok. In your first email, you said "my boxes with early console enabled",
> so I thought you meant that you were starting an earlycon. I see now
> you meant enabled, as in built-in (not enabled as in started).
Sorry, I was imprecise here. I meant "CONFIG_SERIAL_EARLYCON=y".
> > My expectation would be to configure the system in a way that I have
> > everything necessary for earlecon usage compiled into the kernel, so I
> > can enable it manually from the bootloader whenever I need it (i.e. by
> > adding 'earlycon' to the kernel commandline, or by modifying the oftree
> > before it is handled over to the kernel).
>
> Ok.
>
> >>> The box was booted with "console=ttyAMA0,38400n8" on the commandline.
> >>> If I understand this right, the code in drivers/tty/serial/earlycon.c
> >>> calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
> >>> fails to find that string in the "names" part of the __earlycon_table,
> >>> because for the pl011 component on vexpress, the early console was
> >>> registered in drivers/tty/serial/amba-pl011.c with:
> >>>
> >>> OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
> >>> ^^^^^ name
> >>>
> >>> So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
> >>> feeling that I didn't understand the logic behind that.
> >>>
> >>> Can you elaborate about how this is supposed to work correctly?
>
> The facility I describe below is to enable earlycon->console handoff.
> If you're not interested in that, please disregard.
>
> I provided the description because it wasn't clear to me from your
> original email if that was something you were trying to implement and
> couldn't get working.
No, I'm using vanilla 4.1-rc1, without any patch, and I don't want to
implement something. As the involved drivers have support for early
console, all I want to do is to use it the way it was intended. This
fails so far.
> >> Yeah, I've been meaning to write about this but simply haven't had the
> >> time yet; apologies for that.
> >>
> >> The facility is hopefully best explained by the existing 8250 exemplar.
> >> Normally, an 8250 early console is started via command line with a
> >> command line parameter like:
> >>
> >> earlycon=uart,io,0x2f8,115200n8
> >
> > What happens if you don't have this parameter on the kernel commandline,
> > but use the same port for your serial console? i.e. 'console=ttyS0'?
> >
> > I would expect the same warning I see on my boxes.
>
> The diagnostic was added in commit 470ca0de69feaba5df215ad804cec1859883a5ed
> ("serial: earlycon: Enable earlycon without command line param").
>
> Previously, if earlycon failed to start because of an error, such as because the
> earlycon name was misspelled, there was no diagnostic.
That's a good intention :-)
However, you seem to have a different usecase, any my one is broken.
> >> Since 2007, an 8250 early console can also be started via command line
> >> using console= instead, like:
> >>
> >> console=uart,io,0x2f8,115200n8
> >
> > No: "console=..." puts the console on that port, not the early console.
> > The semantic for console= was always to specify the name of the device
> > there, so "console=ttyS0...", not "console=uart...", right?
>
> From Documentation/kernel-parameters:
>
> console= [KNL] Output console device and options.
>
> ....
>
> uart[8250],io,<addr>[,options]
> uart[8250],mmio,<addr>[,options]
> uart[8250],mmio32,<addr>[,options]
> uart[8250],0x<addr>[,options]
> Start an early, polled-mode console on the 8250/16550
> UART at the specified I/O port or MMIO address,
> switching to the matching ttyS device later.
> MMIO inter-register address stride is either 8-bit
> (mmio) or 32-bit (mmio32).
> If none of [io|mmio|mmio32], <addr> is assumed to be
> equivalent to 'mmio'. 'options' are specified in the
> same format described for ttyS above; if unspecified,
> the h/w is not re-initialized.
>
> This behavior was added in Jul 2007 with commit 18a8bd949d6adb311
> ("serial: convert early_uart to earlycon for 8250").
In order to let you better understand the setup here: My AM335x device
(same CPU as on BeagleBone) is a headless embedded system, the only
input/output device it has is a serial port. No display, no touch. For
development, a pretty similar system is simulated in QEMU, with
vexpress.
Until recently, specifying "console=ttyAMA0" was the correct way to get
the kernel + userspace output out of that serial line. On ARM, there was
no "early" mechanism, only early_printk.
I wouldn't mind if your citation from kernel-parameters above was true
and I could get an (early and non-early) serial console with a unified
"console=ttyAMA0".
However, it doesn't work, as "ttyAMA0" doesn't match "pl011".
> AFAICT nothing is broken; you're only seeing a new diagnostic from code that
> was always running.
So I'm doing the right thing here, and it doesn't work.
Do we agree that this is a bug?
Or how do you suggest I should use the code correctly?
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 05/04/2015 04:52 PM, Robert Schwebel wrote:
> On Mon, May 04, 2015 at 04:21:47PM -0400, Peter Hurley wrote:
>>>>> earlycon: no match for ttyAMA0,38400n8
>>>>
>>>> This shouldn't impact any previous earlycon setup. Are you saying
>>>> you're seeing a regression?
>>>
>>> Well, it is a warning, and the system was warning-free on mainline with
>>> the last kernels. People assume something is wrong if they read such a
>>> message, so I'm searching for a way to do it right and get rid of the
>>> warning again.
>>
>> It's not a warning; it's simply a diagnostic in case the earlycon was
>> misspelled.
>
> Just that in my case nothing is misspelled...?
Since the set of possible console names is not a closed set, there's
simply no way to differentiate a misspelled name from a name that
has not been added because a console driver has not yet loaded.
> The message is on the same level as "firmware not found" or any other
> message that tells the casual observer that something unexpected is
> going on, which is bad behaviour if the system really wants to say that
> everything is ok.
>
> I enabled all necessary drivers, I configure the system console to be on
> ttyAMA0, and still it tells me about "no match".
>
> And, as I wrote in my last mail, there is nothing I can do to actually
> *make* it match.
>
>> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
>> the message is new but not the behavior.
>
> "console=" had nothing to do with early param before.
*Yes, it has* since the commit I referenced in the previous email and
the email before that when I noted that 'console=' and 'earlycon=' are
synonyms if CONFIG_SERIAL_EARLYCON=y, and it has been that way since
2007.
The only thing that has changed is that I added a diagnostic; _to repeat_,
the earlycon matching code has always run in this case, only the
diagnostic is new.
>>>> How do you have early console enabled, via the command line or via DT?
>>>
>>> Neither nor: the same SD card image runs on qemu (vexpress) and on an
>>> AM335x. It has its primary console on the serial console:
>>>
>>> - console=ttyAMA0,38400 (amba-pl011.c, vexpress)
>>> - console=ttyO2,115200n8 (omap-serial.c, AM335x)
>>>
>>> There is no "earlycon" on the commandline and nothing earlycon related I
>>> did on purpose in the oftree.
>>
>> Ok. In your first email, you said "my boxes with early console enabled",
>> so I thought you meant that you were starting an earlycon. I see now
>> you meant enabled, as in built-in (not enabled as in started).
>
> Sorry, I was imprecise here. I meant "CONFIG_SERIAL_EARLYCON=y".
>
>>> My expectation would be to configure the system in a way that I have
>>> everything necessary for earlecon usage compiled into the kernel, so I
>>> can enable it manually from the bootloader whenever I need it (i.e. by
>>> adding 'earlycon' to the kernel commandline, or by modifying the oftree
>>> before it is handled over to the kernel).
>>
>> Ok.
>>
>>>>> The box was booted with "console=ttyAMA0,38400n8" on the commandline.
>>>>> If I understand this right, the code in drivers/tty/serial/earlycon.c
>>>>> calls setup_earlycon() with the string above ("ttyAMA0,38400n8") and
>>>>> fails to find that string in the "names" part of the __earlycon_table,
>>>>> because for the pl011 component on vexpress, the early console was
>>>>> registered in drivers/tty/serial/amba-pl011.c with:
>>>>>
>>>>> OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
>>>>> ^^^^^ name
>>>>>
>>>>> So isn't that trying to match "ttyAMA0" against "arm,pl011"? I have the
>>>>> feeling that I didn't understand the logic behind that.
>>>>>
>>>>> Can you elaborate about how this is supposed to work correctly?
>>
>> The facility I describe below is to enable earlycon->console handoff.
>> If you're not interested in that, please disregard.
>>
>> I provided the description because it wasn't clear to me from your
>> original email if that was something you were trying to implement and
>> couldn't get working.
>
> No, I'm using vanilla 4.1-rc1, without any patch, and I don't want to
> implement something. As the involved drivers have support for early
> console, all I want to do is to use it the way it was intended. This
> fails so far.
I'm unclear what you believe is failing here; the console does start, yes?
>>>> Yeah, I've been meaning to write about this but simply haven't had the
>>>> time yet; apologies for that.
>>>>
>>>> The facility is hopefully best explained by the existing 8250 exemplar.
>>>> Normally, an 8250 early console is started via command line with a
>>>> command line parameter like:
>>>>
>>>> earlycon=uart,io,0x2f8,115200n8
>>>
>>> What happens if you don't have this parameter on the kernel commandline,
>>> but use the same port for your serial console? i.e. 'console=ttyS0'?
>>>
>>> I would expect the same warning I see on my boxes.
>>
>> The diagnostic was added in commit 470ca0de69feaba5df215ad804cec1859883a5ed
>> ("serial: earlycon: Enable earlycon without command line param").
>>
>> Previously, if earlycon failed to start because of an error, such as because the
>> earlycon name was misspelled, there was no diagnostic.
>
> That's a good intention :-)
>
> However, you seem to have a different usecase, any my one is broken.
Again, I'm not clear what you see as broken.
As I understand you,
1. you have CONFIG_SERIAL_EARLYCON=y
2. but you don't specify an earlycon
3. so no earlycon starts.
4. your command line includes "console=ttyAMA0,115200n8"
5. and a console starts on that port (yes?)
I don't see a regression here from any previous kernel; this is exactly
the same behavior as before, so what is broken?
>>>> Since 2007, an 8250 early console can also be started via command line
>>>> using console= instead, like:
>>>>
>>>> console=uart,io,0x2f8,115200n8
>>>
>>> No: "console=..." puts the console on that port, not the early console.
>>> The semantic for console= was always to specify the name of the device
>>> there, so "console=ttyS0...", not "console=uart...", right?
>>
>> From Documentation/kernel-parameters:
>>
>> console= [KNL] Output console device and options.
>>
>> ....
>>
>> uart[8250],io,<addr>[,options]
>> uart[8250],mmio,<addr>[,options]
>> uart[8250],mmio32,<addr>[,options]
>> uart[8250],0x<addr>[,options]
>> Start an early, polled-mode console on the 8250/16550
>> UART at the specified I/O port or MMIO address,
>> switching to the matching ttyS device later.
>> MMIO inter-register address stride is either 8-bit
>> (mmio) or 32-bit (mmio32).
>> If none of [io|mmio|mmio32], <addr> is assumed to be
>> equivalent to 'mmio'. 'options' are specified in the
>> same format described for ttyS above; if unspecified,
>> the h/w is not re-initialized.
>>
>> This behavior was added in Jul 2007 with commit 18a8bd949d6adb311
>> ("serial: convert early_uart to earlycon for 8250").
>
> In order to let you better understand the setup here: My AM335x device
> (same CPU as on BeagleBone) is a headless embedded system, the only
> input/output device it has is a serial port. No display, no touch. For
> development, a pretty similar system is simulated in QEMU, with
> vexpress.
>
> Until recently, specifying "console=ttyAMA0" was the correct way to get
> the kernel + userspace output out of that serial line. On ARM, there was
> no "early" mechanism, only early_printk.
>
> I wouldn't mind if your citation from kernel-parameters above was true
> and I could get an (early and non-early) serial console with a unified
> "console=ttyAMA0".
>
> However, it doesn't work, as "ttyAMA0" doesn't match "pl011".
The AM335x does not have a AMBA pl011 port, so "console=ttyAMA0,..." has no
effect on that hardware, and never has. Something else is providing console
on that setup. Please attach your entire dmesg log for that setup.
>> AFAICT nothing is broken; you're only seeing a new diagnostic from code that
>> was always running.
>
> So I'm doing the right thing here, and it doesn't work.
I'm not sure what you mean by "it doesn't work".
Are you saying that the serial console is not starting?
Regards,
Peter Hurley
> Do we agree that this is a bug?
>
> Or how do you suggest I should use the code correctly?
>
> rsc
>
On Mon, May 04, 2015 at 05:27:35PM -0400, Peter Hurley wrote:
> As I understand you,
>
> 1. you have CONFIG_SERIAL_EARLYCON=y
> 2. but you don't specify an earlycon
> 3. so no earlycon starts.
> 4. your command line includes "console=ttyAMA0,115200n8"
> 5. and a console starts on that port (yes?)
>
> I don't see a regression here from any previous kernel; this is exactly
> the same behavior as before, so what is broken?
It outputs a warning message "no match" because it assumes that
"ttyAMA0" (specified in the console= entry on the kernel commandline)
matches with "pl011", coming from OF_EARLYCON_DECLARE for the serial
driver.
I don't understand how this is supposed to work: it will *never* match,
right?
You say it is a diagnostics message that indicates a misspelling.
I fail to see what is misspelled, so what does it diagnose?
> > In order to let you better understand the setup here: My AM335x device
> > (same CPU as on BeagleBone) is a headless embedded system, the only
> > input/output device it has is a serial port. No display, no touch. For
> > development, a pretty similar system is simulated in QEMU, with
> > vexpress.
> >
> > Until recently, specifying "console=ttyAMA0" was the correct way to get
> > the kernel + userspace output out of that serial line. On ARM, there was
> > no "early" mechanism, only early_printk.
> >
> > I wouldn't mind if your citation from kernel-parameters above was true
> > and I could get an (early and non-early) serial console with a unified
> > "console=ttyAMA0".
> >
> > However, it doesn't work, as "ttyAMA0" doesn't match "pl011".
>
> The AM335x does not have a AMBA pl011 port, so "console=ttyAMA0,..." has no
> effect on that hardware, and never has. Something else is providing console
> on that setup. Please attach your entire dmesg log for that setup.
Hardware 1: AM335x
drivers/serial/tty/omap-serial.c
console=ttyO2,115200n8
Hardware 2: QEMU/vexpress
drivers/serial/tty/amba-pl011.c
console=ttyAMA0,38400
The same kernel runs on both platforms.
Let's just discuss the 2nd case for now, with ttyAMA0 (which is pl011),
which has earlycon support and registers here:
http://lxr.free-electrons.com/source/drivers/tty/serial/amba-pl011.c#L2129
> > So I'm doing the right thing here, and it doesn't work.
>
> I'm not sure what you mean by "it doesn't work".
> Are you saying that the serial console is not starting?
The serial console is starting.
It claims that earlycon has "no match", while the correct serial device
is specified.
How do you suggest this is supposed to be used in the pl011 case,
without the "diagnostic message" triggering that says "no match"?
Here is the full serial console log (directed to qemu's stdout):
----------8<----------8<----------8<----------8<----------8<----------
rsc@callisto:OSELAS.BSP-GF$ configs/platform-gf/run
[ 0.000000] Linux version 4.1.0-rc1+ (rsc@callisto) (gcc version 4.8.3 20131111 (prerelease) (OSELAS.Toolchain-2013.12.2 linaro-4.8-2013.11) ) #10 PREEMPT Mon May 4 23:03:27 CEST 2015
[ 0.000000] earlycon: no match for ttyAMA0,38400n8
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootfs=ext2 rw mem=1024M console=ttyAMA0,38400n8 loglevel=6 rootwait rootfstype=ext4
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0674ed4 (6580 kB)
[ 0.000000] .init : 0xc0675000 - 0xc06b2000 ( 244 kB)
[ 0.000000] .data : 0xc06b2000 - 0xc06fd3e8 ( 301 kB)
[ 0.000000] .bss : 0xc0700000 - 0xc073a5d8 ( 234 kB)
[ 0.000000] L2C: platform modifies aux control register: 0x02020000 -> 0x02420000
[ 0.000000] L2C: DT/platform modifies aux control register: 0x02020000 -> 0x02420000
[ 0.425170] platform 10000000.sysreg: Error -2 creating of_node link
[ 0.429607] platform basic-mmio-gpio.1.auto: Error -2 creating of_node link
[ 0.429959] platform basic-mmio-gpio.2.auto: Error -2 creating of_node link
[ 0.430561] platform basic-mmio-gpio.3.auto: Error -2 creating of_node link
[ 0.604531] of_amba_device_create(): amba_device_add() failed (-19) for /memory-controller@100e0000
[ 0.605709] of_amba_device_create(): amba_device_add() failed (-19) for /memory-controller@100e1000
[ 0.606411] of_amba_device_create(): amba_device_add() failed (-19) for /watchdog@100e5000
[ 0.620892] of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@7,00000000/sysctl@01000
[ 0.633512] of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@7,00000000/wdt@0f000
[ 0.725997] SCSI subsystem initialized
[ 0.796591] NFS: Registering the id_resolver key type
[ 0.797533] Key type id_resolver registered
[ 0.797758] Key type id_legacy registered
[ 0.998780] Key type dns_resolver registered
[ 1.403497] random: nonblocking pool is initialized
Welcome to PTXdist / af inventions-GF!
[ OK ] Created slice Root Slice.
[ OK ] Listening on Journal Socket (/dev/log).
[ OK ] Listening on udev Kernel Socket.
<...>
----------8<----------8<----------8<----------8<----------8<----------
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 05/04/2015 05:58 PM, Robert Schwebel wrote:
> On Mon, May 04, 2015 at 05:27:35PM -0400, Peter Hurley wrote:
>> As I understand you,
>>
>> 1. you have CONFIG_SERIAL_EARLYCON=y
>> 2. but you don't specify an earlycon
>> 3. so no earlycon starts.
>> 4. your command line includes "console=ttyAMA0,115200n8"
>> 5. and a console starts on that port (yes?)
>>
>> I don't see a regression here from any previous kernel; this is exactly
>> the same behavior as before, so what is broken?
>
> It outputs a warning message "no match" because it assumes that
> "ttyAMA0" (specified in the console= entry on the kernel commandline)
> matches with "pl011", coming from OF_EARLYCON_DECLARE for the serial
> driver.
>
> I don't understand how this is supposed to work: it will *never* match,
> right?
>
> You say it is a diagnostics message that indicates a misspelling.
> I fail to see what is misspelled, so what does it diagnose?
Ok, so this is only about the diagnostic message, and not about some
other failure.
I don't typically describe harmless diagnostics that didn't appear before
as "broken", so I was having trouble believing what I was reading.
Now that I understand that this is _only_ about a diagnostic message that
didn't appear in previous kernels, I will direct to what I have written
previously multiple times.
Further, I would ask how _you_ would programmatically distinguish
misspellings amongst the following console strings?
console=pl012,...
console=_pl011,...
console=pl,...
console=ttyAMA0,...
Regards,
Peter Hurley
>>> In order to let you better understand the setup here: My AM335x device
>>> (same CPU as on BeagleBone) is a headless embedded system, the only
>>> input/output device it has is a serial port. No display, no touch. For
>>> development, a pretty similar system is simulated in QEMU, with
>>> vexpress.
>>>
>>> Until recently, specifying "console=ttyAMA0" was the correct way to get
>>> the kernel + userspace output out of that serial line. On ARM, there was
>>> no "early" mechanism, only early_printk.
>>>
>>> I wouldn't mind if your citation from kernel-parameters above was true
>>> and I could get an (early and non-early) serial console with a unified
>>> "console=ttyAMA0".
>>>
>>> However, it doesn't work, as "ttyAMA0" doesn't match "pl011".
>>
>> The AM335x does not have a AMBA pl011 port, so "console=ttyAMA0,..." has no
>> effect on that hardware, and never has. Something else is providing console
>> on that setup. Please attach your entire dmesg log for that setup.
>
> Hardware 1: AM335x
> drivers/serial/tty/omap-serial.c
> console=ttyO2,115200n8
>
> Hardware 2: QEMU/vexpress
> drivers/serial/tty/amba-pl011.c
> console=ttyAMA0,38400
>
> The same kernel runs on both platforms.
>
> Let's just discuss the 2nd case for now, with ttyAMA0 (which is pl011),
> which has earlycon support and registers here:
>
> http://lxr.free-electrons.com/source/drivers/tty/serial/amba-pl011.c#L2129
>
>>> So I'm doing the right thing here, and it doesn't work.
>>
>> I'm not sure what you mean by "it doesn't work".
>> Are you saying that the serial console is not starting?
>
> The serial console is starting.
>
> It claims that earlycon has "no match", while the correct serial device
> is specified.
>
> How do you suggest this is supposed to be used in the pl011 case,
> without the "diagnostic message" triggering that says "no match"?
>
> Here is the full serial console log (directed to qemu's stdout):
>
> ----------8<----------8<----------8<----------8<----------8<----------
> rsc@callisto:OSELAS.BSP-GF$ configs/platform-gf/run
> [ 0.000000] Linux version 4.1.0-rc1+ (rsc@callisto) (gcc version 4.8.3 20131111 (prerelease) (OSELAS.Toolchain-2013.12.2 linaro-4.8-2013.11) ) #10 PREEMPT Mon May 4 23:03:27 CEST 2015
> [ 0.000000] earlycon: no match for ttyAMA0,38400n8
> [ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootfs=ext2 rw mem=1024M console=ttyAMA0,38400n8 loglevel=6 rootwait rootfstype=ext4
PS - If the message really bothers you that much, please feel free to submit a
patch to Greg that lowers that message level to pr_info() instead, so it
doesn't appear in your logs.
I've include an _unsigned_ patch below which does just that. Feel free to
modify and submit it to Greg with your Signed-off-by.
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> [ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
> [ 0.000000] .text : 0xc0008000 - 0xc0674ed4 (6580 kB)
> [ 0.000000] .init : 0xc0675000 - 0xc06b2000 ( 244 kB)
> [ 0.000000] .data : 0xc06b2000 - 0xc06fd3e8 ( 301 kB)
> [ 0.000000] .bss : 0xc0700000 - 0xc073a5d8 ( 234 kB)
> [ 0.000000] L2C: platform modifies aux control register: 0x02020000 -> 0x02420000
> [ 0.000000] L2C: DT/platform modifies aux control register: 0x02020000 -> 0x02420000
> [ 0.425170] platform 10000000.sysreg: Error -2 creating of_node link
> [ 0.429607] platform basic-mmio-gpio.1.auto: Error -2 creating of_node link
> [ 0.429959] platform basic-mmio-gpio.2.auto: Error -2 creating of_node link
> [ 0.430561] platform basic-mmio-gpio.3.auto: Error -2 creating of_node link
> [ 0.604531] of_amba_device_create(): amba_device_add() failed (-19) for /memory-controller@100e0000
> [ 0.605709] of_amba_device_create(): amba_device_add() failed (-19) for /memory-controller@100e1000
> [ 0.606411] of_amba_device_create(): amba_device_add() failed (-19) for /watchdog@100e5000
> [ 0.620892] of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@7,00000000/sysctl@01000
> [ 0.633512] of_amba_device_create(): amba_device_add() failed (-19) for /smb/motherboard/iofpga@7,00000000/wdt@0f000
> [ 0.725997] SCSI subsystem initialized
> [ 0.796591] NFS: Registering the id_resolver key type
> [ 0.797533] Key type id_resolver registered
> [ 0.797758] Key type id_legacy registered
> [ 0.998780] Key type dns_resolver registered
> [ 1.403497] random: nonblocking pool is initialized
>
> Welcome to PTXdist / af inventions-GF!
>
> [ OK ] Created slice Root Slice.
> [ OK ] Listening on Journal Socket (/dev/log).
> [ OK ] Listening on udev Kernel Socket.
>
> <...>
>
> ----------8<----------8<----------8<----------8<----------8<----------
>
> rsc
>
--- >% ---
Subject: [PATCH] earlycon: Reduce log message level of "earlycon: no match for
..."
---
drivers/tty/serial/earlycon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 5fdc9f3..a7725f6 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -188,7 +188,7 @@ static int __init param_setup_earlycon(char *buf)
err = setup_earlycon(buf);
if (err == -ENOENT) {
- pr_warn("no match for %s\n", buf);
+ pr_info("no match for %s\n", buf);
err = 0;
} else if (err == -EALREADY) {
pr_warn("already registered\n");
--
2.4.0
Peter,
On Mon, May 04, 2015 at 06:31:44PM -0400, Peter Hurley wrote:
> > You say it is a diagnostics message that indicates a misspelling.
> > I fail to see what is misspelled, so what does it diagnose?
>
> Ok, so this is only about the diagnostic message, and not about some
> other failure.
>
> I don't typically describe harmless diagnostics that didn't appear before
> as "broken", so I was having trouble believing what I was reading.
>
> Now that I understand that this is _only_ about a diagnostic message that
> didn't appear in previous kernels, I will direct to what I have written
> previously multiple times.
>
> Further, I would ask how _you_ would programmatically distinguish
> misspellings amongst the following console strings?
>
> console=pl012,...
> console=_pl011,...
> console=pl,...
> console=ttyAMA0,...
Only the last line gives me output, but with the warning. All others are
misspellings but output nothing. The last one gives me a misspelling
warning, but it is the one that makes the output work.
Obviously this was not tested on an ARM device with a serial console,
because it doesn't work there.
There should be an intended variant where *nothing* is misspelled in my
oftree+kernel commandline.
In that case, the system should come up, console comes out of the serial
line and earlycon is available. Then I should not get a diagnostic
message, becasue I did everything right.
Case A: consoleo=ttyAMA0
Result: - system boots with output on intended serial console
- warning about having the earlycon misspelled
- earlycon not operational, although driver supports it
Case B: console=pl011
Result: - no output at all, because system doesn't output to its
intented serial console.
Case C: ...?
Are there other things I'm supposed to do in order to do it right?
So both cases A+B are not fully working as intented, right?
I'd like to fix it, but in order to do so, I want to learn how it is
actually *intended* to work.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 05/05/2015 12:51 AM, Robert Schwebel wrote:
> Peter,
>
> On Mon, May 04, 2015 at 06:31:44PM -0400, Peter Hurley wrote:
>>> You say it is a diagnostics message that indicates a misspelling.
>>> I fail to see what is misspelled, so what does it diagnose?
>>
>> Ok, so this is only about the diagnostic message, and not about some
>> other failure.
>>
>> I don't typically describe harmless diagnostics that didn't appear before
>> as "broken", so I was having trouble believing what I was reading.
>>
>> Now that I understand that this is _only_ about a diagnostic message that
>> didn't appear in previous kernels, I will direct to what I have written
>> previously multiple times.
>>
>> Further, I would ask how _you_ would programmatically distinguish
>> misspellings amongst the following console strings?
>>
>> console=pl012,...
>> console=_pl011,...
>> console=pl,...
>> console=ttyAMA0,...
>
> Only the last line gives me output, but with the warning. All others are
> misspellings but output nothing. The last one gives me a misspelling
> warning, but it is the one that makes the output work.
>
> Obviously this was not tested on an ARM device with a serial console,
> because it doesn't work there.
The primary test platform was a ARM device with a serial console.
And yes, it does work there.
> There should be an intended variant where *nothing* is misspelled in my
> oftree+kernel commandline.
>
> In that case, the system should come up, console comes out of the serial
> line and earlycon is available. Then I should not get a diagnostic
> message, becasue I did everything right.
On 05/04/2015 05:27 PM, Peter Hurley wrote:
> Since the set of possible console names is not a closed set, there's
> simply no way to differentiate a misspelled name from a name that
> has not been added because a console driver has not yet loaded.
> Case A: consoleo=ttyAMA0
>
> Result: - system boots with output on intended serial console
> - warning about having the earlycon misspelled
> - earlycon not operational, although driver supports it
>
> Case B: console=pl011
>
> Result: - no output at all, because system doesn't output to its
> intented serial console.
>
> Case C: ...?
>
> Are there other things I'm supposed to do in order to do it right?
>
> So both cases A+B are not fully working as intented, right?
>
> I'd like to fix it, but in order to do so, I want to learn how it is
> actually *intended* to work.
What do you want to "fix"?
Please stop using the indefinite pronoun, "it". I have no idea to what
you are referring, because I already supplied you with a patch to "fix"
the loglevel of the message.
Regards,
Peter Hurley
On Tue, May 05, 2015 at 06:39:47AM -0400, Peter Hurley wrote:
> > > Further, I would ask how _you_ would programmatically distinguish
> > > misspellings amongst the following console strings?
> > >
> > > console=pl012,...
> > > console=_pl011,...
> > > console=pl,...
> > > console=ttyAMA0,...
> >
> > Only the last line gives me output, but with the warning. All others are
> > misspellings but output nothing. The last one gives me a misspelling
> > warning, but it is the one that makes the output work.
> >
> > Obviously this was not tested on an ARM device with a serial console,
> > because it doesn't work there.
>
> The primary test platform was a ARM device with a serial console.
> And yes, it does work there.
Which ARM device was that, and which serial driver?
How did the kernel command line look like?
Maybe that helps me to understand how this is supposed to be used, which
is currently totally unclear.
> > Case A: console=ttyAMA0
> >
> > Result: - system boots with output on intended serial console
> > - warning about having the earlycon misspelled
> > - earlycon not operational, although driver supports it
> >
> > Case B: console=pl011
> >
> > Result: - no output at all, because system doesn't output to its
> > intented serial console.
> >
> > Case C: ...?
> >
> > Are there other things I'm supposed to do in order to do it right?
> >
> > So both cases A+B are not fully working as intented, right?
> >
> > I'd like to fix it, but in order to do so, I want to learn how it is
> > actually *intended* to work.
>
> What do you want to "fix"?
>
> Please stop using the indefinite pronoun, "it". I have no idea to what
> you are referring, because I already supplied you with a patch to "fix"
> the loglevel of the message.
I have explained that above, under "Case A" and "Case B"...?
Sorry, I simply don't get it.
My task:
I want to setup a vexpress system with a pl011 serial port in a
way that the console + early console is configured to be on
/dev/ttyAMA0.
My attempts:
Case A from above -> doesn't set the earlycon to /dev/ttyAMA0.
Case B from above -> doesn't output anything.
I fail to find out how this task is supposed to be done in a way that
the kernel doesn't complain, and with the result to have console and
earlycon on /dev/ttyAMA0.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, May 5, 2015 at 1:51 AM, Robert Schwebel
<[email protected]> wrote:
> In that case, the system should come up, console comes out of the serial
> line and earlycon is available. Then I should not get a diagnostic
> message, becasue I did everything right.
On imx6q-wandboard when building multi_v7_defconfig, we get [1]:
[ 0.000000] earlycon: no match for ttymxc0,115200
[1] http://arm-soc.lixom.net/bootlogs/next/next-20150505/wandboard-arm-multi_v7_defconfig.html
Actually this 'no match' warning appears in all arm configs:
http://arm-soc.lixom.net/bootlogs/next/next-20150505/
On 05/05/2015 12:32 PM, Robert Schwebel wrote:
> On Tue, May 05, 2015 at 06:39:47AM -0400, Peter Hurley wrote:
>>>> Further, I would ask how _you_ would programmatically distinguish
>>>> misspellings amongst the following console strings?
>>>>
>>>> console=pl012,...
>>>> console=_pl011,...
>>>> console=pl,...
>>>> console=ttyAMA0,...
>>>
>>> Only the last line gives me output, but with the warning. All others are
>>> misspellings but output nothing. The last one gives me a misspelling
>>> warning, but it is the one that makes the output work.
>>>
>>> Obviously this was not tested on an ARM device with a serial console,
>>> because it doesn't work there.
>>
>> The primary test platform was a ARM device with a serial console.
>> And yes, it does work there.
>
> Which ARM device was that, and which serial driver?
AM3358 Beaglebone Black Rev. C, omap_8250 driver.
Requires patchset "Earlycon cleanup" which is not yet upstream,
but you can find it on LKML or linux-serial.
That patchset depends on "libfdt: Add fdt_path_offset_namelen", which
is in upstream dtc tree but has not been imported into mainline tree yet.
https://lkml.org/lkml/2015/4/28/387
> How did the kernel command line look like?
Kernel command line
earlycon=omap8250,0x44e09000,115200n8 console=ttyS0,115200n8 root=/dev/mmcblk0p2 \
ro fixrtc rootfstype=ext4 rootwait
I've also tested
console=omap8250,0x44e09000,115200n8 ....
with a private version of the 8250_omap driver which implements
earlycon->console handoff.
I've also tested various DT and command line mixes of same, with and
with the <options> parameter.
> Maybe that helps me to understand how this is supposed to be used, which
> is currently totally unclear.
>
>>> Case A: console=ttyAMA0
>>>
>>> Result: - system boots with output on intended serial console
>>> - warning about having the earlycon misspelled
>>> - earlycon not operational, although driver supports it
>>>
>>> Case B: console=pl011
>>>
>>> Result: - no output at all, because system doesn't output to its
>>> intented serial console.
>>>
>>> Case C: ...?
>>>
>>> Are there other things I'm supposed to do in order to do it right?
>>>
>>> So both cases A+B are not fully working as intented, right?
>>>
>>> I'd like to fix it, but in order to do so, I want to learn how it is
>>> actually *intended* to work.
>>
>> What do you want to "fix"?
>>
>> Please stop using the indefinite pronoun, "it". I have no idea to what
>> you are referring, because I already supplied you with a patch to "fix"
>> the loglevel of the message.
>
> I have explained that above, under "Case A" and "Case B"...?
Go back and read what you wrote under "Case A" and "Case B". Both
descriptions simply report what happened. Neither description identifies
what you are trying to accomplish.
> Sorry, I simply don't get it.
>
> My task:
>
> I want to setup a vexpress system with a pl011 serial port in a
> way that the console + early console is configured to be on
> /dev/ttyAMA0.
Ok. This is the _first_ time you have written what you are trying
to accomplish.
Step #1: grab fixmap support for ARM patch from LKML
"[RFC PATCH] ARM: add fixmap based earlycon support" by Ard Biesheuvel
- or -
"[PATCH] ARM: early fixmap support for earlycon" by Stefan Agner
Neither patch is upstream yet; I'm not really sure what's going on
with ARM patches right now.
Step #2: configure earlycon from kernel command line
earlycon=pl011,<addr of uart0> console=ttyAMA0,115200n8
(Optional) Step #3 - implement pl011 -> ttyAMA0 console mapping
I already wrote how to do this in my first email in this thread.
If you've done step #3, then you can change your kernel command line to
simply read:
console=pl011,<addr of uart0>
which will start an earlycon and then handoff to /dev/ttyAMA0 automatically
(if you've implemented step #3).
Regards,
Peter Hurley
On Mon, 4 May 2015, Peter Hurley wrote:
> >> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
> >> the message is new but not the behavior.
> >
> > "console=" had nothing to do with early param before.
>
> *Yes, it has* since the commit I referenced in the previous email and
> the email before that when I noted that 'console=' and 'earlycon=' are
> synonyms if CONFIG_SERIAL_EARLYCON=y, and it has been that way since
> 2007.
>
> The only thing that has changed is that I added a diagnostic; _to repeat_,
> the earlycon matching code has always run in this case, only the
> diagnostic is new.
What's the point of having two parameters as synonyms whose syntax is not
compatible to each other in the general case? I'd expect the following
cases to be handled:
1. Regular console only (no early console requested) => `console=foo...'.
2. Both early and regular console => `earlycon=blah... console=foo...'.
3. Early console handing over to regular console => `earlycon=blah...'.
Why do you want to support `console=blah...' too (a question to be asked
back in 2007, but better late than never)?
If you do need to support such aliasing, then I suggest that you complain
about no early console match only if `earlycon=blah...' has been truly
used and avoid the warning where `console=blah...' has been used instead
(a warning about the latter can be issued where no regular console match
happened).
Maciej
On 05/07/2015 01:09 PM, Maciej W. Rozycki wrote:
> On Mon, 4 May 2015, Peter Hurley wrote:
>
>>>> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
>>>> the message is new but not the behavior.
>>>
>>> "console=" had nothing to do with early param before.
>>
>> *Yes, it has* since the commit I referenced in the previous email and
>> the email before that when I noted that 'console=' and 'earlycon=' are
>> synonyms if CONFIG_SERIAL_EARLYCON=y, and it has been that way since
>> 2007.
>>
>> The only thing that has changed is that I added a diagnostic; _to repeat_,
>> the earlycon matching code has always run in this case, only the
>> diagnostic is new.
>
> What's the point of having two parameters as synonyms whose syntax is not
> compatible to each other in the general case? I'd expect the following
> cases to be handled:
>
> 1. Regular console only (no early console requested) => `console=foo...'.
>
> 2. Both early and regular console => `earlycon=blah... console=foo...'.
>
> 3. Early console handing over to regular console => `earlycon=blah...'.
4. Early console only => `earlycon=blah...'
How to distinguish between 3 & 4?
> Why do you want to support `console=blah...' too (a question to be asked
> back in 2007, but better late than never)?
Command line is considered to be userspace, so it doesn't really matter
what I think about whether console= should have been overloaded like that.
The fact is, it was.
> If you do need to support such aliasing, then I suggest that you complain
> about no early console match only if `earlycon=blah...' has been truly
> used and avoid the warning where `console=blah...' has been used instead
> (a warning about the latter can be issued where no regular console match
> happened).
I'm tearing it out; I'd prefer to go back to the old way where you
don't know why your earlycon didn't start, and I don't get emails
complaining about logs.
Regards,
Peter Hurley
On Thu, 7 May 2015, Peter Hurley wrote:
> > What's the point of having two parameters as synonyms whose syntax is not
> > compatible to each other in the general case? I'd expect the following
> > cases to be handled:
> >
> > 1. Regular console only (no early console requested) => `console=foo...'.
> >
> > 2. Both early and regular console => `earlycon=blah... console=foo...'.
> >
> > 3. Early console handing over to regular console => `earlycon=blah...'.
>
> 4. Early console only => `earlycon=blah...'
>
> How to distinguish between 3 & 4?
Good point. If you want to disable the handover, then it has to be
handled by the early console driver somehow. Perhaps an option for
`earlycon=' (e.g. `nohandover') would be required for that. In that case
the default selection would apply for the regular console, depending on
the available drivers.
Your concern appears to me unrelated to `earlycon=' vs `console='
parameter aliasing though. The same observation about the handover
applies whether the parameters are aliased to each other or not. Have I
missed anything?
> > Why do you want to support `console=blah...' too (a question to be asked
> > back in 2007, but better late than never)?
>
> Command line is considered to be userspace, so it doesn't really matter
> what I think about whether console= should have been overloaded like that.
>
> The fact is, it was.
The change has not been cast in stone, it can always be reverted if on
the second thoughts it is concluded to have been wrong.
How does this overload interact with multiple `console=' options being
present BTW, which one is considered the early console? Or do we support
driving multiple early consoles in parallel just as we do with regular
consoles?
> > If you do need to support such aliasing, then I suggest that you complain
> > about no early console match only if `earlycon=blah...' has been truly
> > used and avoid the warning where `console=blah...' has been used instead
> > (a warning about the latter can be issued where no regular console match
> > happened).
>
> I'm tearing it out; I'd prefer to go back to the old way where you
> don't know why your earlycon didn't start, and I don't get emails
> complaining about logs.
Up to you.
Maciej
On 05/07/2015 04:14 PM, Maciej W. Rozycki wrote:
> On Thu, 7 May 2015, Peter Hurley wrote:
>
>>> What's the point of having two parameters as synonyms whose syntax is not
>>> compatible to each other in the general case? I'd expect the following
>>> cases to be handled:
>>>
>>> 1. Regular console only (no early console requested) => `console=foo...'.
>>>
>>> 2. Both early and regular console => `earlycon=blah... console=foo...'.
>>>
>>> 3. Early console handing over to regular console => `earlycon=blah...'.
>>
>> 4. Early console only => `earlycon=blah...'
>>
>> How to distinguish between 3 & 4?
>
> Good point. If you want to disable the handover, then it has to be
> handled by the early console driver somehow. Perhaps an option for
> `earlycon=' (e.g. `nohandover') would be required for that. In that case
> the default selection would apply for the regular console, depending on
> the available drivers.
>
> Your concern appears to me unrelated to `earlycon=' vs `console='
> parameter aliasing though. The same observation about the handover
> applies whether the parameters are aliased to each other or not. Have I
> missed anything?
>
>>> Why do you want to support `console=blah...' too (a question to be asked
>>> back in 2007, but better late than never)?
>>
>> Command line is considered to be userspace, so it doesn't really matter
>> what I think about whether console= should have been overloaded like that.
>>
>> The fact is, it was.
>
> The change has not been cast in stone, it can always be reverted if on
> the second thoughts it is concluded to have been wrong.
>
> How does this overload interact with multiple `console=' options being
> present BTW, which one is considered the early console? Or do we support
> driving multiple early consoles in parallel just as we do with regular
> consoles?
Please familiarize yourself with the existing 'console=' and 'earlycon='
command line options documented in Documentation/kernel-parameters.txt
These have not changed with 4.1-rc
Regards,
Peter Hurley
On Thu, 7 May 2015, Peter Hurley wrote:
> > How does this overload interact with multiple `console=' options being
> > present BTW, which one is considered the early console? Or do we support
> > driving multiple early consoles in parallel just as we do with regular
> > consoles?
>
> Please familiarize yourself with the existing 'console=' and 'earlycon='
> command line options documented in Documentation/kernel-parameters.txt
Thank you for your suggestion, however that documentation does not answer
my questions I am afraid (and neither does serial-console.txt). Otherwise
I wouldn't have asked them in the first place. If you don't know the
answers either, then it's OK to say: "I don't know".
E.g. (given the parameter aliasing we have) will:
`earlycon=uart8250,io,0x3f8 console=tty0'
`console=tty0 earlycon=uart8250,io,0x3f8'
do what I expect it to, that is open the UART at 0x3f8 as an early console
and then hand it over to the ttyS0 device as respectively a secondary and
the primary (/dev/console) regular console? I've skipped options such as
baud rates for brevity.
Maciej
On 05/07/2015 06:25 PM, Maciej W. Rozycki wrote:
> On Thu, 7 May 2015, Peter Hurley wrote:
>
>>> How does this overload interact with multiple `console=' options being
>>> present BTW, which one is considered the early console? Or do we support
>>> driving multiple early consoles in parallel just as we do with regular
>>> consoles?
>>
>> Please familiarize yourself with the existing 'console=' and 'earlycon='
>> command line options documented in Documentation/kernel-parameters.txt
>
> Thank you for your suggestion, however that documentation does not answer
> my questions I am afraid (and neither does serial-console.txt). Otherwise
> I wouldn't have asked them in the first place. If you don't know the
> answers either, then it's OK to say: "I don't know".
>
> E.g. (given the parameter aliasing we have) will:
>
> `earlycon=uart8250,io,0x3f8 console=tty0'
> `console=tty0 earlycon=uart8250,io,0x3f8'
>
> do what I expect it to, that is open the UART at 0x3f8 as an early console
> and then hand it over to the ttyS0 device as respectively a secondary and
> the primary (/dev/console) regular console?
No.
>From Documentation/kernel-parameters.txt:
earlycon= [KNL] Output early console device and options.
.....
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
uart[8250],mmio32,<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
MMIO inter-register address stride is either 8-bit
(mmio) or 32-bit (mmio32).
The options are the same as for ttyS, above.
IOW, command line parameters of the form:
earlycon=uart8250,...
does not perform earlycon-to-console handoff.
Also from Documentation/kernel-parameters.txt:
console= [KNL] Output console device and options.
.....
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later. The
options are the same as for ttyS, above.
IOW, command line parameters of the form:
console=uart8250,...
performs earlycon-to-console handoff.
Furthermore, because of the way aliasing was implemented in 2007,
it has been possible since to start _any_ earlycon with command line
parameters of the form:
console=<earlycon name>,....
However, only 8250 implemented the console handoff.
Regards,
Peter Hurley
On Thu, May 07, 2015 at 01:22:11PM -0400, Peter Hurley wrote:
> On 05/07/2015 01:09 PM, Maciej W. Rozycki wrote:
> > On Mon, 4 May 2015, Peter Hurley wrote:
> >
> >>>> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
> >>>> the message is new but not the behavior.
> >>>
> >>> "console=" had nothing to do with early param before.
> >>
> >> *Yes, it has* since the commit I referenced in the previous email and
> >> the email before that when I noted that 'console=' and 'earlycon=' are
> >> synonyms if CONFIG_SERIAL_EARLYCON=y, and it has been that way since
> >> 2007.
> >>
> >> The only thing that has changed is that I added a diagnostic; _to repeat_,
> >> the earlycon matching code has always run in this case, only the
> >> diagnostic is new.
> >
> > What's the point of having two parameters as synonyms whose syntax is not
> > compatible to each other in the general case? I'd expect the following
> > cases to be handled:
> >
> > 1. Regular console only (no early console requested) => `console=foo...'.
> >
> > 2. Both early and regular console => `earlycon=blah... console=foo...'.
> >
> > 3. Early console handing over to regular console => `earlycon=blah...'.
>
> 4. Early console only => `earlycon=blah...'
>
> How to distinguish between 3 & 4?
Given that the aliasing only makes sense for console=uart, and
console=uart8250, we can do the following. Not exactly the nicest
code, but only slighty more ugly than what we have now in
do_early_param()
Sascha
--------------------------8<----------------------------
>From e4d5a09877e48308ee0cf4170f2eef8aa2f747f5 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <[email protected]>
Date: Fri, 8 May 2015 08:23:47 +0200
Subject: [PATCH] param: console: Do not treat console as synonym for earlycon
Since 2007 console= and earlycon= are treated as synonyms, but the
syntax for both options is different. The only case in which they
are identical is for console=uart or console=uart8250. All other
cases currently lead to the warning:
earlycon: no match for xxx
This patch drops the general aliasing, but keeps the current
behaviour for console=uart and console=uart8250 to keep the kernel
parameters compatible.
Signed-off-by: Sascha Hauer <[email protected]>
---
init/main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/init/main.c b/init/main.c
index 2115055..bfcbbc5 100644
--- a/init/main.c
+++ b/init/main.c
@@ -413,12 +413,15 @@ static noinline void __init_refok rest_init(void)
static int __init do_early_param(char *param, char *val, const char *unused)
{
const struct obs_kernel_param *p;
+ bool earlyconalias = false;
+
+ if (val && !strcmp(param, "console") &&
+ (!strncmp(val, "uart,", 5) || !strncmp(val, "uart8250,", 9)))
+ earlyconalias = true;
for (p = __setup_start; p < __setup_end; p++) {
if ((p->early && parameq(param, p->str)) ||
- (strcmp(param, "console") == 0 &&
- strcmp(p->str, "earlycon") == 0)
- ) {
+ (earlyconalias && strcmp(p->str, "earlycon") == 0)) {
if (p->setup_func(val) != 0)
pr_warn("Malformed early option '%s'\n", param);
}
--
2.1.4
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 05/08/2015 02:34 AM, Sascha Hauer wrote:
> On Thu, May 07, 2015 at 01:22:11PM -0400, Peter Hurley wrote:
>> On 05/07/2015 01:09 PM, Maciej W. Rozycki wrote:
>>> On Mon, 4 May 2015, Peter Hurley wrote:
>>>
>>>>>> Since 2007, 'console=' is a early param synonym for 'earlycon='; IOW,
>>>>>> the message is new but not the behavior.
>>>>>
>>>>> "console=" had nothing to do with early param before.
>>>>
>>>> *Yes, it has* since the commit I referenced in the previous email and
>>>> the email before that when I noted that 'console=' and 'earlycon=' are
>>>> synonyms if CONFIG_SERIAL_EARLYCON=y, and it has been that way since
>>>> 2007.
>>>>
>>>> The only thing that has changed is that I added a diagnostic; _to repeat_,
>>>> the earlycon matching code has always run in this case, only the
>>>> diagnostic is new.
>>>
>>> What's the point of having two parameters as synonyms whose syntax is not
>>> compatible to each other in the general case? I'd expect the following
>>> cases to be handled:
>>>
>>> 1. Regular console only (no early console requested) => `console=foo...'.
>>>
>>> 2. Both early and regular console => `earlycon=blah... console=foo...'.
>>>
>>> 3. Early console handing over to regular console => `earlycon=blah...'.
>>
>> 4. Early console only => `earlycon=blah...'
>>
>> How to distinguish between 3 & 4?
>
> Given that the aliasing only makes sense for console=uart, and
> console=uart8250, we can do the following. Not exactly the nicest
> code, but only slighty more ugly than what we have now in
> do_early_param()
I already sent Greg a patch to remove the egregious and unsightly
false positive warning. Thanks anyway.
Regards,
Peter Hurley
On Thu, 7 May 2015, Peter Hurley wrote:
> IOW, command line parameters of the form:
>
> earlycon=uart8250,...
>
> does not perform earlycon-to-console handoff.
[...]
> IOW, command line parameters of the form:
>
> console=uart8250,...
>
> performs earlycon-to-console handoff.
OK, thanks. I missed this detail previously and understood the two
parameters had been since 2007 strict aliases to each other. Thanks for
your patience to explain it to me.
Maciej