Not really. The Option ROM modules are somehow the "Firmware" of the related Controllers. They are loaded once (while booting), but the features (and the bugs) they got implemented by the Controller manufacturer will be present all the time until you power-off your computer.
I did had some doubts about it. Anyway, it is older and for tablets only. It was extracted from an Acer Iconia W510.
Found a new AMD GOP 1.55.0.0.0 in some VBIOS, like the ones from Station-Drivers. Here are some observations:
- up until GOP 1.52.0.0.0 (or even 1.50.0.15.36), the GOP was customized for every board, by inserting a dummy OROM for the corresponding GPU.
- with GOP 1.52.0.0.0 there is a universal GOP in main BIOS, but the GPU still has a customized GOP with OROM inserted.
- starting with GOP 1.53.0.0.0, the GOP is universal and the same in main BIOS and GPU. Just that the one in GPU is signed.
I have attached a pack for you to check this on yourself. It contains:
- AtiFlash.exe, atidgllk.sys, atikia64.sys, atillk64.sys are taken from official ATIFlash 2.6.7 package. Just the basic for info display. NOT for flashing!!!
- atiflash-info.bat is for displaying the info about an AMD VBIOS file. Just drop the AMD VBIOS on this bat.
- nvflash.exe, nvflsh32.sys, nvflsh64.sys are the official NVflash 5.196 package.
- nvflash-info.bat is for displaying the info about an Nvidia VBIOS file. Just drop the Nvidia VBIOS on this bat.
- UEFIRomExtract.exe, UEFIRomExtract.bat are for decompressing the EFI stored in second image of AMD/Nvidia VBIOS. Just drop the AMD/Nvidia VBIOS on this bat.
UEFIRomExtract.py is not really needed, but added for two reasons:
a) UEFIRomExtract expects that OROM header starts at 0x00 offset, which is not the case for Nvidia VBIOS, which has an IFR header. This script creates a temp file with IFR header removed, UEFIRomExtract is happy. The original file is left untouched.
b) extracts the EFI image in compressed format, to be used for patching a VBIOS for GOP support. For once, AMD has done it easier for the user, you just take the latest compressed GOP from another VBIOS, patch the ID and add/replace the second image. Last part is to switch the "last image indicator" byte and fix checksum in the first image only. Nvidia is a little bit tricky, because you need a compatible board. The rest is the same - with taking the latest compressed GOP from another VBIOS, patch the ID, add/replace the second image, switch the "last image indicator" byte - but fix checksum in both images. It seems there are GOP variants for GT21X, GF10X, GF119, GK1XX, GM1xx, GM2xx.
Note: [vbios_name]_dump.efi is the decompressed image provided by UEFIRomExtract.exe, while [vbios_name]_compr.efirom is the compressed EFI image extracted by UEFIRomExtract.py script.
UefiOromInfo.rar (736 KB)
AMD GOP 1.55.0.0.0 signed.rar (51.3 KB)
Ok. So do you recommend I just update the RAID, GOP, AND LAN PXE OROMs even though I won’t use them in Windows just to be sure that there won’t be any bugs of any sort? They are all disabled in my BIOS anyway, so I’m not sure. RAID is disabled (AHCI enabled), GOP disabled (onboard GPU disabled), and LAN PXE disabled (LAN boot disabled).
EDIT by Fernando: Post size shrinked by deleting unneeded quoted text and blank lines
@kevindd992002 :
You can update the “Firmware” of on-board Controllers, which have been disabled in the BIOS, but it doesn’t make any sense as long as they are not in use.
Ok, I guess I’ll just leave them as it is. Thanks!
Hello everyone!
I use a MSI 970A-G43 (MS-7693) motherboard, which have an NEC/Renesas µPD720202. In "Device Manager" it shows "Firmware Version: 2018". On the internet I found version 2.0.2.4 (or 2024).
Is there any posibility to update the onboard USB 3.0 Option ROM in the near future? Thanks in advance.
Best regards,
Daniel Ciuperca
@ danielciuperca:
Hello Daniel, welcome at Win-RAID Forum!
According to my knowledge there are only Firmware packages (with installer) and no Option ROM modules available for USB 3.0 Controllers.
You can download the latest Firmware version 2.0.2.4 for your Resenas USB 3.0 Controller µPD720202 from >here<.
Happy New Year!
Fernando
I used v1.9 RC2 a few days ago to upgrade all the ROMs and microcode of the my board’s (ASUS P8Z68-V/GEN3) BIOS and flashed it over. Will using the new v1.9 have any changes if I modify the BIOS again? Or will it do the exact same thing?
I noticed that in the changelogs, it says “altered the procedure for updating microcode files” so I was wondering if v1.9 final does something that the v1.9 RC2 doesn’t.
Probably not for you and your current mainboard BIOS, because the final version of UBU 1.9.0 doesn’t contain any new or updated Option ROM modules.
Changing the method doesn’t automaticly mean, that the results will be changed as well.
@Fernando
Ok. But how can we know for sure what procedures in updating the microcode files were "altered"?
Did you get new microcode in your BIOS (with whatever “method”)? If yes, you have nothing to worry about. You don’t need to reflash anything.
This question can only be answered by SoniX.
Lost in Translation. I would like to say that the redesigned update procedure.
Happy New Year!
Happiness, love, health and prosperity!
@plutomaniac :
For the IB microcode, yes.
@Sonix:
Sorry, I’m not sure what you meant by your last post? How was the update procedure redesigned? Does it do something differently from 1.9 RC2 that warrants another BIOS modification for me?
Differences in microcode update between RC2 and the final version is not present.
Laying out the final version I have overall changes for the whole test version 1.9.0.
Differences in microcode update between RC2 and the final version is not present.
Laying out the final version I have overall changes for the whole test version 1.9.0.
So that means the modified BIOS result from 1.9 RC2 and 1.9 are exactly the same, right?
That’s what I meant above. No matter what changes were made to the method/procedure that UBU uses to update cpu microcodes, if your’s are up to date you do not have to do anything more. It has to do with the fact of whether they are updated and not with what method that was done with. You could have easily used MMTool manually to update them, doesn’t matter. Either way, your SB microcodes were already updated from OEM and the IVB ones do not matter for your SB processor.
Ok, thanks for the clarification. I knew that the SB microcodes are updated by I just thought why not update all options in UBU if I wanted to, there’s no loss in doing it anyway.