<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Start with "QEMU Build Tutorial"
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://www.coreboot.org/QEMU_Build_Tutorial">http://www.coreboot.org/QEMU_Build_Tutorial</a><br>
<br>
Unfortunately, that write up is sketchy and certainly not
newbie-proof.<br>
<br>
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. <br>
<br>
But, you do not appear to be having that particular problem.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Good luck.<br>
<blockquote> -- Dan Connelly<br>
</blockquote>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>