Of all the gin joints in all the towns in all the world, Laszlo Ersek had to
walk into mine at 16:56:36 on Thursday 15 January 2015 and say:
> On 01/16/15 00:05, Bill Paul wrote:
> > I just today did a fresh svn checkout of the EDK2 sources and built a
> > new set of OVMF binaries. This was mainly because my existing binaries
> > didn't include support for the QEMU Q35 machine type, and I found myself
> > needing to do some experimenting with it.
> >
> > A little background: what I'm testing is the UEFI boot loader for
> > VxWorks. The loader supports booting either from disk or using the PXE.
> > It basically just loads a VxWorks image into memory and then runs it.
> > When you use PXE, the loader will obtain the VxWorks image via PXE as
> > well.
> >
> > I'm running FreeBSD/amd64 9.1, and I compiled QEMU 2.2.0 direct from
> > source. It builds pretty much out of the box. I did the OVMF build just
> > a little while ago.
> >
> > I'm running QEMU like this:
> >
> > qemu-system-x86_64 -device e1000,netdev=net0,mac=00:00:e8:01:02:03
> > -netdev tap,id=net0 -bios x64/bios.bin -serial stdio -cpu Nehalem -m
> > 4096 -machine q35 -usb -drive id=blah,file=fat:rw:cdrive,if=none -device
> > usb-storage,drive=blah
>
> Please don't use -bios, use -pflash with a writeable copy.
I am aware of the -pflash option. I didn't happen to use it for this
particular command that I cut and pasted into the e-mail.
> > OVMF boots up and runs fine (both 32-bit and 64-bit builds). I tell the
> > OVMF boot manager to change the boot order so that it boots from network
> > first, and it does indeed try to boot from the network.
> >
> > The problem is that when it boots, it seems to execute the iPXE option
> > ROM code:
> >
> > iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org
> >
> > Features: HTTP DNS TFTP EFI Menu
> >
> > net0: 00:00:e8:01:02:03 using 82540em on PCI00:02.0 (open)
> >
> > [Link:up, TX:0 TXE:0 RX:4 RXE:0]
> >
> > Configuring (net0 00:00:e8:01:02:03)...
> >
> > iPXE successfully transfers the BOOTxxx.EFI image from the TFTP server
> > and runs it. However once it does, PxeBaseCodeProtocol is unavailable.
> > The loader tries to get a PxeBaseCodeProtocol using BS->HandleProtocol()
> > in the LoadedImageProtocol handle from the loaded image.
> >
> > When this fails, the boot loader fails over to SimpleFileSystemProtocol
> > instead.
> >
> > This behavior is different that what I was expecting. Previously when I
> > used PXE with OVMF, it would just print some dots on the screen while
> > doing its PXE boot thing. Then when it completed, I could bind to
> > PxeBaseCodeProtocol in the loader and obtain the VxWorks image from the
> > same source as the loader executable. That doesn't work here: I can boot
> > the loader, but the loader can't get to the network to find VxWorks.
> >
> > The difference seems to be be in the efi-e1000.rom option ROM image. If
> > I use the option ROM from QEMU 1.7.0, then everything works as I expect.
> >
> > My questions are:
> >
> > - Is this new behavior expected?
> >
> > - Is there some trick I need to do to be able to use PxeBaseCodeProtocol
> > in this scenario?
> >
> > - Why did things change suddenly?
> >
> > I can continue to use the older efi-e1000.rom, but I'd like to
> > understand what's going on.
>
> - In general, please read the "Network Support" section in the README.
>
> - OVMF contains a builtin driver (as in, part of the firmware) for the
> virtio-net NIC. Open source of course.
I need to simulate the Intel PRO/1000 NIC for VxWorks though. (It works quite
well.)
> - OVMF can also contain a builtin driver (as in, part of the firmware)
> for the e1000 NIC, *if* you're willing to download the binary only,
> proprietary driver from Intel's website somewhere, run the
> self-extracting binary on a windows machine (I'm not kidding),
Oh I believe you.
> and then
> copy the extracted files into the edk2 tree:
>
> Intel3.5/EFIX64/E3507X2.EFI
> Intel3.5/EFI32/E3507E2.EFI
>
> Plus you have to pass -D E1000_ENABLE to the build command.
>
> These drivers provide SimpleNetworkProtocol implementations, on which
> the edk2 network stack (built into OVMF) sits.
Okay, good to know.
> - If your (emulated or passthru physical) NIC contains a UEFI PCI OpRom,
> then that driver (also providing SNP) will take priority over the
> builtin driver that matches the NIC. This can be changed (the Driver
> Override stuff from the UEFI spec is frequently quoted on the list), but
> it's hairy.
Okay, also good to know. (I think...)
> - If your NIC provides a legacy-only OpRom, or provides no OpRom, or
> provides a UEFI OpRom that is not correctly signed but you are in Secure
> Boot mode and have set the PcdOptionRomImageVerificationPolicy PCD to
> 0x04 (which is the default in the OVMF DSC files), then the OpRom will
> not be used, and the driver stack will fall back to the builtin driver(s).
>
> - Qemu used to bundle legacy-only OpRoms for the NICs it emulates from
> the iPXE project. The iPXE project provides SNP abstractions for more
> than the above two NICs. However, those drivers tend to cause surprises.
>
> - At some point (use git-log) Qemu started to ship combined OpRoms
> (prepared with edk2's EfiRom utility). These oproms contain a legacy
> BIOS binary and a UEFI binary. This change isn't really sudden or recent.
No, _that_ particular change isn't sudden or recent, but that isn't what I'm
asking about either.
- QEMU 1.7.0 and QEMU 2.2.0 include efi-e1000.rom and pxe-e1000.rom
- Obviously, pxe-e1000.rom is just the legacy BIOS PXE option ROM code (though
it's probably built from the same source used to generate efi-e1000.rom)
- I can see that by default the efi-e1000.rom image is used for both PXE and
UEFI boot with QEMU 2.2.0 and it works in both cases (you can force the use of
pxe-e1000.rom with -romfile= if you want to, but I'm not doing that here)
- I can also see that the same is true of the efi-e1000.rom file from QEMU
1.7.0.
However while both QEMU 1.7.0 and QEMU 2.2.0 include efi-e1000.rom, they
include different versions, which exhibit different behavior:
efi-e1000.rom from QEMU 1.7.0:
- Prints no iPXE banner
- OVMF/UEFI firmware displays the usual status dots instead while loading from
the network
- PxeBaseCodeProtocol is available for use once the BOOTxxx.EFI image runs
efi-e1000.rom from QEMU 2.2.0:
- Prints an iPXE banner
- BOOTxxx.EFI image is loaded, but PxeBaseCodeProtocol is not available
Note: I'm not claiming this different behavior started specifically with QEMU
2.2.0. Maybe it started somewhere earlier, but I haven't tried them all to
check.
So, let me ask again: why is it that when I try to PXE boot with the efi-
e1000.rom in QEMU 2.2.0, I a) see the iPXE banner where I didn't used to
before, and more importantly b) PxeBaseCodeProtocol seems to be busted?
I was under the impression that with UEFI, the UEFI portion of a combined
option ROM would just be an UEFI driver for the NIC, i.e. that provides
SimpleNetworkProtocol, and all the other things like PXE and the network stack
were actually part of the UEFI firmware itself and were layered on top of
that. But here it seems like we're just getting an instance of iPXE running
instead. I didn't think that was either desired or possible. (Legacy BIOS PXE
ROMs are self-contained like this because legacy BIOSes don't include any
networking support of their own. I thought UEFI provided all the network
facilities itself and needs only a driver for the underlying interface.)
> - If you want to use the builtin driver despite qemu preloading (by
> default) the iPXE OpRom, use the following option:
>
> -device e1000,netdev=net0,mac=00:00:e8:01:02:03,romfile=
> ^^^^^^^^^
>
> -device virtio-net-pci,netdev=net0,mac=00:00:e8:01:02:03,romfile=
> ^^^^^^^^^
Yes, I discovered that option. That's what I used to temporarily load the efi-
e1000.rom from QEMU 1.7.0. If I use the QEMU 1.7.0 version of efi-e1000.rom
with QEMU 2.2.0, everything works as expected. I just want to understand why
the behavior with 2.2.0 is different. I thought maybe I need to include some
additional code to force the PxeBaseCodeProtocol to load or something.
-Bill
> Hope this helps,
> Laszlo
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
[email protected] | Master of Unix-Fu - Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
