Can I ask just a few condensed questions re: BIOS modifications?

Rather than spread multiple questions across multiple threads and create clutter, I hoped it’d be alright if I post a few quick questions regarding BIOS modding. I’m currently modifying my EVGA x58 e767 BIOS to update OROMS + microcode prior to an OS reformat. If we had an IRC channel, I would ask these there instead of posting).


1.) Why are OROMs necessary? Are they merely for pre OS-load usage (in BIOS/UEFI)? Are they essentially just “drivers” for pre-OS environment, and once the OS takes over, the OS uses its own higher-level drivers?

2.) After the OS takes over, what effect/importance does an OROM have at that point? Is OROM functionality even used anymore at that point? My assumption would be that an OROM is unnecessary/redundant once the OS is running, as the OS can use its drivers to interface with the hardware layer now, instead of having a “middle man” OROM to go between.

3.) I see suggestions about using different CBROM versions for even just specific functions/tasks of modding, meaning you might need to use 2-3 CBROM versions just to update one BIOS. How can one know whether this is necessary?

If a person is able to mod their x58 BIOS using just one CBROM version and the computer boots, does that mean everything is perfect? In other words, is it a binary “Good/Success/Perfect” vs. “Bad/Fail/Errored”, or is there a continuous spectrum of “Perfect mod: 100% performance” -> “Mediocre mod: small performance hit” -> "Bad mod: boots, but severely reduce performance"

Basically, if a modded BIOS boots, can one assume that it’s the best outcome/success it could be, even if the ordering of OROM modules were changed, names changed, sizing differences, etc.?

4.) Does the ORDERING of OROM modules in a BIOS matter? CBROM sometimes changes the order of updated/inserted modules, e.g., instead of A->B->C, it becomes A->C->B. Does this matter or have any effect on anything?

5.) Does the NAMING of OROMs matter when replacing an OROM with a newer version? I wouldn’t think so, but may recall someone mentioning it could, perhaps due to hash/checksum differences due to increased/decreased name length in index.

6.) I’ve seen Fernando and others recommend “matching” OROMs with particular driver versions. I get logically why this would make sense. But what could the consequences be for not doing this? What negatives would come from not doing it, or positives from doing it?


Updating CPU microcode:



1.) I’ve seen conflicting info on whether it’s necessary (or useful) to update microcode in the BIOS, since supposedly the OS loads the latest microcode itself after booting (at least with Windows). Is this true? And if so, what’s the point of updating BIOS microcode? (I don’t mind doing it, I’d prefer to even, just curious why)

2.) How can one know whether new (or older) microcode is better or worse? Is there a good benchmark or test to determine this, rather than just a subjective “feeling” of how things are?

3.) Does it matter if microcode is updated after an OS is already fully installed? I realize that the system will work fine and that this probably happens all the time, but similar to the importance in setting RAID vs AHCI upfront ahead of an OS install, or how the OS will adapt itself when seeing that the primary drive is an SSD, I’m wondering if the outcome would look any different between two identical systems, one with microcode fully updated before the OS is installed, and the other gets its microcode updated after the OS has already been installed.



If anyone prefers that I ask these in separate threads, I’m happy to do so, and hope that I haven’t caused concern here!

Fernando may be able to offer you some info on 1-2

3 - Experience, or others comments/knowledge. To the rest of the questions there, in what I’ve seen this only means difference between bricked BIOS, or not, there is no middle ground or performance related things to this discussion.
Some cbrom may do everything fine on a BIOS with a single version, and that is fine. While others may only be able to do certain functions on some BIOS, while failing at other actions, that may be why you see a mix of cbroms used/mentioned on the same BIOS mod
I do that often on some BIOS, and some only need to use a single version, it all depends on the BIOS and what you are doing. Only way to know if/when this may be required (see first comment of this #)

4. This in general doesn’t matter, if you are only talking oroms, and if you are not moving those around above any sensitive modules (MEMINIT, PPMINIT, GV3 - and sometimes others).
This kind of thing (Sensitive modules) mainly affects Gigabyte BIOS due to how they compiled them, but for safety you should always work around this because other BIOS can be affected too

5. Not usually, but if you don’t want to take any chances, use the original name and format. If that was to affect checksums, you’d already have to be correcting for that, due to you are changing the module anyway so checksum would be changed no matter the name.

6. Not matched series = Poor performance, or failed loading… Follow advice you’ve already read on this, sometimes it might be OK, but this info you read is not given without already tested reasoning and user experiences

uCode
1. Up to you, 100%. Unless you have a CPU that doesn’t boot, and older BIOS you want to keep using, then you may be forced to update/add microcode to support your CPU. The OS stuff mainly applies to Win8-10, Win7 or before does not do this.
2. Research, read others comments/experiences, test yourself etc.
3. No, this doesn’t matter, you can do anytime you want.

They are only necessary, if the system boots off the related Controller.
Examples:
a) As long as the on-board SATA Controller is not running in RAID mode, no RAID OROM module will be used by the related system. An update of the RAID OROM module only makes sense for RAID systems.
b) LAN OROM BIOS modules will only be loaded, if the Wake-on-LAN option has been enabled.

Option ROM modules contain the "Firmware" for the related Controller and may have more functions than just to make the system bootable.
Example:
All RAID OROM modules have the additional function as "RAID Utility", where the user can check, create or delete a RAID Array. That is why there is a relationship between the RAID ROM version and the version of the related RAID driver.

Thanks! So just to clarify, when you mention occasions you use multiple CBROMs for one BIOS/UEFI mod, basically you’re seeing multiple “no-boots”, which means you then go back to the drawing board and use a different CBROM for X task/function, and then maybe you see another no-boot, so you go back and use another CBROM for Y task/function, until the machine finally boots all the way, and then that’s a 100% success, no need to worry about “What if CBROM vXYZ could have done that task even more optimally”? Is that the gist of when you’d need to use more than one CBROM?

The only reason I ask is because of concern “What if this particular task/mod might be better or more optimal if it were done with a different version of CBROM?” But if you’re saying that it all comes down to a binary: “It boots… success!” vs. “It doesn’t boot… try a different CBROM”, then that sums it up nicely for me (and thanks!).

Awesome, thanks. I knew overall BIOS filesize checksum would be different, I was just wondering if there was also a checksum done on an index, like a master-file-table for NTFS or "table of contents" for books, only done on filenames and not the files (sizes) themselves.

That makes sense why that would happen, and I don’t ask because I want to go against the advice to match them. Just wanting to better understand the relationship between the two, and the degree. But would this still be the case if one wasn’t using any RAID functionality, only using AHCI? Fernando mentions below that SATA controller OROMs (and apparently I’ve misunderstood this… that it’s actually a “RAID-OROM” only, not a “SATA-Controller-AHCI/RAID-OROM” like I’ve considered it) are only used if there’s a pre-boot function/need, such as RAID. But I may be misunderstanding that point.


They are only necessary, if the system boots off the related Controller.
Examples:
a) As long as the on-board SATA Controller is not running in RAID mode, no RAID OROM module will be used by the related system. An update of the RAID OROM module only makes sense for RAID systems.
b) LAN OROM BIOS modules will only be loaded, if the Wake-on-LAN option has been enabled.

Option ROM modules contain the “Firmware” for the related Controller and may have more functions than just to make the system bootable.
Example:
All RAID OROM modules have the additional function as “RAID Utility”, where the user can check, create or delete a RAID Array. That is why there is a relationship between the RAID ROM version and the version of the related RAID driver.


Very helpful to know, thank you. So just to clarify, if I’m not using RAID nor plan to, …then it doesn’t matter what Intel/SATA controller OROM is inserted into a BIOS? And if that’s the case, purely for theoretical curiosity, what would happen if I overwrote an Intel OROM with nothing but garbage bytes and inserted it into the BIOS… would my machine boot and function just fine, including all SATA AHCI functionality, as if the OROM wasn’t even there? Again, this would be in AHCI mode.

And in case there’d be any pre-boot checks on OROM headers or integrity, let’s say I overwrote only the “body” of the OROM where all the functionality is contained with garbage bytes. So to the BIOS, the OROM would pass its validity/integrity check since the header would look like a valid OROM. Only the body of its functions/functionality would all be garbage bytes. (Again, just for theoretical understanding)

Actually, and correct me if I’m wrong, but I didn’t realize this OROM is actually a “RAID OROM”… I thought it was a “SATA: RAID-or-AHCI” OROM, with both of them relying on functionality within the OROM. Also really helpful to know about the LAN OROM. So basically OROMs are only necessary for anything that requires pre-boot functionality?

So does this mean then that the Intel OROM has functionality that is used even if the system is set to AHCI? If so, what functionality would this be?



Thank you both for sharing your knowledge with this. I’m hopeful I’ll be able to share this better understanding with others like myself going forward!

You’re welcome!

No, I just know/can tell from experience how/when I need to use different CBROM or different version for different things.
99.9% of BIOS I modify I cannot test on my end, and only 0.001% (or less) BIOS I send out is bricked, mainly I can just tell or have already noted from past edits about certain BIOS series in my cbrom folder etc
There really is no “more optimally” here when it comes to editing something with cbrom, only a brick or not, so yes, that is my summary in general about this.

Checksum, yes, there is often MANY in some BIOS (all modules have one, or most etc), in other BIOS only a few checksums (1-3 etc).

I don’t understand your leading RAID/AHCI question, but your second one I can answer. On old BIOS like this, there is usually a RAID rom and a AHCI Rom, separate things. If you are using RAID then RAID+AHCI roms would be used, if you are using only AHCI then only AHCI would be used.
Additionally, if you are not using RAID at all, that could even be removed or FF’d, it wouldn’t matter.

LAN Rom only used if you use Wake on Lan Function, or PXE Boot etc.

Rest of your post confuses me, since there is not an Intel orom as a general thing, or more specifically you are not being specific enough (Intel RAID orom, Intel AHCI orom, Intel PXE/Boot Agent orom etc)

It’s really hard to discuss BIOS this old, and edits in a “general” way, without having the BIOS you are concerned with, so better and more specific information could be given.
Link me to the BIOS you are working with, stock unedited version, and I could possibly give you more specific answers (provided you asked some specific questions )

Indeed. You can even remove it from the BIOS.

Yes, if you meant the Intel RAID OROM module. The only requirement may be, that the checksum-8 of the modded RAID OROM is still 0.

That’d be great if you’re willing to take a look!

https://gofile.io/?c=ncYJmR
https://file.io/joQBpo
https://filebin.net/rxlt274f80yw6kcn/E76…zip?t=90x6hnnd

I’ve wondered if there are any potential settings or mods/abilities that could potentially be unlocked or optimized, though my guess is probably “no”. I have wondered about unlocking the multiplier, which seems to be artificially limited by the motherboard for x5675.

But my primary purpose is just getting the BIOS updated/cleaned/optimized as best as possible in preparation for a Win10 reformat, which I hate doing (so I want to be sure everything is in order so it only needs to happen once).

Indeed. You can even remove it from the BIOS.

Yes, if you meant the Intel RAID OROM module. The only requirement may be, that the checksum-8 of the modded RAID OROM is still 0.


Thanks Fernando!

BIOS mods/edits wont matter to your Win10 install, so you can do that anytime you want
If CPU multi should be unlocked, that may be not happening now due to the microcode in the BIOS, or they’ve not coded something to where it detects that chip same as the unlocked desktop part.
For the latter there, you’ll need to look around in their forums and see if others have asked about that with same/similar unlocked X58 Xeons. If microcode update doesn’t fix it I mean

You may need the “Westmere Mod” which is a hard mod, but since you have lifetime warranty they should still do it for you if you send it to them. But, not sure if you need this or not, I think it’s only needed if you can’t boot at all, but you’ll have to research about that
https://forums.evga.com/EVGA-X58-SLI-132…5-m2404584.aspx

Some boards already have it done, here is the actual mod
https://forums.evga.com/X58-SLI-LE-Rev-1…82.aspx#2595501
Or https://forums.evga.com/tm.aspx?m=2532618&mpage=1

See also, this about cpu multi’s and turbo (unsure if you even need the mod, since it’s running now/already)
https://forums.evga.com/Is-my-x58-E767-l…5-m2839534.aspx
https://forums.evga.com/EVGA-x58-SLI-LE-…s-m2812308.aspx

I can update microcode for you, as well as Realtek LAN Module (only needed if you use WOL or Boot to LAN), and J.Micron module
I can also update RAID Module, current one is 10.5.0.744



Thanks Lost_N_BIOS. To clarify, I’m currently running fine with the Xeon at 4.5GHz. I don’t technically need an increased multiplier, as I probably wouldn’t be able to overclock any higher anyway.

As for the RAID module, isn’t the current one for ICH10R/x58 11.2 or 11.7?

Is the JMicron module only for pre-boot RAID, as well? All I use is AHCI, so I guess OROMs don’t really affect me.

If there are any other standard BIOS mods you know of, I’m curious to know what’s possible. Not a huge deal however.

Yes, that is pretty high already for X58 CPU and the heat they can output
Default Intel RAID Module is 10.5.0.744 (But this is ONLY used if you use RAID)

J.Micron is used pre- and during OS use I believe, but this only needs updated if you actually “Boot” from these ports, which no one should ever do anyway

No, not too much to do here other than what we’ve discussed, BIOS is too old to easily modify settings contents, unless you have flash programmer then we could try with software and see if it bricks or not

@Coldblackice - Microcode update done, if you want to test and see if this helps with the CPU multi issues
If this fails to boot, or fails to help with CPU multi issues, we should also try with 2015 microcodes instead, sometimes 2018 ones cause issues but always best to try those first.

Updated-uCodes.png



http://s000.tinyupload.com/index.php?fil…872853462298918