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:I believe this is a manual process currently. Please open an enhancement
On 05/31/2012 11:54 AM, jfabernathy wrote:What I found out is the only variable that matters for login console in
On 05/31/2012 02:13 PM, Darren Hart wrote:variable assignments can be tricky, and are not the easiest things to
On 05/31/2012 09:11 AM, jfabernathy wrote:okay now I'm confused. while the cedartrail.conf file has the following:
Using a DN2800MT (Marshalltown) Intel board, I'm testing theLets make sure your environment is what we expect. Please provide the
meta-cedartrail using edison branch and noticed an issues with the
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
Anyone have a solution??
If this is considered a bug I can put it on bugzilla.
$ 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.
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=115200 ttyS0
So is the bitbake command showing the results before the cedartrail.conf
options take affect??
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.
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.
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 theThis is all good feedback to consider as we work through making more
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?
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
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.