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