Thanks a ton Joe. Will keep you updated with the progress.
On 11-Aug-2014 8:15 pm, "Joe Thomas" <joe.tho...@dothill.com> wrote:
> Sushma,
>
>
>
> Sorry – I tried sending offline directly to you. It was not an attachment
> but was part of the mail message.
>
>
>
> Here’s the code:
>
>
>
>
>
>
> //////////////////////////////////////////////////////////////////////////////
>
> //
>
> // mkbios.cpp : Defines the entry point for the console application.
>
> //
>
> //
>
>
> //////////////////////////////////////////////////////////////////////////////
>
>
>
> #include "stdafx.h"
>
> #include <stdio.h>
>
> #include <string.h>
>
>
> //////////////////////////////////////////////////////////////////////////////
>
>
>
>
>
> #ifdef WIN32
>
> #include <windows.h>
>
> #endif
>
>
>
>
> //////////////////////////////////////////////////////////////////////////////
>
> #ifdef WIN32
>
> #define MKB_EOL "\r\n"
>
> #endif // WIN32
>
>
>
> #ifdef __LINUX__
>
> #define MKB_EOL "\n"
>
> #endif
>
>
>
> void
>
> Usage(char **argv)
>
> {
>
> printf("Usage: %s <legacy_bios_name> <uefi_bios_name>
> [<bios_image_name>]\n",
>
> argv[0]);
>
> }
>
>
>
> #define BUFFER_SIZE 512
>
>
>
> int main(int argc, char **argv)
>
> {
>
>
>
> FILE *fLegacy;
>
> FILE *fUefi;
>
> FILE *fOutput;
>
> char Buffer[BUFFER_SIZE];
>
> int Count;
>
> int i;
>
> short int PcirOffset = 0;
>
> int TotalSize = 0;
>
>
>
> if (argc < 3) {
>
> Usage(argv);
>
> return 0;
>
> }
>
>
>
> if ((fLegacy = fopen(argv[1], "rb")) == NULL) {
>
> printf("%s: Unable to open \"%s\" for reading.\n",
>
> argv[0], argv[1]);
>
> return 0;
>
> }
>
>
>
> if ((fUefi = fopen(argv[2], "rb")) == NULL) {
>
> printf("%s: Unable to open \"%s\" for reading.\n",
>
> argv[0], argv[2]);
>
> return 0;
>
> }
>
>
>
> if (argc > 3) {
>
> if ((fOutput = fopen(argv[3], "wb")) == NULL) {
>
> printf("%s: Unable to open \"%s\" for writing.\n",
>
> argv[0], argv[3]);
>
> return 0;
>
> }
>
> } else {
>
> if ((fOutput = fopen("UEFIOROM.bin", "wb")) == NULL) {
>
> printf("%s: Unable to open \"%s\" for writing.\n",
>
> argv[0], "UEFIOROM.bin");
>
> return 0;
>
> }
>
> }
>
>
>
> //
>
> // Handle Legacy BIOS
>
> //
>
>
>
> // Read header
>
> fread(Buffer, BUFFER_SIZE, sizeof(char), fLegacy);
>
>
>
> // Find size in number of sectors. NOTE: Legacy image
>
> // has probably been padded out to 64K so header size
>
> // may not match disk size.
>
> Count = Buffer[2];
>
>
>
> PcirOffset = *((short int *) &Buffer[0x18]);
>
> PcirOffset += 0x15;
>
>
>
> // Adjust checksum in case we clear the Indicator flag
>
> Buffer[0x09] += (Buffer[PcirOffset] & 0x80);
>
>
>
> // Clear Indicator flag to indentify that another image follows
>
> Buffer[PcirOffset] &= ~0x80;
>
>
>
> // Write the modified header to output
>
> fwrite(Buffer, BUFFER_SIZE, sizeof(char), fOutput);
>
> TotalSize += BUFFER_SIZE;
>
>
>
> // Now read and write the remaining data from Legacy BIOS
>
> for (i = 1; i < Count; i++) {
>
> fread(Buffer, BUFFER_SIZE, sizeof(char), fLegacy);
>
> fwrite(Buffer, BUFFER_SIZE, sizeof(char), fOutput);
>
> TotalSize += BUFFER_SIZE;
>
> }
>
>
>
> fclose(fLegacy);
>
>
>
> //
>
> // Handle UEFI BIOS
>
> //
>
>
>
> // Nothing to patch... just read in and write out
>
> fread(Buffer, BUFFER_SIZE, sizeof(char), fUefi);
>
> while (!feof(fUefi)) {
>
> fwrite(Buffer, BUFFER_SIZE, sizeof(char), fOutput);
>
> TotalSize += 512;
>
> fread(Buffer, BUFFER_SIZE, sizeof(char), fUefi);
>
> }
>
>
>
> fclose(fUefi);
>
>
>
> //
>
> // Pad to 1024 boundary for Flash code
>
> //
>
> if ((TotalSize % 1024) != 0) {
>
> memset(Buffer, 0xFF, BUFFER_SIZE);
>
> fwrite(Buffer, BUFFER_SIZE, sizeof(char), fOutput);
>
> }
>
>
>
> fclose(fOutput);
>
>
>
> return 0;
>
>
>
> }
>
>
>
>
>
> // 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]
> *Sent:* Monday, August 11, 2014 5:52 AM
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] making UEFI driver part of optrom
>
>
>
> Hi Joe,
>
>
>
> We could not find the utility used by you as attachment in your earlier
> email.
>
> Can you please share.
>
>
>
> Regards,
>
> Sushma.S
>
>
>
>
>
>
>
>
>
> On Fri, Aug 8, 2014 at 7:59 PM, Joe Thomas <joe.tho...@dothill.com> wrote:
>
> We use the utility I sent… It takes care of everything for us.
>
>
>
> Taking a quick look at EfiRom.c, it doesn’t do what we want for our
> images. It might work for you since it seems to do all the padding, setting
> Image Length, clearing LastImage and appending the EFI image.
>
>
>
> What I’m concerned about is that it potentially adds and extra sector and
> uses the last byte in the padding for a checksum byte. (See
> ProcessBinFile() where it calculates TotalSize and PaddingSize. Since our
> image is already padded out to 0x10000, it will add an extra 512 bytes, 511
> of padding and 1 byte of checksum. The size of the legacy oprom now exceeds
> 64KB and it doesn’t update the checksum where we need it to be.] Also, you
> NEED to have a byte at the end of your legacy oprom for checksum or EfiRom
> might possibly destroy the last byte in your legacy image. [If your legacy
> image is exactly a multiple of 512, EfiRom will copy 1 less byte and the
> write the checksum to the last byte.]
>
>
>
> If your legacy oprom is NOT padded to 64KB, and you have an available byte
> at the end for checksum, and you don’t need any other areas updated, then I
> suspect EfiRom will work.
>
>
>
>
>
> // 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]
> *Sent:* Friday, August 08, 2014 6:48 AM
>
>
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] making UEFI driver part of optrom
>
>
>
> 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
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
