No, you don’t have such advantages like fast RAID booting etc. As I said, it is just looks (appearance) for 6-series, nothing more.
It shouldn’t, sometimes certain microcodes are "better" for overclocking and UBU mentions which. So use that and everything should be fine.
is there anyway to update AsMedia USB roms or modules?
this would be most helpful as the AsMedia USB seems clunky!
No idea why they haven’t fixed the issues yet!?!?
my specs are in my sig fyi!
del
@ All owners of motherboards based on chipset X79. LGA2011.FFS file size is 172056 bytes, which makes it impossible to correctly update volumes BOOT, because the free space in the data volume is very small.
Therefore, I propose to eliminate unnecessary microcode from this file to reduce its size.
At this point, LGA2011.FFS file contains the following microcode:
SandyBridge-E
06D1 - 106
06D2 - 20C
06D3 - 304
06D5 - 513
06D6 - 619
06D7 - 710
IvyBridge-E
06E0 - 008
06E2 - 20D
06E3 - 308
06E4 - 428
06E6 - 600
06E7 - 70D
I ask everyone to express opinions and suggestions which microcode to delete, and which to leave.
Added:
In future releases, I do disable all microcode update for LGA2011. Leave only the choice SandyBridge-E or IvyBridge-E, so as not to spoil the BIOS.
No, you don’t have such advantages like fast RAID booting etc. As I said, it is just looks (appearance) for 6-series, nothing more.
It shouldn’t, sometimes certain microcodes are "better" for overclocking and UBU mentions which. So use that and everything should be fine.
1.) Oh ok. When you say visual improvements, are you referring to when you enter the BIOS? So when I install Windows in UEFI mode (which I did try already before) I’m not getting any improvements at all other than the fact that you can boot off from 2TB HDD’s?
2.) Ok. And I’m assuming that if I update the CPU microcode using UBU to whichever option it presents there would be virtually no risk in bricking the board, right?
Here’s a pic of before udpating the microcode to the recommended overclocker microcode:
https://www.dropbox.com/s/644a35i88u52oij/before.JPG?dl=0
Here’s another after updating:
https://www.dropbox.com/s/066jflqyuaczmqc/after.JPG?dl=0
The thing is I’m only using a SandyBridge 2600K CPU so technically it did not do anything with the SandyBridge architecture microcode, right? They 6A7-28 before AND after.
For the IvyBridge microcode though, why did it get rid of microcode 2 and 3 from the before picture and just retained 2 microcodes in the after picture?
3.) How often does Sonix update the UBU version? What usually are the changelogs? Is it just updated OROM versions inside it? Does the latest beta version now give you more updated OROMs inside it?
The package is updated whenever there are new OROM or EFI-modkli. And also if you find mistakes, or other changes to work safely.
The package includes the most recent and popular versions OROM and EFI-ins.
The latest version 1.9.0 gives a more detailed search for EFI-modules and more correct CPU microcode update.
! Fixed a serious bug when updating microcode modules on the BIOS from Gigabyte, AsRock and the like.
That’s right! Since updated only one module, and their 2. The new version of UBU updated all modules and saved "Empty" module.
I used 1.9RC2 on pre-modded bios file, worked perfectly, many thanks!
1. Usually 6-series with ME8/UEFI support work with CSM (legacy BIOS compatibility) enabled. True UEFI requires CSM disabled.
2. If you already had the latest SB microcode it obviously won’t be updated. IVB microcodes do not need to be updated if you are using a SB cpu. Sometimes OEMs accidentally included multiple microcode versions for the same architecture. That’s not right, only one is used when the system is running (probably the latest). UBU automatically takes care of that issue and updates only to the latest microcode for each given platform. And no, unless you specifically do something wrong in UBU there shouldn’t be any board bricking.
Great. The latest beta will be final on January 1, right?
How do I know if my board has its CSM disabled or enabled?
Also, the link that you’ve provided say that CSM if for MBR-booting. I was able to boot off a GPR-partitioned drive when I said "I tried installing Windows in UEFI mode" already so that means that CSM is disabled with that, right?
EDIT by Fernando: Unneeded quoted text deleted (to save space)
CSM is enabled by default.
Get your motherboard manual and take a look at the section where the bios settings are described.
Then check your actual bios settings.
The CSM setting options - if available at all - usually can be found within the "BOOT" section of the mainboard BIOS.
I just checked the manual and the actual BIOS of my mainboard (especially the BOOT section) and did not find anything that says CSM or Secure Boot (I know this is related to UEFI also). What does that imply? Can CSM be disabled/enabled in the BIOS file itself? And what do I achieve if I disable it similar to true UEFI boards?
And by the way, where is the LAN OROM PXE used? I’m assuming that’s only used when booting off of LAN or when deploying OS images from a central deployment server? If that’s the case, updating it won’t be of any advantage when already in Windows, right?
EDIT by Fernando: Unneeded fully quoted text deleted (to save space within this already very voluminous thread)
Usually only Intel chipset mainboards from 7-Series do support the option to boot in "clean UEFI mode" (CSM disabled), where none of the Option ROM modules will be used. This may be the reason why you cannot find the CSM setting option within your UEFI BIOS. A manual implementation of the CSM setting option into the BIOS can only be done by the mainboard manufacturer.
Right!
Could updating the LAN OROM, in any way, fix the problem that I’m having where the computer is randomly turning on by itself even though Wake-On-LAN is already disabled?
EDIT by Fernando: Unneeded fully quoted text deleted (to save space)
Please quote just the absolutely required part of another post!
You can try it (it wouldn’t harm anything), but I doubt, that it will solve your problem.
No. That could be due to mouse/keyboard/lan wakeup which can be changed via Device Manager (Power Management tab) or Intel Smart Connect option in BIOS etc. Either way, this is offtopic at this point.
No. That could be due to mouse/keyboard/lan wakeup which can be changed via Device Manager (Power Management tab) or Intel Smart Connect option in BIOS etc. Either way, this is offtopic at this point.
I understand. And no, wakeup due to mouse and keyboard is already isolated. When I ran powercfg, it points to the Gigabit LAN being the culprit and so I disabled all power management-related things related to it to no avail. There is no Intel Smart Connect Technology in the BIOS as well.
Yes, it’s going off topic I guess. This was my whole point of updating the LAN OROM at first and I guess I realized that it only affects PXE boot and not the LAN driver in Windows itself. With all these, I’d just leave the original BIOS alone as it already has an updated microcode for SB anyway.
Two final questions:
1.) All OROMs have an effect only during boot-time (before Windows), correct?
2.) The NVM firmware of the LAN hardware is different from that of the LAN PXE OROM, correct?
Thanks for all the help!
EDIT by Fernando: Post size shrinked by deleting unneeded quoted text and blank lines
Yes, and the EFI "Drivers" (SataDriver, GopDriver etc.) as well. But that doesn’t mean, that the loaded ROM/EFI "Driver" modules don’t have any effect on the system while working.
Example: The "TRIM in RAID0" feature, which has been implemented by loading the related (modded) Intel RAID ROM or SataDriver module, lets the TRIM command pass through the Intel RAID Controller into the RAID0 array as long as the computer is running.
Yes!
Yes, and the EFI "Drivers" (SataDriver, GopDriver etc.) as well. But that doesn’t mean, that the loaded ROM/EFI "Driver" modules don’t have any effect on the system while working.
Example: The "TRIM in RAID0" feature, which has been implemented by loading the related (modded) Intel RAID ROM or SataDriver module, lets the TRIM command pass through the Intel RAID Controller into the RAID0 array as long as the computer is running.
Yes!
Got it. But in my case, my board’s BIOS is using all OROMs, and so the only ROM that will have an effect to my system while in the OS (running) is the example that you gave (modded TRIM in RAID0). Other than that, the remaining OROMs in the UBU Tool (jmicron, gop, lan pxe, etc.) won’t have an effect while the system is running. Did I get it right?