OS X compatible motherboard -> QUO

[THe KiNG]

My goal is to do the same as 1479 on 1669, So no chance to do it ? Maybe some kext to replace or flags, arguments, something to disable ?

Ozmosis does not interfere(yet) in firmware graphics policy, you forget that between 1479/1669 firmware base was changed from F3A to F2N.

I know Gigabyte numbering can be confusing but F2N is newer then F3A, it has better mouse and keyboard support(since why hotkeys HOME/ALT now works for launching interface) as other improvements.

Now only AMI/Gigabyte can know what they did on graphics core, you can try to replace some drivers with older one and/or BIOS settings but really I don't see why you would like to do it.

IMHO the firmware is right, the graphics that is initted first must have an output valid, plus I don't see the reason you would like it like this, once you enable IGPU you can use it, why not using it?

If you want to be like on Apple iMac, you need to know that they have IGPU enabled but is not set as init first/nor used ever, if discrete card is present.

[alberto21]

Now only AMI/Gigabyte can know what they did on graphics core, you can try to replace some drivers with older one and/or BIOS settings but really I don't see why you would like to do it.

Well, I understand more accurately now. Do you have any idea on the way I can do that ?

 

Now only AMI/Gigabyte can know what they did on graphics core, you can try to replace some drivers with older one and/or BIOS settings but really I don't see why you would like to do it.

IMHO the firmware is right, the graphics that is initted first must have an output valid, plus I don't see the reason you would like it like this, once you enable IGPU you can use it, why not using it?

The reason why is because, with 1669 I Have two options with my dual screen setup and no one is ok for me: 

- Windows with dual screen working on GFE, and OS X IGPU and IGFE DVI 2 out of order the GFE doesn't detect the screen. Thus, no mirrorplay

- Windows with IGPU working and both GFE DVI  outputs ( at least) out of use , it simply doesn't work. OS X IGPU DVI ok and DVI 1 working but DVI2 out of use ( doesn't detect anything )

If you want to be like on Apple iMac, you need to know that they have IGPU enabled but is not set as init first/nor used ever, if discrete card is present.

If I have a Imac default.plist, it's because the past year my apple ID was black listed from the Ozmosis mac pro serial number. So I just took some valid information from a defective Imac. If I do Igpu enable and gfe init first, no boot, with yelling beeps, even if the screens are connected.

[uglyJoe]

Hi alberto21,

 

if the old F3A bios is working well with your setup, perhaps it helps if you simply update ozmosis, smcemulator and so on.

[Allrounder]

Hi TheKiNG I deleted the file you mean. But with out success. Any idea, I don't want to reinstall

[genzai]

hmm, actually i am pretty sure the F3A BIOS is the newer one. Its presented as so on QUO website and the file creation date is later than that of F2N. It also better adheres to the way gigabyte names files for other boards. Could it be possible the devs are using the older BIOS by mistake or intention?

 

g\

[Jaco2k]

So... The Windows not booting IS a Ozmosis bug. I just unplugged ALL drives from my system, plugged in a virgin SSD, booted from an official Windows 10 USB installer - Created with Microsoft's own tools and from the MS website.

 

I started the installation from USB stick, chose the SSD, all went fine until...

...first reboot to boot from the SSD and continue installation, where it never booted.

 

Problem is with the BIOS.

...and to add more information:

 

I confirmed that the MS USB stick created the necessary partitions, logging in via BIOS shell I can get to FS0 and see the EFI partition with all the needed files and folders inside.

 

For some reason, it seems that this BIOS doesn't like the bootx64.efi file from MS. Can you now handle this as a bug?

I am 200% sure now this is a correct EFI installation - everything done from scratch, by the book, with official tools and install method, with no other drives attached to the computer.

[THe KiNG]

 

Well, I understand more accurately now. Do you have any idea on the way I can do that ?

...

 

Dunno what else to say, try to replace IGPU GOP VBIOS with the one from F3A/H3X see if that helps...

 

Hi alberto21,

 

if the old F3A bios is working well with your setup, perhaps it helps if you simply update ozmosis, smcemulator and so on.

I would do the same if a must...

 

Hi TheKiNG I deleted the file you mean. But with out success. Any idea, I don't want to reinstall

 

Dunno what else can be, I have no such bug, windows worked/works since I got this board and I did several re-installs including upgrade to windows 10, cant replicate the issue so no other idea sorry.

hmm, actually i am pretty sure the F3A BIOS is the newer one. Its presented as so on QUO website and the file creation date is later than that of F2N. It also better adheres to the way gigabyte names files for other boards. Could it be possible the devs are using the older BIOS by mistake or intention?

 

g\

If you know better then me and also pretty sure, then you are right...

So... The Windows not booting IS a Ozmosis bug. I just unplugged ALL drives from my system, plugged in a virgin SSD, booted from an official Windows 10 USB installer - Created with Microsoft's own tools and from the MS website.

 

I started the installation from USB stick, chose the SSD, all went fine until...

...first reboot to boot from the SSD and continue installation, where it never booted.

 

Problem is with the BIOS.

...and to add more information:

 

I confirmed that the MS USB stick created the necessary partitions, logging in via BIOS shell I can get to FS0 and see the EFI partition with all the needed files and folders inside.

 

For some reason, it seems that this BIOS doesn't like the bootx64.efi file from MS. Can you now handle this as a bug?

I am 200% sure now this is a correct EFI installation - everything done from scratch, by the book, with official tools and install method, with no other drives attached to the computer.

Well I am not...

[Jaco2k]

Dunno what else to say, try to replace IGPU GOP VBIOS with the one from F3A/H3X see if that helps...

 

I would do the same if a must...

 

 

Dunno what else can be, I have no such bug, windows worked/works since I got this board and I did several re-installs including upgrade to windows 10, cant replicate the issue so no other idea sorry.

If you know better then me and also pretty sure, then you are right...

Well I am not...

AOSWIN.png

 

What, want a video?

.

Just because it works for you, it doesn't mean it is fine - this is what bugs look like. I confirmed this 100%

You should try to reproduce what I described.

[THe KiNG]

What, want a video?

.

Just because it works for you, it doesn't mean it is fine - this is what bugs look like. I confirmed this 100%

You should try to reproduce what I described.

Why?

You do realize that OS X is a hobby for me and I am using Windows as base, as far I remember booting Windows in UEFI and even older in legacy, I never had a single problem booting it using various loaders as grub/chameleon...

At this moment I have no time/free hdd/will to try and replicate user(s) errors, if you cleaned your drives ESP like I said and Windows is installed correctly, you should have no trouble.

I agree Ozmosis should handle all kind of "weird" errors, but I bet this wont be a priority for any developer since I heard none complaining with such bug, maybe in the future...

[IronManJFF]

@THe KiNG How did you get firmware log (bdmesg) from inside Windows ? A tool similar to DarwinDumper ?

Thanks

[THe KiNG]

@THe KiNG How did you get firmware log (bdmesg) from inside Windows ? A tool similar to DarwinDumper ?

Thanks

Run cmd with elevated privilege(administrator)

bdmesg_windows.rar

[Jaco2k]

Why?

You do realize that OS X is a hobby for me and I am using Windows as base, as far I remember booting Windows in UEFI and even older in legacy, I never had a single problem booting it using various loaders as grub/chameleon...

At this moment I have no time/free hdd/will to try and replicate user(s) errors, if you cleaned your drives ESP like I said and Windows is installed correctly, you should have no trouble.

I agree Ozmosis should handle all kind of "weird" errors, but I bet this wont be a priority for any developer since I heard none complaining with such bug, maybe in the future...

 

You do realize that I followed your exact instructions and it did not work?

 

There has to be something more to it - either the port the drive is connected to or some extra setting on the BIOS or... The situation you installed your Windows on.

 

Which BIOS version you made the Windows installation? Which BIOS settings (not the UEFI boot only, that one is obvious) but other things that might influence?

[THe KiNG]

You do realize that I followed your exact instructions and it did not work?

 

There has to be something more to it - either the port the drive is connected to or some extra setting on the BIOS or... The situation you installed your Windows on.

 

Which BIOS version you made the Windows installation? Which BIOS settings (not the UEFI boot only, that one is obvious) but other things that might influence?

Since is my main OS is on port 0, OS X Yosemite is installed on same HDD.

El Capitan is installed on dedicated HDD using FileVault 2.

[Jaco2k]

I actually see the root of this problem as something different - both my tests are being done with SSD and the previous BIOS was a newer base version than the "new".

Can it be that there is a bug with SSD support on the "new" BIOS? Going back to previous BIOS version immediately booted the Windows install.

 

Will try to make a similar screenshot to yours...

Since is my main OS is on port 0, OS X Yosemite is installed on same HDD.

El Capitan is installed on dedicated HDD using FileVault 2.

 

Can you clarify if your Windows install is in a separate HDD? or do you have Yosemite and Windows on the same HDD?

[Allrounder]

FileVault working without keyboard problems? I also want to encrypt my system drive.

[THe KiNG]

There is no bug on the SSD support, mine is on SSD installed and is on port 0(SATA3) of the motherboard.

The newer base is on F2N, you can trust me or Gigabyte reported date, do u want a bios with the release date on 2056? LOL

[Jaco2k]

There is no bug on the SSD support, mine is on SSD installed and is on port 0(SATA3) of the motherboard.

The newer base is on F2N, you can trust me or Gigabyte reported date, do u want a bios with the release date on 2056? LOL

 

Can you share your BIOS settings? mostly the ones that concern the SATA ports/controller and also the boot settings - there has to be a difference somewhere.

 

Now that Windows installation is finishing on the older BIOS, I can make a similar screenshot to yours.

[alberto21]

Hi alberto21,

 

if the old F3A bios is working well with your setup, perhaps it helps if you simply update ozmosis, smcemulator and so on.

Hi uglyJoe,

Thanks for your reply, good idea. 

 

Dunno what else to say, try to replace IGPU GOP VBIOS with the one from F3A/H3X see if that helps...

 

I would do the same if a must...

 

Thanks you king also for your answer.

 

I guess for the Ozmosis update or the IGPU GOP change, I can do it with AMIBCP ? For the Ozmosis files, uglyJoe, can you point me to a topic where I can find the files/ way to proceed ? thanks

[THe KiNG]

Can you share your BIOS settings? mostly the ones that concern the SATA ports/controller and also the boot settings - there has to be a difference somewhere.

 

Now that Windows installation is finishing on the older BIOS, I can make a similar screenshot to yours.

The BIOS settings are default one, and that is recommended if not a must!

I moved my SSD to Port1(SATA3) everything works as expected, make a screenshot like this:

[Jaco2k]

[THe KiNG]

That is from 1479, plus you have windows SSD on port 2(SATA2) not on port 0/1 (SATA3).

I gave up on you, use whatever you like.

[Jaco2k]

That is from 1479, plus you have windows SSD on port 2(SATA2) not on port 0/1 (SATA3).

I gave up on you, use whatever you like.

 

2 things:

- I changed the port to try before you answered (it was the same when it was in the same port as you)

- IT DOES NOT BOOT IN WINDOWS WITH NEWER BIOS BUILD - if it did, of course we wouldn't be having this conversation.

[uglyJoe]

... For the Ozmosis files, uglyJoe, can you point me to a topic where I can find the files/ way to proceed ? thanks

You can use UEFITool to extract them from your new bios.

Open the new bios from UT and do a 'Text' search for 'ozmosis' ... then 'Extract as is'.

If all necessary files are saved to disk, open your old bios, search again for oz and 'Replace as is' file by file.

https://github.com/LongSoft/UEFITool/releases

 

Another useful tool for converting kext or OzmosisDefaults.plist to .ffs is kext2ffs.

https://github.com/tuxuser/kext2ffs

[bs0d]

2 things:

- I changed the port to try before you answered (it was the same when it was in the same port as you)

- IT DOES NOT BOOT IN WINDOWS WITH NEWER BIOS BUILD - if it did, of course we wouldn't be having this conversation.

 

SINCE YOU RESORTED TO SHOUTING, I WILL REPLY LIKEWISE

 

WE BOOT WINDOWS UEFI EVERYDAY USING THE DEFAULT SETTINGS IN THE BIOS, THERE IS NO BUG.

[alberto21]

You can use UEFITool to extract them from your new bios.

Open the new bios from UT and do a 'Text' search for 'ozmosis' ... then 'Extract as is'.

If all necessary files are saved to disk, open your old bios, search again for oz and 'Replace as is' file by file.

https://github.com/LongSoft/UEFITool/releases

 

Another useful tool for converting kext or OzmosisDefaults.plist to .ffs is kext2ffs.

https://github.com/tuxuser/kext2ffs

You're the guy ! thank you !