> On Mar 25, 2015, at 9:26 AM, Laszlo Ersek <[email protected]> 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.
You can hexdump the binary to see if it is a PE/COFF (EFI executable):
MZ -> DOS header signature
PE/0/0 -> PE/COFF header signature
The section entries will also have text names (.text, .data, .reloc, .etc)
>hexdump -n 576 -C CpuIo2Dxe.efi
00000000 4d 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |MZ..............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000080 50 45 00 00 64 86 04 00 00 00 00 00 00 00 00 00 |PE..d...........|
00000090 00 00 00 00 f0 00 0e 03 0b 02 02 38 00 00 00 00 |...........8....|
000000a0 00 00 00 00 00 00 00 00 c9 23 00 00 40 02 00 00 |.........#..@...|
000000b0 00 00 00 00 00 00 00 00 20 00 00 00 20 00 00 00 |........ ... ...|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000d0 80 42 00 00 40 02 00 00 00 00 00 00 0b 00 00 00 |.B..@...........|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000130 40 41 00 00 68 00 00 00 c0 41 00 00 a2 00 00 00 |@A..h....A......|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000180 00 00 00 00 00 00 00 00 2e 74 65 78 74 00 00 00 |.........text...|
00000190 40 3d 00 00 40 02 00 00 40 3d 00 00 40 02 00 00 |@=..@...@=..@...|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 60 |............ ..`|
000001b0 2e 64 61 74 61 00 00 00 c0 01 00 00 80 3f 00 00 |.data........?..|
000001c0 c0 01 00 00 80 3f 00 00 00 00 00 00 00 00 00 00 |.....?..........|
000001d0 00 00 00 00 60 00 00 e0 2e 72 65 6c 6f 63 00 00 |....`....reloc..|
000001e0 68 00 00 00 40 41 00 00 80 00 00 00 40 41 00 00 |h...@A......@A..|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 60 00 00 62 |............`..b|
00000200 2e 64 65 62 75 67 00 00 a2 00 00 00 c0 41 00 00 |.debug.......A..|
00000210 c0 00 00 00 c0 41 00 00 00 00 00 00 00 00 00 00 |.....A..........|
00000220 00 00 00 00 60 00 00 62 00 00 00 00 00 00 00 00 |....`..b........|
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000240
Thanks,
Andrew Fish
------------------------------------------------------------------------------
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
