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]
Sent: Thursday, August 07, 2014 5:31 AM
To: edk2-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto:rame...@ami.com>]
Sent: Wednesday, August 06, 2014 7:19 AM
To: edk2-devel@lists.sourceforge.net<mailto: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]
Sent: 06 August 2014 11:33
To: edk2-devel@lists.sourceforge.net<mailto: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<mailto: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<mailto: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<mailto: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
