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. > > 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. - 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), 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. - 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. - 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. - 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= ^^^^^^^^^ Hope this helps, Laszlo ------------------------------------------------------------------------------ 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
