[coreboot] QEMU version step-by-step (Actually, just hints here)

[Dan Connelly]

Start with "QEMU Build Tutorial" http://www.coreboot.org/QEMU_Build_Tutorial

Unfortunately, that write up is sketchy and certainly not newbie-proof.

For instance, Tutorial does not point out that, of course, you do need 
to build coreboot BIOS for the Qemu virtual machine (Emulator), not your 
target physical machine.    I suppose this is obvious once you get your 
head around it.   Wasn't obvious to me as a newbie until Peter Stuge 
clued me in.

But, you do not appear to be having that particular problem.

Use FILO as your payload.    Depending on your gcc version, you may have 
a problem with the defined configuration for FILO under a Coreboot ROM 
build.   gcc issues can be hacked around fairly easily in the 
Makefile.inc setups.  Note that either of 2 versions of FILO will be 
offered in the coreboot menu.  Neither one is guaranteed free of gcc 
issues.   But, the rest of FILO configuration will be pre-defined.     
This is a bit over-cooked.    It can be hacked around easily.   But 
don't.   Just go vanilla.

I suggest you avoid multiboot until you get Linux kernels and initial 
ram disk images to load using FILO.   Using FILO will make it easier for 
you to work around kernel compression issues, such as the one you appear 
to have.  (But I am guessing since I don't have experience with 
multiboot set-up and I am not completely clear what you are attempting 
to boot.)

Once you get the "filo>" prompt on your guest (Qemu) console, you are 
ready to diagnose problems with your disk.img  (the "hda" disk image 
that filo will use).   You will need to understand Grub syntax here.   
Root device is hda.

Tutorial says you need to umount this hda image from the loop mount on 
/mnt/rootfs before calling Qemu.   Not so.   Just make sure you do a 
"sync" before  running Qemu.   Also, you really don't have to mount this 
image in the root of your host filesystem as shown (/mnt/rootfs).    A 
mount point local to your Coeboot/Qemu project on host machine may be 
more appropriate.

For FILO, you can set up a menu.lst for a selection of OS boots as you 
would do using Grub in your host environment.   You will boot-up kernels 
and, likely, initial ram disk images as appears on this disk image, 
depending on your selection from FILO menu selection list. This works 
nicely with either VGA console or -nographic.

Note that example screen for the Tutorial shows FILO loading a Linux 
kernel image and an initrd for the kernel to use.     Last line on this 
screen says "Jumping to entry point...".    That is a far into Linux as 
you are likely to get using this tutorial.  You might not get any 
further than that because the kernel you are told to use is one stolen 
from your host Linux.   Different distros will boot the same Linux 
kernel differently using kernel customizations.  Your kernel may not 
like running in the Qemu guest machine due to hardware naming 
mis-matches.   It will probably die trying to mount a physical disk that 
is unknown to Qemu.    This is not a Coreboot issue, of course.  Once, 
you are "Jumping" bios is done (more or less).    Its a kernel issue. 
but the Coreboot Tutorial would be much easier to use if the kernel 
loading mechanism was clearer.

Getting a Linux kernel to run under Qemu was left outside the scope of 
the Tutorial   I am on a personal side-track of using "dracut" to get 
kernel and init ram disk images that can adapt to the hardware it finds 
itself being booted into.   Again, this is well outside the scope of 
coreboot, but may be useful when you re-target to new hardware using 
Qemu.  Nice if you mainboard selections under Coreboot were all you you 
needed to work-out for a hardware port, i.e., if there were a dracut 
integration.    If your bios builds are strictly for qemu or strictly 
for your host hardware, then you may not want to delve into dracut.    
Qemu comes with kernel.   So does your host Linux.   On the other hand, 
dracut testing code is all about running Linux kernel under qemu under a 
variety of hardware constraints.  Dracut testing uses the default qemu 
bios.   However, using coreboot bios instead of the qemu bios should 
work and is an interesting exercise in itself.   If coreboot bios does 
work for full dracut testing, that might suggest a coreboot rom bios 
problem.

Good luck.

      -- Dan Connelly








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20120728/b9dadd1e/attachment.html>