]> git.proxmox.com Git - mirror_edk2.git/blobdiff - OvmfPkg/README
UefiCpuPkg/PiSmmCpuDxeSmm: patch "gSmiCr3" with PatchInstructionX86()
[mirror_edk2.git] / OvmfPkg / README
index e6137ddc1f3695f07471d93fe53bb2a8829f43f0..00fb71848200f76fbfc1567d2b481812bf8e775f 100644 (file)
@@ -224,36 +224,52 @@ longer.)
   basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.\r
 \r
 * Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC\r
-  driver (PROEFI) can be embedded in the OVMF image at build time:\r
-\r
-  - Download UEFI drivers for the e1000 NIC\r
-    - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng\r
-    - Install the drivers into a directory called Intel3.5 in your WORKSPACE.\r
+  driver (from the BootUtil distribution) can be embedded in the OVMF image at\r
+  build time:\r
+\r
+  - Download BootUtil:\r
+    - Navigate to\r
+      https://downloadcenter.intel.com/download/19186/Ethernet-Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers\r
+    - Click the download link for "PREBOOT.EXE".\r
+    - Accept the Intel Software License Agreement that appears.\r
+    - Unzip "PREBOOT.EXE" into a separate directory (this works with the\r
+      "unzip" utility on platforms different from Windows as well).\r
+    - Copy the "APPS/EFI/EFIx64/E3522X2.EFI" driver binary to\r
+      "Intel3.5/EFIX64/E3522X2.EFI" in your WORKSPACE.\r
+    - Intel have stopped distributing an IA32 driver binary (which used to\r
+      match the filename pattern "E35??E2.EFI"), thus this method will only\r
+      work for the IA32X64 and X64 builds of OVMF.\r
 \r
   - Include the driver in OVMF during the build:\r
-    - Add "-D E1000_ENABLE -D FD_SIZE_2MB" to your build command,\r
-    - For example: "build -D E1000_ENABLE -D FD_SIZE_2MB".\r
+    - Add "-D E1000_ENABLE" to your build command (only when building\r
+      "OvmfPkg/OvmfPkgIa32X64.dsc" or "OvmfPkg/OvmfPkgX64.dsc").\r
+    - For example: "build -D E1000_ENABLE".\r
 \r
 * When a matching iPXE driver is configured for a NIC as described above, it\r
   takes priority over other drivers that could possibly drive the card too:\r
 \r
-                 | e1000  ne2k_pci  pcnet  rtl8139  virtio-net-pci\r
-    -------------+------------------------------------------------\r
-    iPXE         |   x       x        x       x           x\r
-    VirtioNetDxe |                                        x\r
-    Intel PROEFI |   x\r
+                         | e1000  ne2k_pci  pcnet  rtl8139  virtio-net-pci\r
+    ---------------------+------------------------------------------------\r
+    iPXE                 |   x       x        x       x           x\r
+    VirtioNetDxe         |                                        x\r
+    Intel BootUtil (X64) |   x\r
 \r
 === OVMF Flash Layout ===\r
 \r
-Like all current IA32/X64 system designs, OVMF's firmware\r
-device (rom/flash) appears in QEMU's physical address space\r
-just below 4GB (0x100000000).\r
+Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)\r
+appears in QEMU's physical address space just below 4GB (0x100000000).\r
+\r
+OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the\r
+FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the\r
+1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB\r
+image is 0xffe00000. The base address for the 4MB image is 0xffc00000.\r
 \r
-The layout of the firmware device in memory looks like:\r
+Using the 1MB or 2MB image, the layout of the firmware device in memory looks\r
+like:\r
 \r
 +--------------------------------------- 4GB (0x100000000)\r
 | VTF0 (16-bit reset code) and OVMF SEC\r
-| (SECFV)\r
+| (SECFV, 208KB/0x34000)\r
 +--------------------------------------- varies based on flash size\r
 |\r
 | Compressed main firmware image\r
@@ -271,9 +287,27 @@ The layout of the firmware device in memory looks like:
 | area (56KB/0xe000)\r
 +--------------------------------------- base address\r
 \r
-OVMF supports building a 1MB or a 2MB flash image. The base address for\r
-a 1MB image in QEMU physical memory is 0xfff00000. The base address for\r
-a 2MB image is 0xffe00000.\r
+Using the 4MB image, the layout of the firmware device in memory looks like:\r
+\r
++--------------------------------------- base + 0x400000 (4GB/0x100000000)\r
+| VTF0 (16-bit reset code) and OVMF SEC\r
+| (SECFV, 208KB/0x34000)\r
++--------------------------------------- base + 0x3cc000\r
+|\r
+| Compressed main firmware image\r
+| (FVMAIN_COMPACT, 3360KB/0x348000)\r
+|\r
++--------------------------------------- base + 0x84000\r
+| Fault-tolerant write (FTW)\r
+| Spare blocks (264KB/0x42000)\r
++--------------------------------------- base + 0x42000\r
+| FTW Work block (4KB/0x1000)\r
++--------------------------------------- base + 0x41000\r
+| Event log area (4KB/0x1000)\r
++--------------------------------------- base + 0x40000\r
+| Non-volatile variable storage\r
+| area (256KB/0x40000)\r
++--------------------------------------- base address (0xffc00000)\r
 \r
 The code in SECFV locates FVMAIN_COMPACT, and decompresses the\r
 main firmware (MAINFV) into RAM memory at address 0x800000. The\r
@@ -290,11 +324,11 @@ If you must use UNIXGCC, then you can override the build options for
 particular libraries and modules in the .dsc to re-enable debugging\r
 selectively. For example:\r
   [Components]\r
-  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf {\r
+  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {\r
     <BuildOptions>\r
       GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG\r
   }\r
-  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {\r
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {\r
     <BuildOptions>\r
       GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG\r
   }\r