Update of the Start post
Changelog:
Hi Fernando (and everyone), do you mind clarifying "The function and the compatibility of the āIntel(R) SATA AHCI Controllerā obviously is managed by a ānormalā (non-OROM) BIOS module, which cannot resp. donāt need to be updated."
Iām a bit confused on a couple things, namely: Intel AHCI OROM vs. Intel RAID OROM vs. Phoenix AHCI OROM vs āa ānormalā non-OROM BIOS moduleā.
I have an EVGA x58 / ICH10R. It has an Award/Phoenix BIOS. Iāve heard a few things, and Iām not sure whatās correct:
@Coldblackice :
The following picture shows the BIOS modules of the BIOS named E76783.bin, which is latest one for your EVGA X58 mainboard:
As you can see, there are only 3 Option ROM modules within your BIOS:
Only the option d) is correct and currently valid for your system.
to options a) and b): A "Phoenix AHCI OROM" cannot be used, because such OROM doesnāt exist. Your on-board Intel SATA AHCI Controller neither needs nor uses any OROM BIOS module.
to option c): The Intel RAID OROM BIOS module doesnāt have an AHCI OROM module in it, but the RAID mode supports some AHCI features.
You can give the inserted Option ROM any name, but I do not recommend to do it, if you want to replace a certain Option ROM by another one.
Update of the Start post
Changelog:
Thanks Fernando! So if there is no AHCI module in my BIOS, how is it able to see + interact with drives in BIOS (with AHCI set)? I seem to recall extracting all of the other modules with a particular tool ā perhaps an old old Award tool ā and then when looking through the hex of these, I recall finding a "Phoenix AHCI" orom. But perhaps Iām remembering that incorrectly.
Also, if I donāt have any AHCI OROM in my BIOS, how can the drives end up being used by Windows? Is an OROM not even necessary then? If not, whatās the point of OROMs if Windows (or any operating system) can access the hardware/drive directly without the need of an OROM?
@Coldblackice :
Thanks for your input, which let me look deeper into my archives than before.
Result: You are partly right and my previously given statement was not 100% correct.
There is indeed a Phoenix AHCI module within the BIOS of your X58 chipset mainboard. Its Item-Name is āBIOSF2ā and its Original-File-Name is āAH_P10710_ROM.BINā. This module contains the Phoenix AHCI ROM v01.07.10 dated 12/05/2008, which seems to be the latest available Phoenix AHCI ROM module version. Its code is rather similar to the one I had posted >here< in February 2018.
Nevertheless it is fact, that there is no āAHCI Option ROMā within your mainboard BIOS, because the related Phoenix AHCI module is not listed as āPCI ROM[X]ā.
Interesting point: How is it possible, that you can boot into your OS in AHCI mode using the on-board Intel SATA AHCI Controller, although no discrete AHCI Option ROM has been loaded while booting?
These things are different with newer Intel chipset systems from 5-Series up, because their AMI BIOS contains either an Intel AHCI Option ROM or a Firmware of the on-board Intel SATA AHCI Controller, which doesnāt need such separate Option ROM.
Hi, all!
A long time ago, I flashed the Marvell Controller 88SE9128 on my old EVGA X58 FTW3 motherboard with a firmware found at Station-Drivers.
Since I made this mistake, I have three issues: the device ID is now 9123, I canāt access to the Marvell BIOS by pressing Ctrl+M, and the top of that, the speed of this SATA III controller is stuck at 3Gb/s. 
So, Iād like to know if someone can explain to me how can I inject this ROM: āMarvell 91xx AHCI/RAID ROM v1.0.0.1038 for DEV_9128ā to flash the firmware, please?
Many thanks in advance!
@Mixmatmax :
You will have to customize the DeviceID code of the Marvell 91xx RAID ROM module, to re-modify the BIOS and to reflash the freshly customized BIOS.
The easiest way is to let SoniXās tool named āSetDevIDā do the first part of the job. The currently latest version of that tool is attached.This is the way how to do it:
1. Download and unzip the SetDevID tool.
2. Create a new folder within the root of drive C and give it a specific name (e.g. C:\Test).
3. Copy the desired original Option ROM and the file SetDevID.exe into the just created folder.
4. Run the āCommand Promptā, navigate to the folder and run the following command:
setdevid <devid> <infile> <outfile>
Ā SetDevID.rar (44.2 KB)
Itās done, the outfile is createdā¦ Thanks a lot, Fernando!
Intel RST RAID ROM v17.8.2.4684
Source came with efi raid driver still v17.8.0.4507 though.
RaidOrom_17.8.2.4684.zip (66.6 KB)
Update of the Start post
Changelog:
@Fernando
new: Intel RST RAID ROM & Intel EFI RaidDriver v17.8.3.4687
new: Intel Gigabit UNDI v0.8.05
+ lots of other new file versions !
is in this MB bios file:
https://dlcdnets.asus.com/pub/ASUS/mb/LGā¦G-ASUS-0403.zip
Can you properly extract these files for us to use ?
Thanks,
Biozzz
@biozzz
Actually, they are in all new z490 BIOS files on ASUS support pages.
Not a secret - you can grab all extracted modules from UBU tmp folder when you open BIOS file in UBU tool and havenāt exited yet.
@Fernando
Intel RST RAID ROM v17.8.3.4687
RaidOrom_17.8.3.4687.zip (66.6 KB)
Update of the Start post
Changelog:
Hello everyone! Guys I want to try AHCI 2.00h. My DeviceID 3A 22. Who knows how to fix the checksum, that would be "00".
Yes, please, anyone!! ^^^ If anyone can tell me which byte is the checksum byte to fix, I can correct checksum for him, but Iām just not sure which byte it is anymore since itās been so long since I edited Intel AHCI roms. 
plutomaniac @Sylar76 @MiesMosel @dsanke @chinobino @davidm71 @ket @SoniX @ex58 @hancor
He said Fernando told him itās byte 0x4h, but comparing several different versions of 1.20E, some have same value at 0x4h and all are zero checksum8, so 0x4h canāt be the checksum byte I think and maybe Fernando was not 100% sure?
@Lost_N_BIOS
The easiest way if the location of the checksum byte is unknown.
The last byte in the file is changed, as for example in the OROM SATF Marvell.
@Lost_N_BIOS : @SoniX :
I told him, that it may be the byte at offset 0x04, but I am not sure about it.
The problem is, that the hex codes of the latest officially released Intel AHCI ROM module v1.20E and of the 8086-0000_v2.00h test version are completely different regarding their last bytes.
Both modules are attached.
I do not think that the byte at offset 0x04 is corrective.
There is another suggestion.
To the original files add a block of 512 bytes as 0x00.
Correct the new file size at offset 0x03.
construct the checksum in the last byte at the end of the file.
Edit:
Sorry!
Filesize offset 0x02
Dec / 512 = Dec -> Hex (1 byte)