Not a problem as such WarSE. What happens is that recent kernel/arch/udev call the single uart on the BBB ttyS0. Now the console variable in uboot (looks like all the way back in the uboot source code) calls the console ttyO0.
Now when recent arch kernel comes up, it notes that ttyO0 doesn't exist, so the console passed to the kernel command line is wrong, and so the kernel reassigns it to ttyS0, which is the only uart it can find.
So arch does come up in working state, with the console connected to the UART0 that comes out on the BBB pins. However it does have the error in the kernel log, that the reassignment has been performed.
So to my mind might as well set the uboot console variable to what the arch kernel is expecting ....
When I get the chance plan to check with udev, as to why the UART is named ttyS0 - e.g. who has chosen to use that name ...
Interestingly this is TI view of the issue:
http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_DriverttyO0 is what you get when using the omap-serial driver, now that we use the 8250 driver the port is called ttyS0 ...
So ttyO0 is a hang over from an old kernel module no longer used ....
So assuming that omap-serial isn't used any more on any omap devices, suggests that in all of them we should change to ttyS0. Hmmm - wonder if i can change the title of this tread - as its no longer just about BBB, but about all omap devices ...
And checking the 8250_omap.c source code it has:
$this->bbcode_second_pass_code('', '#ifdef CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP
static int __init omap8250_console_fixup(void)
{
char *omap_str;
char *options;
u8 idx;
if (strstr(boot_command_line, "console=ttyS"))
/* user set a ttyS based name for the console */
return 0;
omap_str = strstr(boot_command_line, "console=ttyO");
if (!omap_str)
/* user did not set ttyO based console, so we don't care */
return 0;
omap_str += 12;
if ('0' <= *omap_str && *omap_str <= '9')
idx = *omap_str - '0';
else
return 0;
omap_str++;
if (omap_str[0] == ',') {
omap_str++;
options = omap_str;
} else {
options = NULL;
}
add_preferred_console("ttyS", idx, options);
pr_err("WARNING: Your 'console=ttyO%d' has been replaced by 'ttyS%d'\n",
idx, idx);
pr_err("This ensures that you still see kernel messages. Please\n");
pr_err("update your kernel commandline.\n");
return 0;
}')
So read like the 8250_omap driver gets loaded before omap_serial - and so gets priority.
I'll check the set up on my BBB when i get home. But suspect we should deselect omap_serial and switch to ttyS0 everywhere - as this is the future ...
And finally checking /proc/config.gz:
$this->bbcode_second_pass_code('', 'gunzip -c /proc/config.gz | grep "SERIAL" | grep OMAP
CONFIG_SERIAL_8250_OMAP=y
CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
# CONFIG_SERIAL_OMAP is not set')
And so only 8250_omap is in the kernel in any form, so the console can only be ttyS0 ...