If the BIOS wasn’t already IV compatible, then we can not make a SB BIOS work with IV by just by adding its microcodes, it requires many more parts…
ok i see, i have a cpu that i have bought and wanted to uppgrade the laptop. can it be done? will some one look at it?
This is what I have been reading. Maybe someone else could fill in more details.
The official statement is that Ivy is not supported on mobile 6 series. But the requirements are these:
1. The socket and TDP –> your laptop is compatible
2. BIOS update with microcodes, firmware ME v8.xx, VBIOS –> which can be done (although not sure if ME FW 8.1.51.1471 works on HM65)
The problem is that such a modded BIOS could brick your laptop. There are ways to recover, either with a thumb drive or with a programmer, but is it worth the risk for you? Even if the BIOS update works, you might still not be able to use the new CPU. Will you be willing to test this, with such little hope of succeeding and high chance of bricking your board?
@ lordkag:
Welcome at Win-RAID Forum and thanks for your contribution!
Regards
Fernando
This one might concern Sonix.
It seems that the BIOS posted by Tommyl has some problems with UBU. First, it has two VBIOS for the same controller 8086-0106 (2098 and 2080), which makes UBU failing at replacing them. I think one is left over and should be deleted. Second, there is another Realtek FE Family controller with ID 10EC-8136 v1.24 which can be updated to 1.34.
Question: can the GopDriver be inserted without other modifications, or it has to be compiled in the original BIOS? Has someone found anything about IntelSaGop and GopPolicy (for Insyde), how they must be tweaked, how are they related to the Gop?
if all the update for ivy bridge with gt2 hd4000 will work on my laptop i wil flash it, if no ivy with hd 4000 but just update the other things i will send back the i3 3110m cpu and just leave the laptop as is. I ordered a 128gb ssd and the 13 3110m to replace the i3 2310m for more mhz and newer gpu hd3000 - hd 4000.
i have asked for return of the cpu if this project is too deep to make ivy work on this one. So if someone ho is looking at the bios would say its possible and "safe" i will keep it.
Thx
Hi,
with GA-Z77X-UP5TH and 12j bios, at "EFI INTEL UNDI" I get the message "Unknown version. Please contact me."
At Marvell sata option rom i get double entry "Marvell 88SE91xx/92xx -1.0.0.0027" instead of one entry.
Also when I extract a efi module to manually replace in other bios, i choose "extract as is" or "extact UnCombressed"?
And final, when i extract the intel lan rom from CSMCORE, mmtool says 8086,1503
but when I look the extracted rom with Hex Editor , I see that it is 8086,1502
ps: where i find in mmtool the EFI intel UNDI module, so I can extract it and see it?
sorry for the long post and I want to thank you again for this very nice forum
@ greg.chalk:
Please give me the link to the BIOS 12j for your mainboard. I can only find version F11 and F12e at Gigabyte’s support pages.
You should contact SoniX regarding this point.
Sometimes the mainboard manufacturer inserts an OROM module twice. Only one of them will be needed and used.
I always extract the modules "uncompressed", because this way I can check the version by using a hex editor.
This is nothing to worry about as long as the OROM works. The entries you see within the "For Option ROM only" section of the MMTool GUI are edited by the motherboard manufactutrer resp. the person, who inserted the related OROM, and doesn’t mean, that the entries are true.
Another example: All Intel RAID ROM modules of Z77 mainboards are declared by the Aptio MMTool as having the DeviceID 282a, but in reality the DeviceID of the Z77 Intel SATA RAID Controller is DEV_2822.
Please ask SoniX, he knows it better than me.
Thank you for your fast response,
so when I will replace the efi module, it doesn’t matter if it is compressed or uncombressed?
Z77XUP5TH.12j.zip (3.74 MB)
If you replace any compressed module by an uncompressed one, the originally uncompressed one will be automaticly compressed by the MMTool.
You can easily verify it by extracting afterwards the freshly inserted module "As is" and compare it with the uncompressed module.
EDIT:
Thanks for the BIOS link.
I just checked the CSMCORE content and couldn’t find 2 Marvell DEV_9192 AHCI/RAID OROM modules.
LAN EFI Intel UNDI - 4.09.00
In the module Marvell 9192 version meets 2 times, so you can see the two versions.
No difference. In some BIOS do not have enough space for the new modules, so module compressed
Just a FYI about the OCZ Vector SSD, it does not use a Sandforce controller. It uses the Indilinx Barefoot 3 controller, which is unrelated to LSI/Sandforce.
http://ocz.com/consumer/vector-7mm-sata-3-ssd/specifications
EDIT by Fernando: The fully quoted text has been shortened (to save space) and linked to the original post.
You are right - thanks for the correction.
Obviously the Indilinx Barefoot 3 Controllers behave similar to the Sandforce ones regarding TRIM with the result, that TRIM activity is not easy to be detected.
@greg.chalk
The Intel EFI Undi is named IntelGigabitLanx64. You can also look inside UBU → VerDID.txt and check name, Device ID or GUID for quick finding.
There are 2 Marvell OROM’s in your BIOS, but the second one is not valid.
Let me see if I got this right: extract CSMCore uncompressed, look for string PCIR for finding OROM name in its proximity, the Dev ID is stored in hex little-indian next to PCIR. A valid OROM is stored with a header like 20 00 ID Hex-length (e.g. for your Intel Lan 8086-1502 and length F800 = 20 00 86 80 02 15 00 F8 00 00, and then the module - 55 AA …)
Your second Marvell OROM is for 1B4B-9230, but it is missing a valid header, an anchor for MMTOOL. Not sure if you should try to add one, if you don’t have this controller. Also, in the case of your Lan 8086-1503, it is the anchor that it is wrong, thus confusing the tool, but the OROM is right. My guess is that only the Device ID from the OROM matters, the header being just for proper structuring. You can check this by flashing this BIOS and checking in Device Manager and in your BIOS.
@Sonix
How did you extracted the version from that EFI module? I couldn’t find anything related to that number, except some meaningless(?) hex values.
Embedded into the BIOS and look through the EFI Shell.
@ SoniX:
Thanks for the release of the updated UBU version 1.1.3.
The start post of this thread has already been customized.
Are you sure, that this OROM dated 07/17/2012 is the latest and that it really works with actual ASMedia 106X SATA Controllers?
Please have a look into >this< station-drivers site.
So,what is happen now with latest OROM VBIOS for Haswell iGPU …?
@ Fernando
I read it, but there was a request to add. If unsubscribe, then everything will become clear.
Edit:
I was very confused by the checksum. CS is not equal to 00.
Search for BSF files and customize OROM VBIOS Haswell.