[yocto] This one can't be me...

[Bodke, Kishore K]

Thanks Darren, will follow up on this.

Hi Paul, 
Please try out what Darren has suggested.

-Kishore.

>-----Original Message-----
>From: Darren Hart [mailto:dvhart at linux.intel.com]
>Sent: Wednesday, April 03, 2013 8:39 AM
>To: Paul D. DeRocco
>Cc: yocto at yoctoproject.org; Bodke, Kishore K
>Subject: Re: [yocto] This one can't be me...
>
>Hi Paul,
>
>First off, please CC the relevant maintainers of the recipes and BSPs
>you are having trouble with. The README in the cedartrail BSP lists
>Kishore as the maintainer, now on CC. This will help improve response
>time to your post as well as getting the right people looking at it.
>
>Kishore, can you please work with Paul to get him booting?
>
>Some ideas on things to check/try inline below.
>
>On 04/02/2013 02:27 PM, Paul D. DeRocco wrote:
>> I've successfully built core-image-base-cedartrail-nopvr, with NO
>> modifications, no meta-oe layer to pull in Samba, no attempt to partition
>> the flash drive, just the .hddimg file dd'ed to /dev/sdb, to see if I can
>> get something, anything to boot out of the box.
>>
>> I get a kernel panic when it tries to boot on my Intel DN2800MT mobo, with
>> 1GB of RAM. The error messages, which appear on the attached VGA
>monitor,
>> are:
>>
>> VFS: Cannot open root device "ram0" or unknown-block(0,0)
>> Please append a correct "root=" boot option;
>> here are the available partitions:
>> VFS: Unable to mount root fs on unknown-block(0,0)
>> User configuration error - no valid root filesystem found
>
>
>Believe it or not, this is the single most common boot error in the
>history of boot errors on Linux :-)
>
>It is telling you there is no block device called "ram0" to load and
>there are no other block devices detected. The USB stick doesn't show up
>here because USB can take a while to enumerate and unless you tell the
>kernel to wait for it, it doesn't. That shouldn't be your problem here
>as you are attempting to boot from a ramdisk.
>
>The most obvious question is whether or not the kernel you built has
>ramdisk support. You can do this by analyzing the .config file in your
>linux-yocto build tree
>(build/tmp/work/cedartrail.../linux-yocto*/linux-cedartrail-standard-
>build/.config).
>You want to look for:
>
>$ grep BLK_DEV_RAM .config
>CONFIG_BLK_DEV_RAM=y
>CONFIG_BLK_DEV_RAM_COUNT=16
>CONFIG_BLK_DEV_RAM_SIZE=4096
>
>>
>> Here is the syslinux.cfg file that is controlling the boot:
>>
>> # Automatically created by OE
>> serial 0 115200
>> ALLOWOPTIONS 1
>> DEFAULT boot
>> TIMEOUT 10
>> PROMPT 1
>> LABEL boot
>> KERNEL /vmlinuz
>> APPEND initrd=/initrd LABEL=boot  root=/dev/ram0   console=ttyS0,115200
>> console=tty0 video=vesafb vga=0x318
>> LABEL install
>> KERNEL /vmlinuz
>> APPEND initrd=/initrd LABEL=install  root=/dev/ram0   console=ttyS0,115200
>> console=tty0 video=vesafb vga=0x318
>>
>> This is a live-image boot, and the flash drive contains the usual five
>> files. As far as I can tell, a live-image boot is a two-stage boot beginning
>> with a really stripped down vmlinuz and a small RAM-disk read from initrd,
>> which then reads the big rootfs.img into another RAM-disk and tries to boot
>> the real kernel from that. I don't know which kernel is panicking, because
>> it all flies by so fast.
>
>
>Well, see my comment above, the kernel was about as explicit as it can
>be - it didn't find a block device to mount as root. However, when
>debugging kernel issues, it is important to be able to record the log.
>You have a serial port console configured in your kernel parameters
>(console=ttyS0,115200), it would be a good idea to connect to the serial
>console and capture the boot messages to a file using minicom, screen,
>or similar.
>
>
>> Any ideas, or am I cursed?
>>
>
>Another common problem is the hddimg format itself and conflicts with
>certain firmware. You can try the zip image format as described in
>poky/README.hardware under the "Intel Atom based PCs and devices"
>section.
>
>Finally, usb sticks are terrible about just being bad. Many of them are
>literally write once devices. They're fine so long as you don't fill
>them up, which works for shuffling small files around, but writing full
>OS images to them tends to kill them in a hurry. Try with a brand new stick.
>
>Thanks,
>
>--
>Darren Hart
>Intel Open Source Technology Center
>Yocto Project - Technical Lead - Linux Kernel