MP 1,1-5,1 Anyone tried uefiseven to boot win7 in UEFI mode?

[trondl]

I have a MP4,1->5,1 that I've tried to use AHCI in CSM mode in Win7 for some time.
As you probably know, HDD bay 3 & 4 is tricky in this mode (Impossible with the MBR hack?).
I've tried to use grub to set the PCI registers and flip bits in the ABAR memory to set the SATA controller in combined mode (6 port controller instead of the default in CSM mode 4+2. Guess which ports are related to bay 3 & 4).
What I end up with is an almost 2 minutes boot time from an SSD and a constant higher than normal CPU usage from the System Interrupts (IIRC) service.
It is stable and functional after login, but I don't trust this hack.
There may be a correct sequence to reset the controllers PCI register post boot to defaults in 6 port mode, but I haven't found it, or I have the wrong sequence of pciset and bitflips in ABAR ram area.

I am very stubborn (also foolish) and want to avoid OpenCore and Win10. I already have a more competent Win10 machine.

Is https://github.com/manatails/uefiseven a possible solution, although it's intended use is for newer UEFI machines with a lack of int10?
Is Win7 known to write junk/certificates to NVRAM in the same way Win10 does, potentially resulting in a lost ROM?

I have a good dump of the ROM and verified the health of the SPI flash thanks to tsialex guide with UEFITool.

Any input here is welcome!
Thanks in advance.

 

[tsialex]

Is Win7 known to write junk/certificates to NVRAM in the same way Win10 does, potentially resulting in a lost ROM?

I have a good dump of the ROM and verified the health of the SPI flash thanks to tsialex guide with UEFITool.

Any input here is welcome!
Thanks in advance.

Never tried to do that, so can't help more, but Windows SecureBoot started with Windows 8.1. Windows 7 don't sign the BootROM at all.

 

[trondl]

Never tried to do that, so can't help more, but Windows SecureBoot started with Windows 8.1. Windows 7 don't sign the BootROM at all.

Thanks for verifying my hunch!
That makes experimenting a bit less hairy.
I will report my findings when done.

 

[tsialex]

Btw, one of the first things that I found when trying to RI and understand the evolution of MacPro BootROM is that cross-flashed early-2009 Mac Pros have a different CSM than real MacPro5,1s. I've written about it in the past, probably around late 2018 or early 2019 (I don't know if it was on the BootROM thread or to @crjackson2134 when we were comparing his late run mid-2012 to my B08 20H early-2009 Mac Pro).

Anyway, you can always dump your current BootROM image and test your Mac Pro flashed with the 144.0.0.0.0 generic BootROM imag, the MP51.fd, to see if the later CSM works better for you. If it works, a BootROM reconstruction service can reverse the cross-flashing issues and get your Mac Pro to a real 0x0D BootROM image.

 

[trondl]

Btw, one of the first things that I found when trying to RI and understand the evolution of MacPro BootROM is that cross-flashed early-2009 Mac Pros have a different CSM than real MacPro5,1s. I've written about it in the past, probably around late 2018 or early 2019 (I don't know if it was on the BootROM thread or to @crjackson2134 when we were comparing his late run mid-2012 to my B08 20H early-2009 Mac Pro).

Anyway, you can always dump your current BootROM image and test your Mac Pro flashed with the 144.0.0.0.0 generic BootROM imag, the MP51.fd, to see if the later CSM works better for you. If it works, a BootROM reconstruction service can reverse the cross-flashing issues and get your Mac Pro to a real 0x0D BootROM image.

Thanks a bunch for your knowledge!
I think you may be on to something there.
You did post a "quick" reconstruction guide that I read, but until now saw no reason to go through.
As long as I follow that guide to the point, I should end up with a 100% clean and working image?
Worst case, which limb should suffice to pay for a reconstruction?

 

[tsialex]

You did post a "quick" reconstruction guide that I read, but until now saw no reason to go through.
As long as I follow that guide to the point, I should end up with a 100% clean and working image?

That requires that you already have the intermediate files extracted, cleaned and upgraded.

A cross-flashed early-2009 is a mess made with a mix of MP4,1 and MP5,1 components, nowadays I don't even waste time trying to correct it, I just extract what is really needed (the hardwareIDs) and insert in a 0x0D template, then correct the free space indicators and re-do all the checksums. It's definitively not worth trying to repair a cross-flashed BootROM image.

Worst case, which limb should suffice to pay for a reconstruction?

I'll send you a PM.

 

[trondl]

I've now tried uefiseven on a win7 usb install, but got a common error: Unable to unlock VGA ROM memory at C0000.
It looks like someone has successfully changed the address in the source code for an MP 5,1 with OpenCore and RX580, but unfortunately the solution was never given: https://www.win-raid.com/t8270f52-SOLVED-Can-t-install-Windows-on-UEFI-Class.html
The user mentioned patching the address to 0x80000, but was apparently not the solution.
My GPU is an EFI flashed GTX680.

What would be the easiest way to look for the actual address for VGA ROM in vanilla EFI mode without OpenCore?