From: Laszlo Ersek <lersek@redhat.com>
To: david moheban <moheban79@gmail.com>
Cc: edk2-devel@lists.01.org
Subject: Re: HELP: Qemu not able to load Duet image
Date: Thu, 8 Mar 2018 10:48:27 +0100 [thread overview]
Message-ID: <d9381c45-0e0c-cfee-473e-1d6f3f3fd7c8@redhat.com> (raw)
In-Reply-To: <EF86BBCB-782A-41A4-A084-2D8405A0A9AC@gmail.com>
Hello David,
On 03/08/18 02:08, david moheban wrote:
>
> Hi,
>
> I am having difficulty loading Duet image via Qemu x86-64 or Bochs in
> Windows 10-64. Command line I type ‘Qemu -fda floppy.img’ and does
> not get past ‘Welcome to Efi World’ but if I burn the image to a
> flash usb drive it will boot up just fine. Are there any settings or
> drivers that need to be included in the compilation process?
I saw your last query too on the mailing list:
[edk2] How load Duet Floppy.IMG File in Bochs or Quemu?
https://lists.01.org/pipermail/edk2-devel/2018-March/022313.html
I could have followed up there, but I decided not to, because (a) I
didn't want to appear as questioning your use case, and (b) I really
cannot help with the DUET firmware platform of edk2. I assumed what you
really cared about was running DUET on physical machines, and meant to
use QEMU only as a testbed of sorts.
However, seeing how this may be important to you, I can no longer avoid
questioning your use case -- are you perhaps targeting QEMU as your main
platform? Because, in that case, I certainly recommend that you drop
DUET and use OVMF instead.
So what's your ultimate goal here? For example, if you have individual
UEFI_DRIVER modules (not upstreamed to edk2) that you'd like to test on
QEMU first, and then use "for real" on physical machines, you could
build the driver into both OVMF and DUET. For testing, you can use OVMF
on QEMU, and DUET on physical machines with traditional BIOS firmware.
With regard to running OVMF on QEMU, I personally recommend a wrapper
script like the following (this example will launch a UEFI-bootable ISO
image):
ISO=/.../xxxx.iso
CODE=Build/OvmfX64/.../FV/OVMF_CODE.fd
TMPL=Build/OvmfX64/.../FV/OVMF_VARS.fd
DEBUG=ovmf.debug.log
cp $TMPL varstore.fd
qemu-system-x86_64 \
-m 2048 \
-drive if=pflash,format=raw,file=$CODE,readonly \
-drive if=pflash,format=raw,file=varstore.fd \
-drive if=none,format=raw,file=$ISO,readonly,id=cdrom \
-device ide-cd,drive=cdrom,bootindex=0 \
-debugcon file:$DEBUG \
-global isa-debugcon.iobase=0x402 \
-monitor stdio
Laszlo
next prev parent reply other threads:[~2018-03-08 9:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 1:08 HELP: Qemu not able to load Duet image david moheban
2018-03-08 9:48 ` Laszlo Ersek [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-03-11 15:21 david moheban
2018-03-12 16:47 ` Richardson, Brian
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-list 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=d9381c45-0e0c-cfee-473e-1d6f3f3fd7c8@redhat.com \
--to=devel@edk2.groups.io \
/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