KMoore4318

 
I do hope someone from EVGA actualy reads this thread, I can respect that the X58 is quickley becomeing EOL, and that your attention needs to go to the boards that will soon become your money maker. ( I under stand the need for you to shake your money maker ), But please do not ever forget it's your loyal fan base, that is your future customers, it takes ten times the money to attract a new customer than it does to keep an old one. and most of us are satisfied just knowing what is happening and an estimate of when. It feels good to be in the loop. I'm not saying divulge any trade secrets, or violate any Non disclosure agrements, just keep us updated, and remind us that we are relavent. and our wishes respected. If it is truley impossible, many of us will accept that, but will feel slited, if we are told it's not possible, and then see other companies do it. actualy it's your fault, But I have come to expect the impossible from EVGA, based on past performance.

Alucard666

dejanh

Sick today so I had time to play with the option ROM a bit further and I have narrowed it down a bit...

I took the last 64K RAID option ROM version 8.5.0.1030 and modified it to be length of 84K by padding with FFh at the end (no impact on functionality), same as new ROM but left the 3rd byte as 80h (128 in decimal system) to indicate that the length of the ROM is still 64K ((128 * 512) / 1024).  Made sure that the checksum is 00h so that the option ROM is still valid, replaced it in the BIOS, flashed and everything worked fine.  So this is an 84K option ROM now working fine in the existing BIOS but keep in mind that the 3rd byte is still indicating that the ROM is 64K in size, so only first 64K of code are loaded.

Next I decided to try something else.  I took the same working option ROM and changed the 3rd byte to A9h, basically to indicate that this is now an 84K option ROM and that 84K of code should be loaded.  I ensured the checksum is still 00h by padding a few additional FFh bytes, saved, and flashed the option ROM.  It failed to boot the RAID ROM when it needed to address first 84K instead of 64K.

So, what does this say...well, it says that the code will load both from a 64K ROM or an 84K ROM.  The newer ROM fails because it is trying to address more than 64K of code regardless of what that code is, which I am now more convinced than ever is a current BIOS limitation and should be fixable.  Maybe EVGA needs a newer Phoenix-Award BIOS, I am not sure, but clearly this barrier can be overcome as Gigabyte has done it successfully on a Phoenix-Award BIOS. 

Just some food for thought.

Sounds like you're making some great progress.... can't wait to see the next BIOS release :-D

dejanh

Yep...I just hope my BIOS chip comes quick so that I can start playing with the AHCI ROM.

dejanh

sromerod

Hi dejanh

What is the latest version of AHCI ROM?

Phoenix latest version is the one we already have...however, Intel has much newer AHCI ROM from a couple months back that I will try to integrate as soon as my backup chip is here

dejanh

smoothie
Thanks for the hard work Dejanh, I have the new drivers 10.xxx but haven't seen much improvement. This is probably due to the bios not having a matching driver.

You're welcome

It is all dependent on the configuration you have of course, but for people that run RAID and especially SSD RAID combinations the newer the ROM the better.  Most of us are running very new drivers with very old ROMs so not only do we not have the optimal combination, but we are likely missing features as well.  The ROM upgrade barrier to be broken is important too as there is a chance that future RAID ROMs may support TRIM or TRIM like commands which is not something that is supported today but would be much welcome.  No matter how you look at it, it's important to be able to run newer ROMs, whether its stability, feature set, performance, etc.

dejanh

Coldblackice
So I've read through the thread and it's apparent that the mismatch of Intel's BIOS driver to OS driver isn't 'good'.

Anyone have specifics of what happens? Is there anything documented/reported from this mismatch, or is it just an overall sense that things won't go as well as they could/should?

Wondering if an SSD upgrade would run as well with this mismatch...

This is not quite true...you can have a mismatch and running the newer drivers is generally better with SSDs, but you will certainly not benefit from the newest driver as much as you would if you had matching hardware to go with it...since our hardware is so "outdated" you will not get much in the way of improvements from newer drivers most likely.  Once the ROM is updated to bring it into the current era from stone age all will be good, but alas, we continue to wait

ezetsnd

dejanh

Coldblackice
So I've read through the thread and it's apparent that the mismatch of Intel's BIOS driver to OS driver isn't 'good'.

Anyone have specifics of what happens? Is there anything documented/reported from this mismatch, or is it just an overall sense that things won't go as well as they could/should?

Wondering if an SSD upgrade would run as well with this mismatch...

This is not quite true...you can have a mismatch and running the newer drivers is generally better with SSDs, but you will certainly not benefit from the newest driver as much as you would if you had matching hardware to go with it...since our hardware is so "outdated" you will not get much in the way of improvements from newer drivers most likely.  Once the ROM is updated to bring it into the current era from stone age all will be good, but alas, we continue to wait

Do you think that having the older OROM and installing the newest Intel RST drivers would cause the PC to get stuck at the loading screen? I had that problem with the old 8.0 OROM and 10.1 RST drivers. When I went back to the old RST drivers, I could load to windows just fine. I have been worried about trying RST 10.1 again for fear I will have to reload my windows image even though now I have the 8.5 OROM. I may play it safe and wait to see if we can get another BIOS before attempting that again.

fq360
dejanh i have a question for you since bios version s22z i think it is the cpu code was updated to support 6 core, however the native speedstep was changed along with hpet, would it be possible to incorporate this again in the latest bios along with the new cpu microcode for hexacore, im aware we have hpet support now but in the bios but this doesnt work with other OS's i wont mention which but is it possible to do?