On 2015-03-25 16:26, Laszlo Ersek wrote: > On 03/25/15 16:56, Gordan Bobic wrote: >> On 2015-03-25 15:25, Laszlo Ersek wrote: >>> On 03/25/15 11:12, Gordan Bobic wrote: >>>> Hi, >>>> >>>> I'm trying to solve what should be a relatively simple problem >>>> of side-loading a GPU VBIOS but I am running into an unexpected >>>> problem. >>>> >>>> The setup is a laptop with Optimus setup (Intel primary + Nvidia >>>> headless), and I want to pass the headless Nvidia GPU to the KVM >>>> virtual machine. Unfortunately, the GPU appears to be >>>> uninitialized in the VM, judging by the GPU-Z symptoms. >>>> >>>> The VBIOS in question isn't on an EEPROM attached to the GPU, it >>>> is instead in the main system BIOS payload (which actually contains >>>> 3 Nvidia BIOS-es, presumably for different compatible GPUs). I >>>> extracted all the BIOS blobs using PhoenixTool and deduced the >>>> correct one, but the blob in question appears to have the EFI >>>> header missing - which means it looks much like a legacy BIOS, >>>> rather than an EFI one (type 0 header is there, but type 3 >>>> header is not. But the crypto certs are in fact there in the >>>> BIOS payload, which indicates it is an EFI BIOS after all, >>>> only with the type 3 header stripped out. >>> >>> You can use the EfiRom utility from the edk2 git tree, with the >>> "--dump" >>> option, to "Dump the headers of an existing option ROM image". >> >> I tried that but it doesn't produce anything useful on the Insyde >> UEFI ROM image - just tens of thousands of the following until >> I Ctrl-C it: >> >> >> Image 57024 -- Offset 0x0 >> ROM header contents >> Signature 0x5A4D >> PCIR offset 0x0000 >> Signature MZ >> Vendor ID 0x0000 >> Device ID 0x0000 >> Length 0x0000 >> Revision 0x0000 >> DeviceListOffset 0x00 >> Class Code 0x000000 >> Image size 0x0 >> Code revision: 0x0000 >> MaxRuntimeImageLength 0x00 >> ConfigUtilityCodeHeaderOffset 0x00 >> DMTFCLPEntryPointOffset 0x00 >> Indicator 0x00 >> Code type 0x00 > > I think this might be exactly what you need, a "bare" UEFI executable. > I > think EfiRom might mis-recognize (or just assume) that the file being > dumped is an oprom; it is mis-interpreting parts of the bare UEFI > executable as fields of the ROM header. > > How did you get this image? Again, I guess this should be exactly what > you need for building into OVMF / loading from the UEFI shell.
I extracted it from the system BIOS dump using PhoenixTool. >>> I don't know of any utility offhand that extracts images from >>> expansion >>> ROMs (splitting off the expansion ROM header and the PCI Data >>> Structure >>> etc). >> >> If I run it on just the VBIOS image I extracted using PhoenixTool, >> I get this: >> $ EfiRom -d GTX860M.rom >> Image 1 -- Offset 0x0 >> ROM header contents >> Signature 0xAA55 >> PCIR offset 0x0190 >> Signature PCIR >> Vendor ID 0x10DE >> Device ID 0x1392 >> Length 0x001C >> Revision 0x0003 >> DeviceListOffset 0x30 >> Class Code 0x030200 >> Image size 0x19600 >> Code revision: 0x0001 >> MaxRuntimeImageLength 0x80 >> ConfigUtilityCodeHeaderOffset 0x00 >> DMTFCLPEntryPointOffset 0x00 >> Indicator 0x80 (last image) >> Code type 0x00 >> >> I also got a rom-parser utility from here: >> https://github.com/awilliam/rom-parser >> and that reports the following: >> >> $ rom-parser GTX860M.rom >> Valid ROM signature found @0h, PCIR offset 190h >> PCIR: type 0, vendor: 10de, device: 1392, class: 030200 >> PCIR: revision 3, vendor revision: 1 >> Last image >> >> But my understanding is that type 0 means legacy BIOS, and type 3 >> means UEFI. > > Right. The above seems to be a legacy (BIOS) oprom. Can that be loaded/used by UEFI? >> So at a glance it doesn't look like I can side-load this >> image to OVMF. >> >>>> Is the EFI header as described (usually 1KB on Nvidia Kepler >>>> BIOS-es and 1.5KB on Nvidia Maxwell BIOS-es) only applicable >>>> to discrete EFI BIOS-es? Is it handled differently if the >>>> GPU BIOS is integrated into the main system BIOS payload? >>> >>> Normally the UEFI driver is built as a UEFI executable. The EfiRom >>> utility (or another equivalent tool) is used to build it (possibly >>> together with other such executables) into an expansion ROM. This >>> procedure formats the "PCI Data Structure" and "PCI Expansion ROM >>> Header" structs into the output file, as specified in the "PCI (TM) >>> Firmware Specification Revision 3.1". >>> >>>> If so, is there a method for incorporating the GPU firmware >>>> I have extracted into the OVMF core instead of side-loading >>>> it? >>> >>> Yes, there is. (Well, assuming that whatever you extracted is indeed >>> a >>> UEFI binary.) >> >> How can I verify that? > > No clue -- maybe try loading each with both "load" and "loadpcirom" in > the UEFI shell, and see which succeeds. FS0:\> loadpcirom GTX860M.rom Image 'FS0:\GTX860M.rom' load result: Not Found FS0:\> load GTX860M.rom Image 'FS0:\GTX860M.rom' is not an image. So neither seems to have worked. >>> Method #1 is to place the binary somewhere appropriate in the edk2 >>> tree, >>> write an INF file for it, include the INF file in >>> "OvmfPkg/OvmfPkgX64.fdf", and rebuild OVMF. Since this is going to be >>> a >>> binary-only module, you can refer to the following examples: >>> - FatBinPkg/EnhancedFatDxe/Fat.inf >>> - EdkShellBinPkg/FullShell/FullShell.inf >>> >>> Method #2 is similar, except you don't need to write an INF file. >>> Search >>> the same FDF file for "Intel3.5/EFIX64/E3507X2.EFI". >>> >>> Method #3 is to prepare a disk image with a FAT32 partition. Then >>> copy >>> the extracted binary to this filesystem, using mtools or guestfish. >>> During OVMF boot, enter the UEFI shell, and load the driver binary >>> with >>> the "load" command from this filesystem. (This should also connect >>> the >>> driver to matching devices at once.) >>> >>> Hm, I'm just noticing method #4: the UEFI shell has a command called >>> "loadpcirom", which "Loads a UEFI driver from a file in the format of >>> a >>> PCI Option ROM". >> >> That seems like the easiest first thing to try, so I'll start with >> that. >> Unfortunately: >> EfiRom -o GTX860M.efi -b GTX860M.rom >> >> only copies GTX860M.rom to GTX860M.efi >> >> What am I doing wrong? > > Hm, I think you may have misunderstood. I only recommended EfiRom for > dumping images. "EfiRom -o" is only needed if you want to prepare a PCI > expansion ROM (to be passed with -device ...,romfile=...) from > individual binaries. Right, I see. > You can indeed combine images with different Code Types (eg. legacy > bios, and UEFI) into a single expansion ROM (and then the given > firmware > should pick the matching image), but this is only necessary if you want > to *create* an expansion ROM, because you already have the input > binaries. > > I don't know what you have. If you have a UEFI driver binary, you can > load that with "load"; if you have a complete expansion ROM, you could > try to load that with "loadpcirom". If you don't know what you have, > try > each variation, I guess. It seems what I have is closer to a complete expansion ROM, but it doesn't appear to get loaded successfully. But loadpcirom command takes a few seconds to return to the prompt which implies it is doing something. Gordan ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
