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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
