On 06/01/2012 01:55 PM, Darren Hart wrote:
On 06/01/2012 10:53 AM, jfabernathy wrote:
On 06/01/2012 01:44 PM, Darren Hart wrote:What is the boot error?
On 06/01/2012 10:39 AM, jfabernathy wrote:Well this boot error issue seems to be USB Key related because I just
On 06/01/2012 01:01 PM, Darren Hart wrote:Sorry, ddimage wasn't meant to fix the issue, just as a slightly more
On 06/01/2012 08:45 AM, jfabernathy wrote:I'll make the entry.
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.
This script does not eliminate the boot error I get with syslinux on USB
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.
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
convenient/safe wrapper around dd.
I'm not familiar with the error you are seeing with the live image. Can
you point me to the thread or the bug?
did the ddimage script on a edison core-image-sato image using the
.hddimg file and it worked correctly on a hard drive. This was a 1.2GB
image. Now I'll have to add in the parameters that give you more free
disk space now that I'm testing with a real hard drive.
The readme in most of the x86 BSP directory in meta-intel talk about if
you get boot errors to:
dd if=/dev/zero of=/dev/sdf bs=1M count=512
I have not found this to work. Maybe it's a count size issue. I always
use 512, but maybe it should be 4096 for a 4GB USB key.
SYSLINUX 4.03 2010-10-22 CHS Load error- Boot error