uboot console env variable, now that 8250 serial is prefered

This forum is for supported devices using an ARMv7 Texas Instruments (TI) SoC.

uboot console env variable, now that 8250 serial is prefered

Postby summers » Sat Sep 10, 2016 1:01 pm

Hi,

Where does the arch BBB uboot keep the env variables for uboot? E.g. what do you set /etc/fw_env.config to?

Or does it just use the defaul compiled into the uboot image? If so is where is it easiest to read this from?

Ta,

David.
Last edited by summers on Wed Sep 14, 2016 2:34 pm, edited 1 time in total.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB uboot env variables

Postby WarheadsSE » Sat Sep 10, 2016 1:37 pm

https://github.com/archlinuxarm/PKGBUIL ... beaglebone

https://github.com/archlinuxarm/PKGBUIL ... .patch#L33

Essentially,

The variables are either default, or handled by uEnv.txt, and most if not all the defaults are present a few lines below.
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: BBB uboot env variables

Postby summers » Sun Sep 11, 2016 2:12 pm

Thanks WarSE,

So the place to change ttyO0 to ttyS0 is in github? My BBB changes it during boot up so make sense to get it right. Guess I should check though that the standard UART comes up fine with ttyS0, should be easy as I've a serial interface plugged in right now ...

Thanks,

David
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB uboot env variables

Postby summers » Mon Sep 12, 2016 10:02 pm

OK have dug some deaper. My BBB only comes up with ttyS0 at MMIO 0x44e09000 , which is on the external uart pins. This seems to be taken from http://lxr.free-electrons.com/source/arch/arm/boot/dts/am33xx.dtsi, I don't get to see the other uarts defined in the device tree. Can't see right now what names it ttyS0 - but it is looking like the uboot should set console to that, and the BBB boots fine with that as a setting.

When I get the chance I'll submit the github change ....
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: BBB uboot env variables

Postby WarheadsSE » Tue Sep 13, 2016 6:28 pm

I am confused as to what exactly your actual problem is.

The serial console is _moving_ during boot? from ttyO0 to ttyS0?
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: BBB uboot env variables

Postby summers » Wed Sep 14, 2016 9:36 am

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_Driver

ttyO0 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 ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm


Return to Texas Instruments (TI)

Who is online

Users browsing this forum: No registered users and 6 guests