Hi Joe,
Thanks for detailed explanation. We will verify on all the points mentioned
by you.
How do you place, UEFI ROM image AFTER legacy optrom image.
Did you use EfiRom utility which combines both UEFI ROM and legacy optrom
images.
EfiRom –f <vendorid> -I <deviceid> -o outputfile.rom –ec efidrivername.efi
–b legacyoprom.bin –l <pci class code>
Regards,
Sushma.S
On Thu, Aug 7, 2014 at 5:47 PM, Joe Thomas <joe.tho...@dothill.com> wrote:
> Sushma,
>
>
>
> The problem(s) with ‘cat’ are that 1) It won’t modify the header for the
> legacy oprom, and 2) it assumes that the legacy oprom image is exactly the
> correct number of 512 bytes blocks. ‘cat’ is placing one image after the
> other, but it doesn’t take into account any padding requirements
> (everything needs to be aligned to 512 byte boundaries) or filling that may
> have occurred (i.e. padding unused legacy oprom space to say 64KB as we
> do). As I mentioned in one of the emails, our default legacy rom images are
> always padded out to 64KB even if the image size is less than 64KB. Such in
> image will NOT work when using ‘cat’
>
>
>
> As for the header, it’s not the EFI ROM image you need to worry about,
> it’s any image that comes before it – in this case, the legacy oprom.
>
>
>
> Look through this and see if it helps…
>
>
>
> -Joe
>
>
>
>
>
> I’ve included some dumps from our images to demonstrate: (This happens to
> be for a SAS disk controller…)
>
>
>
> Legacy OPROM before combining – ROM_L.bin – 65536 bytes in length: Can be
> used as is for a standalone legacy oprom. MUST be modified if an oprom
> image is to be placed AFTER this image.
>
>
>
> 1 0x000000: 55 aa 7d e9 50 08 52 43 00 53 26 00 4c 02 91 d5
> *U.}.P.RC.S&.L...*
>
> 2 0x000010: 9c 06 28 10 24 1f c3 0d 1c 00 48 00 50 43 49 52
> *..(.$.....H.PCIR*
>
> 3 0x000020: 28 10 16 00 00 00 18 00 00 00 04 01 7d 00 01 00
> *(...........}...*
>
> 4 0x000030: 00 80 00 00 04 04 51 00 14 08 48 01 6f 01 9e 0b
> *......Q...H.o...*
>
> 5 0x000040: a3 0b a8 0b ad 0b 00 00 24 50 6e 50 01 02 00 00
> *........$PnP....*
>
> 6 0x000050: 00 5f 28 10 16 00 48 01 6f 01 01 04 00 44 14 08
> *._(...H.o....D..*
>
> 7 0x000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *................*
>
>
>
> Decoding --
>
> Offset 0000: Option ROM header
>
> Signature: 55 AA
>
> Option ROM Length:
> 7d ; length in 512 byte “sectors”
>
> Init Vector: e9 50
> 08 ; jmp _init – BIOS calls offset 3 to jump
> to legacy oprom init routine
>
> Application Specific: <offset 06 thru 19>
> ; we store a OPROM checksum at offset 9 – we need to modify our checksum
> if we change the image
>
> Offset to PCIR: 1c
> 00 ; offset 001C
>
>
>
> Offset 001C: PCIR header
>
> Signature: 50 43 49
> 52 ; ASCII ‘PCIR’
>
> Vendor ID: 28 10
>
> Device ID: 16 00
>
> Device List Ptr: 00 00
>
> Struct Length: 18 00
>
> Struct Rev: 00
>
> Class Code: 00 04 01
>
> Image length: 7d
> 00 ; in 512 byte sectors
>
> Vendor rev level: 01 00
>
> Code Type:
> 00 ; 0 = intel x86
>
> Last Image:
> 80 ; this is (currently) marked
> as the last image – this needs to be modified
>
>
>
>
>
> UEFI OPROM before combining – ROM_U.bin – 147456 bytes in length: Can be
> used as a standalone UEFI oprom or can be added, as is, after a legacy
> oprom image.
>
>
>
> 1 0x000000: 55 aa 20 01 f1 0e 00 00 0b 00 64 86 00 00 00 00 *U.
> .......d.....*
>
> 2 0x000010: 00 00 00 00 00 00 34 00 1c 00 00 00 50 43 49 52
> *......4.....PCIR*
>
> 3 0x000020: 28 10 16 00 00 00 18 00 00 00 00 00 20 01 00 00
> *(........... ...*
>
> 4 0x000030: 03 80 00 00 4d 5a 00 00 00 00 00 00 00 00 00 00
> *....MZ..........*
>
> 5 0x000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *................*
>
> 6 0x000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *................*
>
> 7 0x000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *................*
>
>
>
>
>
> If I were to cat the two files together, the UEFI oprom image would start
> at offset 65536 but according to the legacy oprom header, it should start
> at offset 7d * 512, or 64000. Also, unless I change the last image
> indicator, BIOS won’t look past the legacy oprom for the UEFI oprom, even
> if the offsets were correct.
>
>
>
>
>
> Anyways, using the code I sent, we clear the last image indicator for the
> legacy oprom image, patch the checksum byte, and only copy out the 64000
> bytes of the legacy oprom.
>
>
>
> Immediately after that, we copy unchanged, the UEFI oprom image.
>
>
>
>
>
> Here’s the new header on the merged image (first image is legacy oprom) –
> ROM_C.bin – 211968 bytes in length:
>
>
>
> 1 0x000000: 55 aa 7d e9 50 08 52 43 00 d3 26 00 4c 02 91 d5
> *U.}.P.RC..&.L...*
>
> 2 0x000010: 9c 06 28 10 24 1f c3 0d 1c 00 48 00 50 43 49 52
> *..(.$.....H.PCIR*
>
> 3 0x000020: 28 10 16 00 00 00 18 00 00 00 04 01 7d 00 01 00
> *(...........}...*
>
> 4 0x000030: 00 00 00 00 04 04 51 00 14 08 48 01 6f 01 9e 0b
> *......Q...H.o...*
>
> 5 0x000040: a3 0b a8 0b ad 0b 00 00 24 50 6e 50 01 02 00 00
> *........$PnP....*
>
> 6 0x000050: 00 5f 28 10 16 00 48 01 6f 01 01 04 00 44 14 08
> *._(...H.o....D..*
>
> 7 0x000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *................*
>
>
>
> Notice the byte at offset 0x31 (offset 0x15 in the PCIR header) has
> changed from 80 to 00. The is the clearing of the last image indicator.
> BIOS now knows that another image should follow this one.
>
> Also, the byte at offset 0x09, our checksum, changed from 53 to d3.
>
>
>
> If I dmp from offset 64000 (0xFA00 = 0x7d * 0x200), I should, and do, see
> my header for the UEFI oprom image…
>
>
>
> 1 0x00f9e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> *................* ß padding of legacy image to 512 byte boundary
>
> 2 0x00f9f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> *................* ß more padding
>
> 3 0x00fa00: 55 aa 20 01 f1 0e 00 00 0b 00 64 86 00 00 00 00 *U.
> .......d.....* ß 0x7D * 0x200 – offset from start to this image
>
> 4 0x00fa10: 00 00 00 00 00 00 34 00 1c 00 00 00 50 43 49 52
> *......4.....PCIR*
>
> 5 0x00fa20: 28 10 16 00 00 00 18 00 00 00 00 00 20 01 00 00
> *(........... ...*
>
> 6 0x00fa30: 03 80 00 00 4d 5a 00 00 00 00 00 00 00 00 00 00
> *....MZ..........*
>
> 7 0x00fa40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *................*
>
>
>
> As you can see, nothing changed in the UEFI oprom header.
>
>
>
>
>
> I think you can figure out what’s happening if you look at your legacy
> oprom last indicator in the combined image – make sure it’s 00, and then
> look to make sure your UEFI oprom image is at the correct offset – multiply
> the legacy oprom image size (offset 2) by 0x200 (or 512). You should see
> your UEFI oprom header at that offset in your combined image.
>
>
>
>
>
> // Joseph Thomas
>
> // Principal Software Engineer
>
> // Dot Hill Systems
>
> // 2905 NorthWest Blvd., Suite 20
>
> // Plymouth, MN 55441
>
> // 763.226.2640
>
>
>
> *From:* sushma s [mailto:sushma.bharadw...@gmail.com
> <sushma.bharadw...@gmail.com>]
> *Sent:* Thursday, August 07, 2014 5:31 AM
>
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] making UEFI driver part of optrom
>
>
>
> Hi Joe,
>
>
>
> Thanks for your inputs.
>
> We had missed to set"Last Image Indicator" in legacy optrom header as
> zero.
>
> But even with this change, the BIOS doesn't see our driver UEFI ROM image.
>
> We are using win32 tool "CAT" to combine our legacy optrom image and UEFI
> ROM image.
>
>
>
> Instead of using CAT, should we place the images just one below the other?
>
>
>
> I have dumped the ROM header contents using EfiRom utility run against my
> UEFI.rom image. Please have a look at let us know if anything is missed.
>
>
>
> ROM header contents
>
> Signature 0xAA55
>
> PCIR offset 0x001C
>
> Signature PCIR
>
> Vendor ID 0xxxxx
>
> Device ID 0xxxx
>
> Length 0x001C
>
> Revision 0x0003
>
> DeviceListOffset 0x00
>
> Class Code 0x010100
>
> Image size 0x11E00
>
> Code revision: 0x0000
>
> MaxRuntimeImageLength 0x00
>
> ConfigUtilityCodeHeaderOffset 0x00
>
> DMTFCLPEntryPointOffset 0x00
>
> Indicator 0x80 (last image)
>
> Code type 0x03 (EFI image)
>
> EFI ROM header contents
>
> EFI Signature 0x0EF1
>
> Compression Type 0x0001 (compressed)
>
> Machine type 0x0EBC (EBC)
>
> Subsystem 0x000B (EFI boot service driver)
>
> EFI image offset 0x0038 (@0x38)
>
>
>
> Thanks,
>
> Sushma.S
>
>
>
> On Wed, Aug 6, 2014 at 6:01 PM, Joe Thomas <joe.tho...@dothill.com> wrote:
>
> Sushma,
>
>
>
> When you say “We placed this UEFI driver ROM image, below the legacy
> optrom and flashed the same on the PCIe card.”, how exactly did you do this?
>
>
>
> Did you change the headers in the legacy image to indicated that it no
> longer is the last image?
>
>
>
> It’s been several years since I’ve done this so I’m still going back
> trying to find the tools we used but it almost sounds like the PCI Data
> Structure in the legacy ROM wasn’t updated and therefore, the BIOS only
> sees the one image, regardless of what you put after… (There’s a ‘Last
> Image Indicator’ that needs to have bit 7 set to zero in all images except
> the last. In this, case, the legacy image should be zero and the UEFI image
> should be 1 (0x80). The UEFI image then needs to follow the legacy image at
> ‘Image Length’ * 512 bytes.)
>
>
>
> I’ll try to find what we did and forward if I can.
>
>
>
> -Joe
>
>
>
> // Joseph Thomas
>
> // Principal Software Engineer
>
> // Dot Hill Systems
>
> // 2905 NorthWest Blvd., Suite 20
>
> // Plymouth, MN 55441
>
> // 763.226.2640
>
>
>
> *From:* Ramesh R. [mailto:rame...@ami.com]
> *Sent:* Wednesday, August 06, 2014 7:19 AM
>
>
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] making UEFI driver part of optrom
>
>
>
> Hi Sushma,
>
>
>
> It’s depend on the platform BIOS to decide which option rom needs to be
> invoked. May be the BIOS you are having invokes only Legacy option rom if
> it’s exists and doesn’t launch the UEFI option rom.
>
>
>
> I mean to say from the option rom we can’t control which option rom needs
> to be launched. It’s decided by the platform BIOS.
>
>
>
> Thanks,
>
> Ramesh
>
>
>
> *From:* sushma s [mailto:sushma.bharadw...@gmail.com
> <sushma.bharadw...@gmail.com>]
> *Sent:* 06 August 2014 11:33
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] making UEFI driver part of optrom
>
>
>
> Hello,
>
>
>
> As suggested, we placed only uefi.rom in the PCIE optrom, our UEFI driver
> is getting loaded during boot.
>
> But if i keep both the legacy optrom images, and UEFI driver rom image, i
> below the other in the optrom space, my UEFI driver is not getting loaded.
>
>
>
> Any additional changes required to make both images co-exist. Please
> advise.
>
>
>
> Regards,
>
> Sushma.S
>
>
>
> On Mon, Aug 4, 2014 at 11:17 AM, Onipchuk Vladimir <v-onipc...@yandex.ru>
> wrote:
>
>
> >>> We are able to successfully load the UEFI driver ROM using loadpicrom
> UEFI
> >>> shell command.
>
> During loadpcirom command please make sure what "start" function was
> loaded (not just "entrypoint").
>
>
>
> >>> In the PCIE card optrom layout We placed this UEFI driver ROM image,
> below
> >>> the legacy optrom image and flashed the same on the PCIe card.
>
> Try to place only UEFI driver ROM image on the PCIe card.
>
> Thanks,
> Vladimir
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
