Re: meta-cedartrail - serial console


Jim Abernathy
 

On 06/01/2012 01:01 PM, Darren Hart wrote:

On 06/01/2012 08:45 AM, jfabernathy wrote:
On 05/31/2012 03:41 PM, Darren Hart wrote:
On 05/31/2012 11:54 AM, jfabernathy wrote:
On 05/31/2012 02:13 PM, Darren Hart wrote:
On 05/31/2012 09:11 AM, jfabernathy wrote:
Using a DN2800MT (Marshalltown) Intel board, I'm testing the
meta-cedartrail using edison branch and noticed an issues with the
serial console.

The cedartrail.conf in the machine directory has the following statements:

SYSLINUX_OPTS = "serial 0 115200"
SERIAL_CONSOLE = "115200 ttyS0"
APPEND += "console=ttyS0,115200 console=tty0"

However, when the image booted, I had no serial console on ttyS0. I
checked /etc/inittab and noticed that the following line existed:

S:2345:respawn:/sbin/getty 115200 ttyS3

I changed the ttyS3 to ttyS0 and then I have a serial console on the
next reboot. So it appears the override in the .conf file is not
working. Also I only have the console from getty, and not the kernel
logging console.

Anyone have a solution??

If this is considered a bug I can put it on bugzilla.
Lets make sure your environment is what we expect. Please provide the
output of:

$ bitbake core-image-minimal -e | grep SERIAL_CONSOLE=

If it is not "115200 ttyS0" then it is getting overwritten somewhere
either in your config, or possibly by an inappropriate selection of an
assignment operator (=, ?=, etc.) in edison.
okay now I'm confused. while the cedartrail.conf file has the following:
SYSLINUX_OPTS = "serial 3 115200"
SERIAL_CONSOLE = "115200 ttyS3"
APPEND += "console=ttyS3,115200 console=tty3"


The output of the bitbake command you suggested above gives:
jim@ubuntu-x64:~/poky/build$ bitbake core-image-minimal -e | grep
SERIAL_CONSOLE=

# SERIAL_CONSOLE=115200 ttyS0
SERIAL_CONSOLE="115200 ttyS0"
jim@ubuntu-x64:~/poky/build$

So is the bitbake command showing the results before the cedartrail.conf
options take affect??
variable assignments can be tricky, and are not the easiest things to
track down. I suggest looking through your configured layers and looking
for all the SERIAL_CONSOLE assignments using ttyS3 and ttyS0 and see if
you can determine what is overriding your cedartrail.conf setting.
What I found out is the only variable that matters for login console in
my situation is SERIAL_CONSOLE because I have to use grub and the boot
from hard drive method because my image can't be put on a USB Flash for
some reason. So I manually have to edit the grub.cfg file as documented
on the wiki "How Do I" section of putting Yocto on a hard drive. Adding
console=ttyS0,115200 on the linux statement takes care of the boot console.
I believe this is a manual process currently. Please open an enhancement
in bugzilla for your specific situation and I'll incporporate into the
larger boot process and image revamp we're doing for 1.3.
I'll make the entry.
So the question is has there been any thought about automating the
choice of boot loader and the parameters that are needed or optional?
In the case of meta-cedartrail, the cedartrail.conf assumes syslinux is
the boot loader. When I could use a USB Flash key, creating a boot
device was a trivial dd statement. Because I have to use a hard drive
now, I have to do a number of manual steps. Or is there a way to create
a boot-able hard drive with syslinux so the cedartrail.conf parameters
are all that is needed to adjust?
This is all good feedback to consider as we work through making more
universally bootable images. This is becoming a hot topic as people are
using Yocto in more and more situations and as things like EFI become
more commonplace.

There is no reason you can't just dd (have a look at
scripts/contrib/ddimage) the image to a hard disk instead of a usb
stick. You may need a USB to SATA adapter for your host (this is what I
use). If you have a USB port, you could just use the install option.
This script does not eliminate the boot error I get with syslinux on USB flash keys. I noticed the script is not in edison but is in denzil, so I got it there and tried to run it against an image created with edison. I still get the same boot error I get with dd, which is understandable since that's what the script uses. Not sure if this is a size issue because my image is over a 1GB. I'm guessing this this will still fail on a hard drive with the dd'ing of the .hddimg, but I'll test it anyway.
The integration between the boot loader options is something that needs
work. At some point I hope to replace GRUB with syslinux in all possible
situations in order simplify the option handling and present a
consistent boot interface between live images, iso limages, and disk images.

Join yocto@lists.yoctoproject.org to automatically receive all group messages.