Question relating to EVGA X58 RAID option ROM mod

[dejanh]

Hi there,

I'm at my wits end as to what is the problem that I am running into...it seems that no matter what I do I cannot get the Intel RAID option ROM higher than version 8.5.0.1030 to successfully initialize.

Basic situation is like this. The current latest BIOS from EVGA (found here ftp://ftp.evga.com/bios/E75977.bin) uses a 64K 8.0.0.1038 OROM. Newer OROMs are 84.5K in size. While replacing the 8.0.0.1030 OROM with the last 64K 8.5.0.1030 OROM released by Intel works fine, replacing with the 84.5K 10.1.0.1008 OROM or any other OROM larger than 64K results in the following error once the system tries to initialize RAID.

Internal Error - PnP and PCI compliant BIOS not Present

I am at odds what to do. It clearly seems like some sort of addressing problem, but I cannot get around it as I have no clue where to look or what to do. I noticed that Gigabyte X58 boards using the same Award BIOS are able to update, so it must be a (relatively) simple addressing/offset issue or something along those lines.

Anybody know how to get around this?

I already tried multiple versions of the OROM and as soon as the 64K uncompressed size is exceeded the OROM does not work any more and throws the same error. I also tried changing positions of OROMs with no effect.

For your reference, here is the cbrom output...the BIOS has enough space to acommodate the new larger option ROM. Also, I am not sure what the HOLE entries are actually for...?


******** E75977.bin BIOS component ********

No. Item-Name Original-Size Compressed-Size Original-File-Name
================================================================================
0. System BIOS 20000h(128.00K) 1398Dh(78.39K) 8a79teva.BIN
1. XGROUP CODE 0DF20h(55.78K) 08FD8h(35.96K) awardext.rom
2. ACPI table 09F75h(39.86K) 032A3h(12.66K) ACPITBL.BIN
3. YGROUP ROM 0E100h(56.25K) 07558h(29.34K) awardeyt.rom
4. GROUP ROM[ 0] 08B80h(34.88K) 034A1h(13.16K) _EN_CODE.BIN
5. SETUP0 02320h(8.78K) 00D93h(3.39K) _ITEM.BIN
6. BIOSF0 01910h(6.27K) 01186h(4.38K) _DMI.BIN
7. FLSH CODE 02570h(9.36K) 00E1Dh(3.53K) SPIFLASH.BIN
8. ExtF ROM 01070h(4.11K) 00A22h(2.53K) EXTFGRP.BIN
9. SMI32 00010h(0.02K) 00038h(0.05K) SMI32COD.BIN
10. SMIAP 00440h(1.06K) 002E9h(0.73K) SMIAPCOD.BIN
11. 1 PE32 in MB 2B321h(172.78K) 2B3A8h(172.91K) BIOSINIT.BIN
12. BIOSF2 04C00h(19.00K) 02EEEh(11.73K) AH_P_ROM.BIN
13. GV3 03320h(12.78K) 03347h(12.82K) PPMINIT.BIN
14. PCI ROM[A] 08000h(32.00K) 0458Fh(17.39K) jmb363_1.06.79_raid.bin
15. PCI ROM[B] 10000h(64.00K) 09E44h(39.57K) raid_or_8001038.bin
16. PCI ROM[C] 0C800h(50.00K) 070ECh(28.23K) rtegpxe_d.lom
(SP) NCPUCODE 15400h(85.00K) 15400h(85.00K) NCPUCODE.BIN
(SP) HOLE0 5000h(20.00K) 5000h(20.00K) 8BYPASS.BIN
(SP) HOLE2 2B320h(172.78K) 2B320h(172.78K) BIOSINIT.BIN

Total hole area space = 40000h(256.00K)
Total compress code space = 9D000h(628.00K)
Total compressed code size = 89F36h(551.80K)
Remain compress code space = 130EAh(76.23K)

** Micro Code Information **
Update ID CPUID | Update ID CPUID | Update ID CPUID | Update ID CPUID

------------------+--------------------+--------------------+-------------------
SLOT1 11 000106A5| SLOT1 0A 000106A4 | SLOT1 0F 000106A4 | SLOT1 0D 000106A4

SLOT1 1A 000106A0| SLOT1 0B 000106A1 | SLOT1 19 000106A2 | SLOT1 16 000206C0

SLOT1 06 000206C1| SLOT1 0C 000206C2 |

Any help is appreciated!

[Dansolo]

Just to make sure, what version of CBROM do you use?

[dejanh]

Just to make sure, what version of CBROM do you use?

I've tried several versions from 115 to 32_198, but settled on the 32_198 as it seems to work the best.

I am not sure that the problem is with CBROM. The option ROM loads correctly (or appears to load correctly), however any ROM larger than 64K cannot be initialized successfully and just returns and error. Using any available 64K option ROM works without a hitch wit all tested versions of CBROM.

[Dansolo]

Sorry, not sure. I think you should see if EVGA is willing to help you out.

[dejanh]

Sorry, not sure. I think you should see if EVGA is willing to help you out.

That's unfortunate. Do you have any idea what Gigabyte did to break through this barrier? They can successfully use the newer ROMs but they used to be on the 64K limit as well before.

[Dansolo]

Not sure, but I wonder if this is the same problem that plagues Asus boards. I bet 8.5 would work on them...

[dejanh]

Not sure, but I wonder if this is the same problem that plagues Asus boards. I bet 8.5 would work on them...

It is, it is the exact same problem. And yes, 8.5 does work (I've updated to it some time ago) but it is ancient by every standard not to mention that it has very rudimentary support for SSD drives, especially newer ones, and especially in RAID. It also has a 2TB limit bug for drives in RAID.

[Dansolo]

Now I'm wondering why the code size increased so much in the newer versions and if there's anything we might be able to cut out to get a newer version to be 64KB... While I have a little assembly experience, such an idea might be over my head, unfortunately...

[dejanh]

Now I'm wondering why the code size increased so much in the newer versions and if there's anything we might be able to cut out to get a newer version to be 64KB... While I have a little assembly experience, such an idea might be over my head, unfortunately...

Same here Last time I've done any assembly (and that was very basic assembly too) was 8-9 years ago.

To be honest I had the exact same idea as what you are suggesting, but again, the problem is I have no idea where to start cutting out code. String can always be removed but I really doubt that there are 20K worth of Strings in the code. FFh can also be stripped off the end, but that is only a few bytes, not few kilobytes. Without in-depth knowledge of the module and the ability to see the code nicely in its true form (not disassembled through IDA) it's next to impossible to find out what to remove. To top it off, I think that for it to be a valid option ROM the checksum has to be a very specific value (I cannot recall exactly but it's something silly, like 0).

[Dansolo]

I was thinking about removing some of the display code. I actually do intend to look into it, but I can almost promise you that my skills won't be good enough for anything to come of it.

---

Hmm, can't make much sense of what IDA is telling me, unfortunately.

Now, I wonder, what file in this BIOS is responsible for loading OROMs? Also, does anyone know an AMIBIOS X58 board that does work with one of the newer Matrix RAID OROMs like 9.x/10.x?