qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] EFI BIOS on QEMU
Date: Mon, 7 Jan 2008 19:12:25 -0600	[thread overview]
Message-ID: <200801071912.25678.rob@landley.net> (raw)
In-Reply-To: <4782894F.60902@mail.berlios.de>

On Monday 07 January 2008 14:19:27 Stefan Weil wrote:
> Hi,
>
> I just wanted to run QEMU CVS with EFI BIOS:
>
> i386-softmmu/qemu -snapshot -L efi-bios -hda efi-bios/efi.disk
> linux.img  -net nic,model=i82551 -net user
>
> i82551 is part of the E100 emulator (eepro100.c).
>
> It does not work - no output on serial console nor VGA screen.
> Or do I have to press some magic keys to get any response?

You tried ctrl-alt-2 to switch from vga to serial console?  (Wild guess...)

Where did this bios come from?

You are aware that bioses come in 2 stages, and that only the _second_ stage 
applies to something like qemu, right?

The first stage is hardware initialization.  Most importantly, BIOS stage 1 
has to initialize the DRAM controller and start the periodic refresh timer, 
and then wait a bit for it to clock up before the DRAM can store stable 
values.  (The memory starts out holding random garbage, and until the refresh 
timer is working it won't hold on to values you write to it either.)

This sort of early hardware initialization is what the "linux bios" project 
does.  It's extremely system specific stuff that has to have hardwired into 
it exactly where all the devices it's talking to live because it can't do 
things like probe the PCI bus until you know where the PCI bus controller is 
(and have switched it on and booted it up).

This stage doesn't apply to qemu.  QEMU is only emulating hardware, it doesn't 
have things like DRAM refresh hardware, and if you try to play with that sort 
of thing you won't get back the right results because it's not _there_.  (In 
general, running a stage 1 BIOS for one machine on any other machine won't 
work unless the hardware is _identical_.  That's why Linux Bios has 8 
gazillion config options at build time for which board you're building it 
for.)

The second stage of the BIOS provides an API to userspace, called by things 
like bootloaders to load sectors from the boot device into memory.  For the 
x86 and x86-64 targets QEMU uses the bochs bios to provide this interface, 
for bootloaders like grub.  That's already there.

Could you tell us more about what exactly you're trying to do?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

  reply	other threads:[~2008-01-08  1:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06  4:58 [Qemu-devel] EFI BIOS on QEMU Kuniyasu Suzaki
2007-12-06  9:30 ` Tristan Gingold
2007-12-06 15:48   ` Kuniyasu Suzaki
2008-01-07 20:19     ` Stefan Weil
2008-01-08  1:12       ` Rob Landley [this message]
2008-04-26 16:11         ` Stefan Weil
2008-04-26 19:15           ` Rob Landley
2008-04-26 20:32             ` Stefan Weil
2008-01-08 15:07       ` Tristan Gingold
2008-04-26 17:20         ` [Qemu-devel][BUG] EFI BIOS on QEMU stopped working with r3371 Stefan Weil
2008-06-15 15:05           ` [Qemu-devel][BUG] Regression: " Stefan Weil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200801071912.25678.rob@landley.net \
    --to=rob@landley.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).