Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
When I delete the suitable µcodes from i.e. a MP2,1 that were contained for i.e. an E5150 or E5160 processor, or even when I delete all microcodes, and flash that back, the machine still boots!

What could be an explanation? Some backup copy of the last known-good µcode table in the Northbridge (4-8k is not so much to store anywhere)?

The CPU contains its own microcode!

Microcodes in firmware are errata. The processor should be perfectly capably of booting without getting any additional microcode at boot. If they could not, they should have never left the factory. Besides, operating systems contain their own version of microcode patches that are loaded into the CPU when the OS starts.

Checking for microcodes is an antifeature. The BIOS on many motherboards checks to see if they have a microcode for the installed processor and refuse to post or boot if no microcode is included. Evidently Macs do not do that. The iMac 7,1 is perfectly happy to boot with a Penryn processor it has never heard of. Unflashed Mac Pro 1,1s will happily run quad-core Clovertowns.

Does anyone know if the intel ME is located in the 5000 controller (Northbridge) and what kind of embedded controller intel used there? Or does it come along contained in the Xeons?

I believe there is some separate controller on the Intel S5000-series boards for system management. (A bit similar to the SMC on Macs.) The Intel firmware package actually contains three components, named BIOS, BMC, FRUSDR. One of these may be firmware for system management. (Don't ask me what the third one is :)..). I think all three are included in the same 1,7 MB .bin file.

The Core microarchitecture used by Clovertown and Harpertown Xeons is the last Intel architecture without the infamous Intel Management Engine backdoor hidden in the chipset. That is why I believe there will always be an interest in these computers.

I have managed to find the firmware update for the Intel S5000 series servers boards. (Intel must have removed the file from their site since I first posted about this.) The latest BIOS version for the boards is R0098 from November 30, 2010. Only version R0096 from January 13, 2009 can be found anywhere on the web.

I actually managed to download firmware version R0098 from the Intel site last year when it was still available. The release notes contain this text:
=======================================================================
BIOS Changes in release R0098.4
=======================================================================
Issues Fixed:
- Added Microcode Update - SRV_P_96 to address the following:
Intel(R) Xeon(R) Processor 5100 Series Specification Update, Erratum AG131
Intel(R) Xeon(R) Processor 5200 Series Specification Update, Erratum AY76
Intel(R) Xeon(R) Processor 5300 Series Specification Update, Erratum AJ127
Intel(R) Xeon(R) Processor 5400 Series Specification Update, Erratum AX76

The processor specification has changed, new microcode is needed to fix this issue. Intel has recently been updating microcodes to old processors to mitigate Meltdown and SPECTRE and other side-channel vulnerabilities. The Core 2 based Xeons have never received a fix. It may be that they are actually not vulnerable as they do not use hyperthreading.

Update July 30, 2020: The Intel .zip packages contain two versions of firmware, a .bin file and a .cap UEFI capsule file. I tried opening the files in both the R0096 and the R0098 firmware packages with UEFITool 28. UEFITool does not understand the .bin file. It can open a few levels of the .cap file until it reaches a FFSv2 volume it does not understand. The FFSv2 volume is 1969609 bytes but the freeform file inside is only 3345 bytes.
Screen Shot 2020-07-30 at 7.54.09.png
 
Last edited:
  • Like
Reactions: Larsvonhier

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
Meanwhile I tried @petri Krohn´s (revised) suggestion of writing the 1.7MB file directly to the MP2,1 flash. As suspected, nothing happens on boot, other than the mainboard status LED for GPU init flash in an irregular pattern instead of steadily blinking (with 54xx processor). Just a side note.
I really think we have to debug/disassemble the original Apple flash contents.

Can anybody shed some light on what "locked" means for the 2.1MB file? How are the contents in there organised? Is there any table with entry/offset adresses that we can use as hooks for starting to sort out things?
There seems to be no global CRC for the whole file, perhaps separate CRCs exist for code and microcode sections?
Why is it 2.1MB instead of 2MB (the flash is really 32 sectors with 64KB each)? And why does the read-out (done with @dosdude1 rom tool) contain personal setting information as i.e. computer name and wifi settings? I doubt that they are really part of what is stored on flash but perhaps is instead an (address-adjacent region?) content of the NVRAM (4KB SPI chip).
 
  • Like
Reactions: Petri Krohn

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
Meanwhile I tried @petri Krohn´s (revised) suggestion of writing the 1.7MB file directly to the MP2,1 flash. As suspected, nothing happens on boot, other than the mainboard status LED for GPU init flash in an irregular pattern instead of steadily blinking (with 54xx processor).

Do the blinking lights show signs of intelligence?

To show something on the screen we need either a boot screen or a bootable file system connected to a SATA port. The Intel cards have integrated ATI graphics. The default BIOS settings may be set to use only the integrated graphics. Even if the firmware choses to use discrete graphics, it may require specific firmware from the graphics card.

Intel S5000 server boards have EFI firmware, just like Macs and unlike modern motherboards with UEFI. I still do not think they are compatible with Mac video cards with Mac EFI.

To boot from the hard drive and load video drivers you need a Windows or Linux installation. The Intel board is not a Hackintosh, it cannot boot Mac OS.

At this point we are not really interested in booting. All we need to see is if the board posts. Here are a few signs to look for.
Does it try to read from the hard drive? Macs do not have HD LEDs but is there some other way of finding out?
Does the Caps Lock light turn on when pressing the Caps Lock button?

If we can establish that the system is "intelligent" with the 5300-series processors, and we then see the same behavior with 5400-series processors, we know that there is no hardware incompatibility. If, on the other hand, we see intelligence with 5300s and it is missing with 5400s, we have a hardware issue to debug.
And why does the read-out (done with @dosdude1 rom tool) contain personal setting information as i.e. computer name and wifi settings? I doubt that they are really part of what is stored on flash but perhaps is instead an (address-adjacent region?) content of the NVRAM (4KB SPI chip).

The NVRAM variables are stored in the flash ROM. For more see my old post here:

To access all UEFI or NVRAM variables on a Mac, boot into Linux and use the efivar command. You can also see the NVRAM variables as files in the folder /sys/firmware/efi/efivars/. Variables can be created, deleted and modified with the efivarfs filesystem.
If we had a real Intel S5000XVN board we could set up the BIOS and EFI settings to be compatible with a Mac Pro, dump the flash and flash it to the Mac Pro with all its NVRAM variables.

Actually it may be possible to modify a firmware's BIOS settings with out access to the board itself. See this guide on the Win-RAID forum. (To understand what is happening on Win-RAID, read my post first, as linked above.)
 
Last edited:

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
Do the blinking lights show signs of intelligence?

To show something on the screen we need either a boot screen or a bootable file system connected to a SATA port. The Intel cards have integrated ATI graphics. The default BIOS settings may be set to use only the integrated graphics. Even if the firmware choses to use discrete graphics, it may require specific firmware from the graphics card.

Intel S5000 server boards have EFI firmware, just like Macs and unlike modern motherboards with UEFI. I still do not think they are compatible with Mac video cards with Mac EFI.

To boot from the hard drive and load video drivers you need a Windows or Linux installation. The Intel board is not a Hackintosh, it cannot boot Mac OS.

At this point we are not really interested in booting. All we need to see is if the board posts. Here are a few signs to look for.
Does it try to read from the hard drive? Macs do not have HD LEDs but is there some other way of finding out?
Does the Caps Lock light turn on when pressing the Caps Lock button?

If we can establish that the system is "intelligent" with the 5300-series processors, and we then see the same behavior with 5400-series processors, we know that there is no hardware incompatibility. If, on the other hand, we see intelligence with 5300s and it is missing with 5400s, we have a hardware issue to debug.


The NVRAM variables are stored in the flash ROM. For more see my old post here:


If we had a real Intel S5000XVN board we could set up the BIOS and EFI settings to be compatible with a Mac Pro, dump the flash and flash it to the Mac Pro with all its NVRAM variables.
Well, EFI or UEFI -> the UEFI tool my colleague found can perfectly display all contents of our EFI files: MBP4,1 / MP2,1 / MP3,1. It deconstructs and lists all into separate FFSv2 file system containers, subfolders etc. in an overwhelming grade of details. We can spot binary code blobs as well as resources there (i.e. icons for the boot screen as FireWire or USB drives). All very consistent. Now the real work begins to find differences between the 3,1 EFI and the 2,1 one.
The idea is to keep the right parts for suitable S5000 init, but take over as much as needed from the 3,1 EFI and add/inject it to the EFI with the tools we now have at hand ;-)

As for POST: Of course the first step is to get some sign of life out of the MP2,1 // 54xx processor combo. Difference of PC vs. Apple ROM GPU cards is well known, we have both types here, so we can get an output once EFI tries to initialize an "Apple" GPU card. The appropriate diag mainboard LED is fully plausible here as well - blinks as long as non-Apple-cards are not initialized (until El Cap does that). And it turns on earlier during EFI init of the card. All well here.
Activity LED on SSD (connected to USB 2.0) is also there to help, and as said, we can already boot a patched El Cap with a 51xx processor. (In fact, our server in the office runs El Cap on MP2,1 since a couple of years).
Bildschirmfoto 2020-07-29 um 11.18.48.jpg

Bildschirmfoto 2020-07-29 um 11.19.28.jpg


This also clears the question why we find NVRAM stuff here. Seems to be a shadow copy of the actual 4KB SPI EEPROM onboard (in other Macs/MacBooks it´s included as battery buffered SRAM in the RTC). Interesting way it finds its way into the flash - as the flash cannot be written to at all without the 12V Vpp applied by enabling it through long power-on button press...
 
Last edited:
  • Like
Reactions: Petri Krohn

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
One possible issue might be the chipset. Do all revisions of 5000X support Harpertowns. Intel is not telling us anything. The only version of the 5000X datasheet is from September 2006, from a time long before Harpertowns were introduced.

Intel has not updated the datasheet, but they have issued a "Specification Update", revision 009 is from September 2009. I would expect this document to contain information on added processor support, but the document does not mention 5400s or any other Xeon series.

It does however contain a list of chip revisions and their differences. None of the differences explain why one stepping would support the 5400-series and another would not. The main content of the document is errata, a total of 46 errors, only six of which have been fixed in any stepping.

There are four stepping of the 5000-series northbridge. The 5000X chip exist in all four, three of which we have seen in the wild.
  1. Stepping B-2, Revision Number 12h
  2. Stepping B-3, Revision Number 13h - seen in a Dell Poweredge 2900 server with a Xeon X5460 CPU
  3. Stepping G-0 Revision Number 30h - seen in a Mac Pro 1,1
  4. Stepping G-1 Revision Number 31h - seen in a Mac Pro 2,1
Correction July 30, 2020: Actually the Poweredge 2900 with the X5460 has the B-2 stepping, rev 12h, as does every other Poweredge 1950 / 2900 / 2950 out there. This means that every version of 5000X must support Harpertowns!

Original post continues below...

One would think that the G1 stepping is newer than B3 but B3 has actually more errors fixed than G0. The unfixed errors of stepping G1 should not affect its ability to run 5400-series Xeons. Only four of them are fixed in B3, which we know can run Harpertowns. The errors are as follows:
  • 18 (Fixed in B3) PCIe* Link Width Degradation During Reset Tests
  • 19 (Fixed in B3) PCIe Surprise Link Down or Link Degrade During L1 Exit
  • 20 (Fixed in B3) L1 entry Hangs When x4 Links Have Downshifted to x2
  • 21 (Fixed in B3) MCH PCI Express L0s issue
  • 23 (Fixed in G1) Fixed System hang with multiple retries and locks
  • 24 (Fixed in G1) Fixed Patrol Scrub with CRC error issue
The "hidden BIOS setup utility" that is also included in the firmware of MP3,1 and MP5,1 has mitigations for two of the PCIe issues. In the "Internal Forms Representation" file, under "Blackford Pci Express Ports Configuration" we have options to set "L1 Entry Hang Protection" and "Coalesce Mode and MPS". The default value for the last one (as seen in the NVRAM in the variable Setup-EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9) is "Coalesce Mode disabled with MPS of 128B". I do not think errors 18 and 21, even if unfixed in firmware, could prevent a 5400-series CPU from booting in a Mac Pro 1,1.

Trivia: Actually I was looking for something totally different, adding PCIe bifurcation support to a Mac Pro 5,1. The
Intel® 5520 Chipset and Intel® 5500 Chipset datasheet says that the register to manipulate is called PCIE_PRTx_BIF_CTRL.

A Google search for the register name returns as the first result a post on the Win-RAID forum. This post again links to the bifurcation guide on the same forum. Reading the guide I realized that the technique used is the same one I proposed on the "hidden BIOS setup utility" tread.

I then brought up my local copy of the Internal Forms Representation file to see if it contained similar settings for PCIe bifurcation. It only had the two settings listed above. I had no idea what "L1 Entry Hang Protection" and "Coalesce Mode and MPS" were. A Google search for "Coalesce Mode disabled with MPS of 128" brought up the Intel® 5000 Series Chipset Memory Controller Hub (MCH) Specification Update available on the Mouser web site. I already had a stored copy of the document, but had not read through it. There I find the listing of the different stepping, which brings me back here.
 
Last edited:
  • Like
Reactions: Larsvonhier

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
@Petri Krohn
Very structured approach concerning the S5000 steppings, thank you!

Meanwhile, we found the resistor pair that we need to change VTT voltage to approx. 1,1V down from 1,2V (it really is 1,2V and not as previously assumed 1,33V). We found a combination that should work as specified for both types of Xeons (Series 54xx and 51xx-53xx) by applying approx. 1,122V.
I can at least confirm that the 5150 and 5160 Xeons work well with this setting - and the 54xx should be in their "comfort zone" here.

For this, replace R3D10 (formerly 4k99) with 3k3 and R3D11 (formerly 10k) with 8k2.
(The white stars in the photo just cover the "parked" original resistors that I did not want to lose so soldered them with one side to a safe place).

Formula for the voltage is
VTT = (1 + (3k3 / 8k2)) * 0,8

IMG_2732.jpg


Another interesting fact:
We found that the "market segmentation" bits/pads from both processor sockets lead to some I/O ports of the SMC.
While having no clue (yet) what the SMC does with this information (51xx / 52xx / 53xx and 54xx can be distinguished by HW with this 2 bit combination), I have changed the bits to represent a 53xx series Xeon while actually having 54xx in the sockets. It does not bring us to POST success, but on the other hand, the modification is compatible with 51xx Xeons in that they a) still work and b) still report as 51xx back to the SMC.

(Mentioning these two HW mods above because I think we might end up with several HF/FW/EFI mods being required to work together for bringing 54xx success on this machine).
 
Last edited:

Ludacrisvp

macrumors 6502a
May 14, 2008
786
356
when you are doing these tests ... are you using both CPUs or just one? have you tried doing one and tried each socket? are the CPUs known to work properly?
 
  • Like
Reactions: Petri Krohn

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
when you are doing these tests ... are you using both CPUs or just one? have you tried doing one and tried each socket? are the CPUs known to work properly?
We did the tests with one and two matched processors. Single Xeon in socket „B” works (with 51xx). Dual 51xx and 53xx also.
We have 3 pairs of 54xx so at least one of them in „B” should also work...
 

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
Small progress today:
We managed to do some tricks with the UEFI tool that might come handy and in any case add knowledge about the structure of the MB2,1 (and all other Macs!) flash structure.

My colleague found out enough to patch the boot icons in a way that the overall structure keeps being valid. We flashed this and the effect is visible - modified USB drive icons on the boot selector screen while fully bootable.

I also modified the APFS ROM patcher so that it also works on the MP2,1. Patched the original Apple flash contents and saved the result back to disk. We can now compare the patched and unpatched versions to find what the difference is (-> how can additional software be hooked into the contents).

What´s more: The MP2,1 can now detect APFS volumes right in the boot selector. To actually boot from it does not (yet) make sense, as long as we´re Xeon-limited to max. El Capitan.
All credits for the APFS patcher itself of course go to the work of @dosdude1 !

Another info bit: I checked and found that the SMC in the MP3,1 is the same type (H8 2116) as in the 2,1/1,1.
Layout is also very close to the predecessors, so if we´re lucky, the 3,1 SMC firmware could also run on 2,1. I just do not yet dare to risk bricking the "eval board" now. (I recently found a 2116 suitable debugger as PC PCI card on ebay...).
 

Attachments

  • APFS ROM Patcher.app.zip
    11.2 MB · Views: 137
Last edited:

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
boobystrapping (verb)
the process of labeling otherwise identical hardware "revisions" with hidden and undocumented GPIO straps to deprive the user of his right to repair or upgrade his system with otherwise fully functional firmware or hardware.

This techniques seems to be used by American PC manufacturers on their server and workstation motherboards. Dell may be the worst offender.

Dell has at least four products using the Intel 5000X Memory Controller Hub, the Precision 690 and the Poweredge 1950, 2900 and 2950 models. All except the Precision 690 support 5400-series quad-core Xeons in at least one revision. The Poweredge servers come in three revisions.
  1. Generation I: Supports 5100-series dual-core Xeons
  2. Generation II: Supports 5300-series quad-core Xeons
  3. Generation III: Supports 5400-series quad-core Xeons
There is no known hardware difference between the versions, except for the "Gen II" and "Gen III" stickers on the front panel of the later versions. All versions share the same B-2 stepping (rev 12h) of the 5000X north bridge. As far as I know, they all use the same firmware versions. If Dell had followed the Intel documentation and design guidelines, it would have been impossible to create a motherboard that would work with 5100-series or 5300-series Xeons but not with 5400-series Xeons. Yet, when the user installs a 5400-series Harpertown Xeon he is greeted with a in-your-face "Incompatible processor" splash screen.

If the hardware is functionally similar, how then does the firmware know that it is running in a Powerenge without the vital "Gen III" sticker? The technique to do this is "boobystrapping", connecting unused GPIO pins to strap lines that differ between the different "revisions". The firmware then checks to see if the if the straps encode the correct "market segment" to allow the processor to execute. If the customer only paid for the "right" to use Woodcrests, then that is all he will get!

Support has nothing to do with functionality or compatibility. "Supports" is a code word used by hardware vendors to claim intellectual property rights over user-owned hardware.

I suspect the difference in the "R" and "non-R" revisions in Intel S5000 server boards is in the strappings. The likely contents of the long forgotten "Intel V8 Harpertown upgrade" article is that the authors found the strapping resistors and moved them into the revision "R" locations. It can no longer be found on the internet as it was removed because of a DMCA takedown notice.

Update August 1, 2020: The Intel® 82802 Firmware Hub and the pin compatible M50FW016 that is used in the Mac Pro 1,1 and 3,1 has five general purpose input (FGPI) pins. Intel says that "these individual inputs can be used for additional board flexibility." ST says they are for "platform design flexibility." (See M50FW016 datasheet below.)

Screen Shot 2020-08-01 at 18.29.40.png


Many of Intel's ATX sized S5000-series motherboards share the same basic PCB. For example the S5000XVN has empty solder pads instead of the ATI ES1000 graphics chip and the second PCIe slot. It is likely that intel differentiated between the various board layouts by strapping the FGPI pins. They might also have used one of the pins to differentiate between the "R" and "non-R" revisions.

P.S. - Apple might have used the pins to differentiate between Mac Pro 1,1 and Mac Pro 2,1. Someone with a multimeter should check the strappings.
 

Attachments

  • Screen Shot 2020-08-01 at 18.04.53.png
    Screen Shot 2020-08-01 at 18.04.53.png
    92.1 KB · Views: 118
Last edited:

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
In the seven years the DELL Precision 690 microcode update thread has been up on the bios-mods.com site no one has figured out how to run Harpertowns or even to boot with quad-core Clovertowns on the wrong motherboard revision. User DeathBringer has however posted this insightful piece of code from module 0B_9.ROM of the DELL Precision 690 firmware. The code checks the CPUID and if it does not like what it sees it jumps to a subroutine to display messages on the VGA screen with and error status of 0x16 meaning "Alert! Incompatible processor detected." It then halts the processor, preventing it from booting. It may be possible to bypass the compatibility check and boot once by clearing the CMOS memory.

Code:
9FD8    push    eax
9FDA    mov     eax, 1
9FE0    cpuid
9FE2    and     ax, 0FFF0h
9FE5    cmp     ax, 0F60h     ; Dempsey
9FE8    jz      short 0A00Ah
9FEA    cmp     ax, 6F0h      ; Woodcrest & Clovertown
9FED    jnz     short 0A00Ah
9FEF    call    sub_AE1D      ; reading byte in 0F000h:4D73h
9FF2    cmp     al, 3
9FF4    jb      short 0A00Ah
9FF6    mov     al, 50h ; 'P'
9FF8    call    0F000h:0F18Ch ; reading CMOS memory
9FFD    cmp     al, 30h ; '0' ;
9FFF    jnb     short 0A00Ah
A001    mov     cx, 16h       ; set error status to 16h
A004    call    sub_B7A5
A007    jmp     732Bh         ; jump to halt state
A00A    pop     eax           ; continued normal

Many users still believe the issue is missing microcode. It is not, the firmware has microcodes for quad-core Clovertown Xeons in both B3 and G0 steppings. I believe the issue is in the FGPI strappings. Wrong strappings mean Clovertowns are "unsupported" and system refuses to boot.

Actually the code above with the simple cpuid instruction cannot distinguish between dual-core 5100 Woodcrests and quad-core 5300 Clovertowns, as thay share the same die and CPUID. It will however prevent the system from booting with 5400-series Harpertowns.

Dempsey with CPUID 0F60h (Family ID F, Model 6, Stepping ID 0-4) is a Pentium 4-derived hyperthreaded dual-core processor. Despite its larger transistor count and its 3.7 GHz top frequency it has half the performance of Core 2-derived dual-core Xeons.

These are relevant CPU IDs. The Mac Pro 2,1 firmware actually supports Dempseys, although no Mac OS version may be able to boot on them.

CPUID (Stepping)​
Dempsey (5000)​
0F64 (C1)​
Woodcrest / Clovertown (5100 / 5300)​
06F6 (B2)​
06F7 (B3)​
06FB (G0)​
Wolfdale / Harpertown (5200 / 5400)​
0676 (C0)​
067A (E0)​

I checked if there were similar CPUID checks in the Mac Pro 2,1 firmware. I opened the Mac Pro EFI Firmware Update package that I had downloaded from Apple. After peeling though about ten layers of encapsulation (.dmgs, packages, .zips) I found the file named LOCKED_MP21_007F_06B.fd. I saved it on disk and opened it with UEFITool.
Screen Shot 2020-08-02 at 16.18.47.png

The EFI image containes three main parts, each with the same GUID of "7A9354D9-0468-444A-81CE-0BF617D890DF". The first part is 1572864 bytes (180000h) long and contains a DXE core and DXE drivers. The next 16384 byte (4000h) section contains mainly a raw section. (Update August 21, 2020: GUID 00000000-0000-0000-0000-000000000000 contains the microcode updates.)

The last section is 262144 bytes long (40000h) and contains PEI modules. PEI stands for Pre-EFI Initialization. Two modules stand out, a PEI core and a SEC core. SEC or SECurity phase is the first part of EFI firmware to be executed.

I extracted module SEC core.fbd from the EFI image and saved it to disk. I then opened it with a demo version of the Hopper disassembler.

The module has code for both Dempsey (CPUID 0F60h) and Woodcrest / Clovertown (CPUID 06F0h) processors. Every time it sees the CPUID 06F0h it does some processor initialization specific to Core 2 processors. It seems evident that if this initialization is not done the system will not post or boot. A Harpertown processor with CPUID 0670h would not be initialized.

The code compares the masked CPUID against the value 6F0h (0x6f0 on the Hopper listing). If it is a match, it sets a bit in a Model Specific Register by reading and writing to the register.

Screen Shot 2020-08-02 at 17.45.26.png


A simple way to add support for Harpertowns would be to do the same initializations to all Family 6 processors. This can be done by narrowing the CPUID mask to only cover the Family ID part of the bit vector.

The code
Code:
mov     eax, 1
cpuid
and     ax, 0xff0
cmp     ax, 0x6f0
jne     loc_13ab

would become.
Code:
...
cpuid
and     ax, 0xf00
cmp     ax, 0x600
...

0xF and 0x7 share the last three bits. If we wanted to be more restrictive we could write
Code:
and     ax, 0xf70
cmp     ax, 0x670

This would imply changing the least amount of bits in the code.

I also extracted the whole PEI section. It contains some 10 others calls to cpuid. Two of these make an explicit compare to 0x6f0. These too need to be changed.

Update August 3, 2020: Would it be possible to combine the PEI code from the Intel S5000-series firmware with the rest of the EFI firmware from Mac Pro 2,1? At a minimum we might want to take the SEC core module from the Intel S5000XVN server board. (Actually we may want to use the Mac Pro 3,1 EFI with the Intel Pre-EFI Initialization.)

I extracted the SEC core module from the Intel R0098 BIOS update package. It has code to support all there LGA771 Xeon generations, Dempsey, Clovertown, and Harpertown. The coding style is different from the one used in the Mac Pro firmware. Mac explicitly checks for CPUIDs 0x6f0 and 0xf60. Intel assumes that it will ever see only three different CPUIDs, namely 0x6f0, 0x670, and 0xf60. Or at the minimum it assumes that any future Clovertown-compatible CPU will have a CPUID with a numerical value that is less than 0x6f.

Screen Shot 2020-08-03 at 9.03.23.png


The above is a typical example of the Intel code. It first checks to see if the bitmasked CPUID is less or equal to 0x6f0, i.e. the CPU is a Clovertown or Harpertown. If so it jumps to a "subroutine" section that sets certain bits in Model Specific Registers 0xe2 and 0x1a0. It then next compares the CPUID to 0xf60 and if it is a match it performs a different set of initializations. (Note that the "subroutine" sub_1a7f+118 shown in the yellow box on the right is actually the same code as on the left starting at address 00001af5. The arrows on the left also show the same control flow.)

There is only one time the code explicitly checks for the CPUID 0x670 (Harpertown). It is seen on line 000001b37 in the code above.

P.S. - I think I have found the Halt and Catch Fire (HCF) instruction. It is located at address 00001d91. A jump to sub_1ce0+177, as used above, goes to this address. Note the address notation, 1ce0 is in hexadecimal and 177 is in decimal. I still have not figured out which CPUID combination actually goes there.

Screen Shot 2020-08-03 at 13.22.56.png


As far as I can tell there is only one difference in the behavior of the Intel SEC core module between Clovertowns and Harpertowns. In both cases Model Specific Registers 0x198 is read and masked against a bitmask. Clovertowns with CPUID 0x6f0 read bits 0x1f while Harpertowns with CPUID 0x670 read one extra bit using bitmask 0x5f. I do not think the missing bit would prevent Harpertowns from booting on a Mac Pro, if only the Clovertown specific code of the Mac Pro 2,1 firmware was executed.

Screen Shot 2020-08-04 at 0.07.12.png


More on the Intel firmware file...

Compilers produce object modules from source files. An object module typically contains three parts, a .text segment for code, a .data segment for static and global variables and a relocation table (.reloc) containing relocation entries. A linker then combines the object modules into one executable program merging each of the segments. (At least I think they do, but I have not written a dynamic linker/loader in 30 years.) A program that is executable in an operating system retains the relocation table. The loader can then map the local offsets to global addresses depending on where in the address space it loads the program.

Static firmware like the Pre-EFI Initialization part of the boot ROM would not need relocation tables. It sits at a fixed address defined by the processor architecture. As expected, the .bin image of the flash rom Intel offers as an alternative does not contain any .text or data or .reloc segments.

I was however surprised to see .text and .data segment and relocation tables in both the Apple and Intel EFI images. The processor would not know how to link and load these if it ever saw them on the flash rom chip! The EFI flash utility must therefore contain its own linker to create the .bin image for the flash chip. But why then does the EFI image contain padding files? Shouldn't the linker decide where it wants to put each piece of code in the binary image? (This is relevant as we may need to change the size of the padding files if we change the size of an object module.)

I was not able to open the Intel EFI image with UEFITool. I therefore decided to look for the SEC core module with a hex editor. The object modules in the EFI image are easy to spot. In clear text you can read ".text", ".data", and ".reloc" near the beginning of the module. The SEC core module was easy to find, as it was at the end of both files. Also, it may have been compiled with a different compiler that the other modules. In both EFI images the SEC core module has five segments, labeled .text, _TEXT_RE4, _TEXT_PR, data and .reloc. The Intel module is somewhat longer than the Apple module. (I suspect the "Apple" module actually comes from Intel, as part of the Intel® Firmware Support Package.)

From the Apple EFI image I had earlier extracted the SEC core module both as "Extract as is..." and "Extract body". The resulting files differed in the "SEC core.ffs" file having some extra bytes of header around the content of the "SEC core.fdb" file. I the hex editor I tried to cut a segment from the Intel EFI image along the same lines as the SEC core.ffs file was cut. The beginning was easy, but I am not 100% sure of the the end, as there was some extra padding after the module in the Intel file. (One must check if the file size matches the data in the EFI header.) In theory it should be possible to implant this module to the Apple EFI image by replacing its original SEC core. I don't think this alone would make the system boot, as there are still other CPUID checks in other parts of the Pre-EFI Initialization.

I am including a copy of the Intel SEC core module for commentary and research. (2,745 byte .zip file)

Update: I was able to replace the Apple SEC core module with the Intel SEC core module in the LOCKED_MP21_007F_06B.fd file using UEFITool. The file size stays the same at 200000h (2097152).
 

Attachments

  • SEC core Intel S5000.ffs.zip
    2.7 KB · Views: 121
Last edited:

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
In the seven years the DELL Precision 690 microcode update thread has been up on the bios-mods.com site no one has figured out how to run Harpertowns or even to boot with quad-core Clovertowns on the wrong motherboard revision. User DeathBringer has however posted this insightful piece of code from module 0B_9.ROM of the DELL Precision 690 firmware. The code checks the CPUID and if it does not like what it sees it jumps to a subroutine to display messages on the VGA screen with and error status of 0x16 meaning "Alert! Incompatible processor detected." It then halts the processor, preventing it from booting. It may be possible to bypass the compatibility check and boot once by clearing the CMOS memory.

Code:
9FD8    push    eax
9FDA    mov     eax, 1
9FE0    cpuid
9FE2    and     ax, 0FFF0h
9FE5    cmp     ax, 0F60h     ; Dempsey
9FE8    jz      short 0A00Ah
9FEA    cmp     ax, 6F0h      ; Woodcrest & Clovertown
9FED    jnz     short 0A00Ah
9FEF    call    sub_AE1D      ; reading byte in 0F000h:4D73h
9FF2    cmp     al, 3
9FF4    jb      short 0A00Ah
9FF6    mov     al, 50h ; 'P'
9FF8    call    0F000h:0F18Ch ; reading CMOS memory
9FFD    cmp     al, 30h ; '0' ;
9FFF    jnb     short 0A00Ah
A001    mov     cx, 16h       ; set error status to 16h
A004    call    sub_B7A5
A007    jmp     732Bh         ; jump to halt state
A00A    pop     eax           ; continued normal

Many users still believe the issue is missing microcode. It is not, the firmware has microcodes for quad-core Clovertown Xeons in both B3 and G0 steppings. I believe the issue is in the FGPI strappings. Wrong strappings mean Clovertowns are "unsupported" and system refuses to boot.

Actually the code above with the simple cpuid instruction cannot distinguish between dual-core 5100 Woodcrests and quad-core 5300 Clovertowns, as that share the same die and CPUID. It will however prevent the system from booting with 5400-series Harpertowns.

Dempsey with CPUID 0F60h (Family ID F, Model 6, Stepping ID 0-4) is a Pentium 4-derived hyperthreaded dual-core processor. Despite its larger transistor count and its 3.7 GHz top frequency it has half the performance of Core 2-derived dual-core Xeons.

These are relevant CPU IDs. The Mac Pro 2,1 firmware actually supports Dempseys, although no Mac OS version may be able to boot on them.

CPUID (Stepping)​
Dempsey (5000)​
0F64 (C1)​
Woodcrest / Clovertown (5100 / 5300)​
06F6 (B2)​
06F7 (B3)​
06FB (G0)​
Wolfdale / Harpertown (5200 / 5400)​
0676 (C0)​
067A (E0)​

I checked if there were similar CPUID checks in the Mac Pro 2,1 firmware. I opened the Mac Pro EFI Firmware Update package that I had downloaded from Apple. After peeling though about ten layers of encapsulation (.dmgs, packages, .zips) I found the file named LOCKED_MP21_007F_06B.fd. I saved it on disk and opened it with EFITool.
View attachment 939756
The EFI image contained three main parts. The first part FileSystem GUID: 7A9354D9-0468-444A-81CE-0BF617D890DF is 1572864 bytes (180000h) and contains a DXE core and DXE drivers. The next 16384 byte (4000h)
section contains mainly a raw section.

The last section with GUID: 7A9354D9-0468-444A-81CE-0BF617D890DF is 262144 bytes long (40000h) and contains PEI modules. PEI stands for Pre-EFI Initialization. Two modules stand out, a PEI core and a SEC core. SEC or SECurity phase is the first part of EFI firmware to be executed.

I extracted module SEC core.fbd from the EFI image and saved it to disk. I then opened it with a demo version of the Hopper disassembler.

The module has code for both Dempsey (CPUID 0F60h) and Woodcrest / Clovertown (CPUID 06F0h) processors. Every time it sees the CPUID 06F0h it does some processor initialization specific to Core 2 processors. It seems evident that if this initialization is not done the system will not post or boot. A Harpertown processor with CPUID 0670h would not be initialized.

The code compares the masked CPUID against the value 670h (0c670 on the Hopper listing). If it is a match, it sets a bit in a Model Specific Register by reading and writing to the register.

View attachment 939782

A simple way to add support for Harpertowns would be to do the same initializations to all Family 6 processors. This can be done by narrowing the CPUID mask to only cover the Family ID part of the bit vector.

The code
Code:
mov     eax, 1
cpuid
and     ax, 0xff0
cmp     ax, 0x6f0
jne     loc_13ab

would become.
Code:
...
cpuid
and     ax, 0xf00
cmp     ax, 0x600
...

0xF and 0x7 share the last three bits. If we wanted to be more restrictive we could write
Code:
and     ax, 0xf70
cmp     ax, 0x670

This would imply changing the least amount of bits in the code.

I also extracted the whole PEI section. It contains some 10 others calls to cpuid. Two of these make an explicit compare to 0x6f0. These too need to be changed.

Update August 3, 2020: Would it be possible to combine the PEI code from the Intel S5000-series firmware with the rest of the EFI firmware from Mac Pro 2,1? At a minimum we might want to take the SEC core module from the Intel S5000XVN server board. (Actually we may want to use the Mac Pro 3,1 EFI with the Intel Pre-EFI Initialization.)

I extracted the SEC core module from the Intel R0098 BIOS update package. It has code to support all there LGA771 Xeon generations, Dempsey, Clovertown, and Harpertown. The coding style is different from the one used in the Mac Pro firmware. Mac explicitly checks for CPUIDs 0x6f0 and 0xf60. Intel assumes that it will ever see only three different CPUIDs, namely 0x6f0, 0x670, and 0xf60. Or at the minimum it assumes that any future Clovertown-compatible CPU will have a CPUID with a numerical value that is less than 0x6f.

View attachment 939945

The above is a typical example of the Intel code. It first checks to see if the bitmasked CPUID is less or equal to 0x6f0, i.e. the CPU is a Clovertown or Harpertown. If so it jumps to a "subroutine" section that sets certain bits in Model Specific Registers 0xe2 and 0x1a0. It then next compares the CPUID to 0xf60 and if it is a match it performs a different set of initializations. (Note that the "subroutine" sub_1a7f+118 shown in the yellow box on the right is actually the same code as on the left starting at address 00001af5. The arrows on the left also show the same control flow.)

There is only one time the code explicitly checks for the CPUID 0x670 (Harpertown). It is seen on line 000001b37 in the code above.

I am including a copy of the Intel SEC core module for commentary and research. (2,745 byte .zip file)
Super findings, great source of info for us to delve into! Thanks a lot!
We´ll investigate/disassemble the 3,1 counterpart for the CPU related checks there and compare it to the 2,1 EFI.
Side question: For uncompressing and compressing (LZMA) - do you have hints for (command line) tools? I guess we´d find some brews for that task, but perhaps you can already hint us to suitable tools?

edit:
found that xz can be forced with "-F lzma" to compress to the desired format and seems to work as "advertised" ;-)
 
Last edited:
  • Like
Reactions: Petri Krohn

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
We´ll investigate/disassemble the 3,1 counterpart for the CPU related checks there and compare it to the 2,1 EFI.

I do not know if anyone has ever tried running Mac Pro 3,1 firmware on a Mac Pro 1,1. If it does not work, it is most likely because the firmware cannot initialize the 5000X northbridge. The SEC core module alone implanted to the rest of MP2,1 firmware might work.You would need to make sure that the processors are of the right C0 stepping and not of the newer E0 stepping.

What to test next:
  1. Mac Pro 2,1 EFI with Intel SEC core implant. (Extract the section from the R0096 image or use the file included in my previous post.) There are still some CPUID 0x6f0 checks in other parts of PEI, but I do not know how fatal they are.
  2. Same as number one, but rest of CPUID 0x6f0 checks corrected. I will next try to find them in the binary file using a hex editor, correct them, and extract the corresponding EFI module using UEFITool. I will then replace the check for the CPUID 0x6f0 with a check for Family ID = 0x600. I will post the module online, after I have checked with an disassembler that the changes are those that were planned.
  3. Original Mac Pro 2,1 EFI with all cases of CPUID = 0x6f0 replaced with Family ID = 0x600.
The PEI.vbd file I extracted for the LOCKED_MP21_007F_06B.fd is 0x3FFB8 bytes long. There are multiple cpuid calls outside the SEC core module, but most of them are not CPU type specific. Here is a typical example.

Screen Shot 2020-08-04 at 15.37.36.png


I went through the file with Hopper disassembler looking for offending cpuid calls. Hopper shows the two that need a fix at addresses 0xFFDA and 0x17162. Hopper however adds 0x1000 to the addresses it shows, so the real addresses are 0xEFDA and 0x16162 in my PEI.vdb file.

The PEI section with the 72 byte header is 0x40000 bytes long. The start address of PEI.vbd in the LOCKED_MP21_007F_06B.fd file is 0x200000 - 0x3FFB8 = 0x1C0048 = 1835080.

Address 0xEFDA of PEI.vbd is 0x1CF022 or 1896482 in the whole EFI capsule. The two values to change are at 0x1CF02A = 1896490 and 0x1CF02F = 1896495. (I can set Hex Fiend to shows addresses in decimal format, but I decimal addresses to use the "Move" function.)

At address 0x1CF022 or 1896482 I find this code.
0FA28945 FC8B45FC 25F00F00 003DF006 0000

I changed it to this
0FA28945 FC8B45FC 25000F00 003D0006 0000

The other cpuid call to fix is at 0x1D61AA = 1925546.

Screen Shot 2020-08-04 at 18.22.00.png


There are two additional move commands between the cpuip command and the and command, therefore the extra bytes. The x86 is little-endian, so the data bytes are flipped.

I made the same change also to the PEI.vbd file to check how the changes have taken effect. This is the file before and after.

Before edit:

Screen Shot 2020-08-04 at 18.02.00.png


After edit:

Screen Shot 2020-08-04 at 17.57.08.png


I have created a EFI image file named MP21_007F_06B - Petri CPUID fix - Intel SEC inject.rom that contains the fixes suggested at option 2 at the top. I will not post it online untested, but I think it may work. I will next try to locate the two PEI modules I have just edited. I will then extract them from the capsule using UEFITool, check the code using Hopper disassembler and if it looks good I will post them here so they can be injected into some EFI image.

@Larsvonhier - I will send the file to you if you provide contact information. You can find me on Gmail at petri.krohn@...
 
Last edited:

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
The complete 3,1 firmware does not run on 2,1 hardware. We tried it. RAM init goes wrong, one Err LED on each riser card...

SEC transplant from 3,1 to 2,1 section does not work when done quick&dirty without adapting code lengths

Patching 2,1 with CPUID to 10676 does not show CPU Err LEDs, but does not POST successfully.

0x600 does instead act with Err LED as 0x6f0 did.
 
  • Like
Reactions: Petri Krohn

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
@Larsvonhier - When you say "does not run", do you mean does not boot at all, or does not boot with 5400-series Xeons?

0x600 does instead act with Err LED as 0x6f0 did.

Does it boot with 5100 or 5300-series Xeons (CPUID 0x6f0)? You may have to correct the two additional cpuid checks I listed above.

Patching 2,1 with CPUID to 10676 does not show CPU Err LEDs, but does not POST successfully.

Why check for such a specific model number, with stepping number included. This code should not work with the 5100/ 5300 Xeons.

SEC transplant from 3,1 to 2,1 section does not work when done quick&dirty without adapting code lengths

What do you mean by adapting code lengths? Does UEFITool not set the code length automatically? (It does for me.)

The complete 3,1 firmware does not run on 2,1 hardware.
What happens if you take the Mac Pro 3,1 firmware and replace the whole PEI section with PEI taken from MP2,1?
 
Last edited:

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
Analyzing the Mac Pro 2,1 SEC core module.

The module has a total on ten calls to cpuid, eight of these are done with eax set to 0x1. I will group them bellow with suggestions on if and how each of them should be fixed. I will list the addresses as they are shown by Hopper when viewing the SEC core.ffs file. The addresses are 0x18 = 24 less when viewed in the SEC core.fbd file without the 24 byte ffs header. Hopper also adds 0x1000 to the addresses.

- 12DF
Screen Shot 2020-08-04 at 21.24.00.png


In one case the CPUID is read and stored without checking for anything. The ID is masked with 0xFFF3FFF to remove the undefined "reserved" bits. I do not think anything needs to be done here.

- 13A4
- 13C8
Screen Shot 2020-08-04 at 21.30.10.png


In two cases the CPUID is checked against the 0x6F0 of Woodcrest/Clovertown Xeons with a bitmask of 0xFF0. This check should be against Family ID, not against a specific CPUID. Change mask to 0xF00 and compare against 0x600.

- 185F
- 18A1
Screen Shot 2020-08-04 at 21.32.54.png


In two cases the CPUID is checked against the 0x6F0 with a bitmask of 0xFFF3FF0. At first I thought this was a bug in the code. I expected cpuid to return "Extended Model ID" in bits 16-19, but Clovertown Xeons only return values in the last 12 bits of the CPUID bit vector. The Extended Model ID is always 0x0, whereas it is 0x1 for Harpertowns. We need to change the mask to 0xF00 and compare against 0x600.

- 1790
- 182C
Screen Shot 2020-08-04 at 21.31.03.png


In two cases the CPUID is checked against the 0xF60 of Pentium 4 like Netburst Xeons. Nothing needs to be done here.

- 13EB
Screen Shot 2020-08-04 at 22.46.26.png


In one case the stepping of a Woodcrest/Clovertown Xeon is checked to see if it is less than 2. This could be left as is, as Harpertowns have a full CPUID of 0x10670, which is more than 0x6F0. I have changed the code anyway to check for an exact CPUID and stepping value of 0x6F1.

At first this too looked like a bug, as the CPUID value is compared against the unmasked output of cpuid. Actually it is just bad and inconsistent programming style. The whole branch is likely unnecessary, as stepping 1 is an engineering sample that we are unlikely to ever meet.

Update: I have attached the updated SEC core module to the post. Use a hex editor to cut and paste it to the end of the MP21 EFI image file or use UEFITool to merge it. (Now updated to version 2.)

Update 2, August 5, 2020: I have created an EFI image file by making all the edits to the original MP21 firmware image. This includes the edits to SEC core and the two edits to the rest of the PEI segment. I will share the file on request.

Update 3, August 6, 2020: I have figured out that the Woodcrest/Clovertown Xeons only return values in the last 12 bits of the CPUID bit vector. The "Extended Model ID" bits were only defined for Penryn, 5400-series Xeons. It is therefore not a bug to compare the unmasked CPUID to 12-bit values. I have changed my code to use the 0xF00 bitmask everywhere. I have edited this post accordingly.

Here is a diff of the two files from "cmp -l" but with the octal values converted to hex.
Code:
1896492  F0   0
1896497  F0   0
1925556  F0   0
1925561  F0   0
2095176  F0   0
2095181  F0   0
2095212  F0   0
2095217  F0   0
2095247  F2  F1
2095251  7C  74
2096387  F0   0
2096388  3F  0F
2096389  FF   0
2096390  0F   0
2096392  F0   0
2096458  F0   0
2096459  3F  0F
2096460  FF   0
2096461  0F   0
2096463  F0   0

This is the output I get when I run the md5 command from the terminal:
Code:
MD5 (/Users/petri/Documents/Apple/Firmware/Mac Pro 2,1/MP21_007F_06B Petri CPUID fix - v02.fd) = 83cedbfa1dd7e17b9bfc351633099b60
 

Attachments

  • SEC core Petri CPUID fix v02.ffs.zip
    2.5 KB · Views: 149
Last edited:

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
@Petri Krohn
Thanks for your suggestions, very welcome to have additional thoughts on the matter!
We also use a demo of Hopper, but also a very hand online ass/disass: Defuse.ca
...and we reached the same conclusions about what to modify in the 2,1 code, but what I do not get is
that you suggest to mask and compare to the $600 family processor ID whereas I´d see comparing to the
actual 1067x ID of our E5440 Xeons.
Perhaps you have more insight: Do the E5440 (with their ID 10676) report back a family ID in the $6xx range via MSR register call? Otherwise the suggested compare to those 6xx IDs you modified the code for won´t work...

edit:
Or does the masking just rely on getting rid of the "10" of the "10676" and thus result in 6xx?
Then it would be plausible and explain why it leads to the same end result, no POST completion.
We suspect now that on different Xeons we´d have to initialize certain MSRs with individual values. Unfortunately, the 3,1 code is very differently structured in this module, as i.e. instead of 10 CPUID checks there seems only to be made one check and then subsequently initialized differently depending on which exact type of Xeon is found.
 
Last edited:
  • Like
Reactions: Petri Krohn

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
...and we reached the same conclusions about what to modify in the 2,1 code, but what I do not get is
that you suggest to mask and compare to the $600 family processor ID whereas I´d see comparing to the
actual 1067x ID of our E5440 Xeons.

I believe the firmware must be made compatible with both 5300 (0x6F) and 5400 (0x67) Xeons. Everyone cannot have a dual BIOS setup to switch between firmware every time they swap processors.

Testing should happen in two steps: 1) First try the firmware with 5100s or 5300s to check that the changes broke nothing. 2) Only then swap the processors to see if the firmware can post with 5400s. Doing both these things in one step is too complex and likely to fail.

If you compare the CPUID against 0x10676 your test is too specific. The system will post with only one stepping of a specific processor series. One should mask the bits to allow a maximum number of CPUs to pass the test.

Testing for CPUID only exist because Apple (or Intel) wanted to maintain compatibility with Netburst Depseys that no one in their right mind would ever dream of putting in a Mac Pro. If the Mac Pro was intended to support only one type of processor, they could have left out the checks. As a side effect this would have solved the issue of compatibility. Newer CPU types are usually backward compatible with firmware made for older CPUs, unless the firmware has anti-features that intentionally lock them out.

Or does the masking just rely on getting rid of the "10" of the "10676" and thus result in 6xx?

Yes, I believe Xeons actually return a full CPUID bit vector, with bits set for Extended Model ID, Family ID, Model, and Stepping ID. If one wants to support all possible steppings, then one must mask out the Stepping ID bits before doing the comparison. This leads me to believe the Mac Pro 2,1 SEC core module is buggy. Comparisons are made to the result of cpuid without masking off the extra bits. This leads to dead code which is never executed by any processor. But it has worked for 13 years. We would only make matters worse if we try to fix it now.

As we cannot rewrite the code we must leave all the checks in place. Let the Netburst branch be as in it. Make sure that all Core 2 CPUs (both 0x6f and 0x67) follow the Core 2 branch.

Do the E5440 (with their ID 10676) report back a family ID in the $6xx range via MSR register call?
Netburst Dempseys return a Family ID of "F" (15) in the 0xF00-masked bits of the CPUID. Core2-derived Clovertowns and Harpertowns return a Family ID of "6" in the same bit positions.

P.S. - I sent you a private message.
 
Last edited:
  • Like
Reactions: Larsvonhier

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
We made some progress yesterday. I sent Lars a version of my code. He tested it after fixing the checksum for one of the modules. It booted fine with Xeon 5100s but got stuck in POST with 5400s.

I later realized that there was a bug in my code. 5100s have an Extended Model ID of 0x0 while it is 0x1 for 5400s. I changed a few more bytes in the EFI image and sent it to Lars. I also updated my previous comment on "Analyzing the Mac Pro 2,1 SEC core module" to reflect the changes.

Update 3, August 6, 2020: I have figured out that the Woodcrest/Clovertown Xeons only return values in the last 12 bits of the CPUID bit vector. The "Extended Model ID" bits were only defined for Penryn, 5400-series Xeons. It is therefore not a bug to compare the unmasked CPUID to 12-bit values. I have changed my code to use the 0xF00 bitmask everywhere. I have edited this post accordingly.

If this was a vaccine test we would have passed Phase I for safety. It is safe to inject the modified code. Now we have to pass Phase II and show that the code changes have the desired effect.
 
  • Like
Reactions: flygbuss

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
I sent @Larsvonhier the second version of my MP21 EFI image with CPUID fixes. It again booted fine with Xeon 5100s but failed POST with 5400s. It seems we are stuck without debugging tools. Can we make the Mac Pro display POST codes?

POST codes can be sent over the PCI, PCIe or LPC buses. Modern POST diagnostic cards have connectors for reading all three. A BIOS sometimes has settings for selecting where to send the POST codes. SuperMicro motherboards that share the 5000-series Blackford northbridge with the Mac Pro 1,1 have a BIOS setting for selecting between PCIe and LPC.

If the firmware on Macs sends POST codes, they are most likely on the LPC bus, as I was not able to read them with the diagnostic card connected to the mini PCIe slot on my Mac Pro 3,1.

Macs have no user interface for changing firmware settings. They may however be stored in an easily accessible NVRAM variable. On my Mac Pro 3,1 the name of this variable is Setup-EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9. Each setting is stored as one byte in this 636 bytes long byte array.

The semantics of the bytes is defined is a IFR file that is also stored in the Mac Pro's firmware. The format of the IFR file is part of the EFI specification. In theory it would be possible to write a generic program that would serve as the configuration interface for any EFI computer. The program could be launched from the EFI shell, it would read the IFR file and dynamically create forms for all the various setup options. So far no one has made such a program publicly available.

In 2014 "donovan" created the Universal IFR Extractor that converts IFR files into a human readable format. A new version is maintained by the LongSoft team, who also maintain the UEFITool.

With the help of the human readable version of the IFR it is possible to edit the Setup variable directly. This method is explained in a post on the Win-Raid forum. In a post from February I explained how one would use it to send POST codes to the PCIe bus on a Mac Pro 3,1. One needs to change byte 0xB3 from 0x0 to 0x1. I have not tried this as I fear it might brick my Mac Pro. I was planning to first work out a method of restoring the firmware. Clearing NVRAM on boot will not restore the Setup variable. Only variables in the "Apple" namespace are cleared.

The IFR file on a Mac Pro 3,1 is odd. Even more curious is that @tsialex found the same file on his Mac Pro 5,1. It has a section named "Blackford configuration". Blackford is intel's name for the X5000 northbridge. The setup options are mitigations for the errata in the different steppings of the X5000 chip. I expected this same IFR file to exist in Mac Pro 2,1 firmware. I tried to look for it, but so far I have not been successful.

The first thing to do would be to look for a Setup-GUID-some-number... variable in the NVRAM. (I could not do it today. I do not have access to my Mac Pro 1,1, because I borrowed it to my cousin while I worked on her iMac. Hope to have it back on Monday.)

I tried to search the MP21 EFI image for the IFR file. @tsialex says that the GUID on his Mac Pro 5,1 is FC1BCDB0-7D31-49AA-936A-A4600D9DD083. I searched for the same GUID in the MP21 file. There is a file with the globally unique identifier, but it is a BIOS for the ATI X1900XT graphics card from June 15, 2007. (How can two things have the same globally unique identifier?) The file starts something like this:

Code:
113-A52027-107
R580 PCI_EXPRESS DDR3 A52027
X1900XT BIOS                                                  

YOU HAVE NOT CONNECTED THE POWER CABLE TO YOUR VIDEO CARD.
PLEASE REFER TO THE 'GETTING STARTED GUIDE' FOR PROPER HARDWARE INSTALLATION.
(C) 1988-2005, ATI Technologies Inc. ATOMBIOS
BK-ATI VER009.012.005.002.025551S3A52027.107350248 420598

More oddities follow. I searched for the word "Blackford", that I know exists in the Mac Pro 3,1 and 5,1 IFR file. I found a binary object module with humanly readable text in its .text segment. It is yet another BIOS with a configuration interface in three languages but it certainly was not meant for the Mac Pro. I searched for some of the longest strings.

Code:
Wake on LAN from S5
Determines the action taken when the system power is off and a PCI Power Management wake up event occurs

The Technical Product Specification from 2008 says that this exact text appears in the BIOS of Intel® S3000AH-series Server Boards.

Another string...
Code:
Max CPUID Value Limit
This should be enabled in order to boot legacy OSes that cannot support CPUs with extended CPUID functions
...can be found in the BIOS of the Shuttle® XPC from 2014. This page says it is related to running Windows 98 or XP on a Pentium 4 processor.

Another EFI module has a user interface for starting an EFI shell or running the Apple hardware test.

Code:
Internal EFI Shell
BootCurrent
BootPicker
EFImanufacturing-enter-picker
Netboot
DefaultImage
Netboot
DiagnosticsDriver%04xTimeout
WaitForRemoteauto-boot?target-mode
CapsuleUpdate
Databoot-signature
boot-image-key\.diagnostics\diags.efi

I tried to find other modules with text using the Unix strings command. It could not work as the Mac version does not allow the option for searching for texts in UTF-16 format. I opened the whole EFI image in a hex editor to see if there were any clusters of text. I could see nothing, as most of the EFI modules are compressed.

I am as confused as I was yesterday. Will continue tomorrow.

P.S. - The globally unique identifier FC1BCDB0-7D31-49AA-936A-A4600D9DD083 is defined in this C source file. It simply means an EFI section with a GUID and a CRC32 checksum.

About the ATI X1900XT shadow ROM: Early versions of Windows are reported to have problems with the Mac edition of the ATI X1900XT graphics card. People online are actually asking if they can flash the Mac card with the PC version of the BIOS. Apple may have fixed this with a firmware update at the same time they launched "Boot Camp" for Windows compatibility. Instead of reflashing the GPU they included the PC version of the option ROM in the Mac Pro EFI firmware. The Mac somehow shadows the EFI firmware with the PC firmware when booted into the Compatibility Support Module. This is results in users reporting different versions of the ATI X1900XT firmware in Windows and in Mac OS. Quote: "the ROM is reported as revision 113-A52027-202 (by Mac OS X), but WinXP and Vista report it as 113-A52027-107. WTF?"

None of this helps us solve the problem with Xeon 5400s, but it shows what kind of wormhole we are entering.
 
Last edited:
  • Like
Reactions: Larsvonhier

Petri Krohn

macrumors regular
Feb 15, 2019
100
107
Helsinki, Finland
Status August 11, 2020: We seem to have navigated the Pre-EFI Initialization part of the firmware and are now making fixes to two EFI DXE modules. Below are my latest fixes to SEC core.

The SEC core module uses the stack pointer ESP as a temporary storage for the masked CPUID value. (I guess this is OK as long as there in no stack in use. This part of the code contains no PUSH or POP calls.)
Code:
2ba:    b8 01 00 00 00          mov    eax,0x1
2bf:    0f a2                   cpuid
2c1:    25 ff 3f ff 0f          and    eax,0xfff3fff
2c6:    8b e0                   mov    esp,eax
2c8:    b9 8b 00 00 00          mov    ecx,0x8b
2cd:    0f 32                   rdmsr

On line 0x444 the stored value is accessed by moving the stack pointer back to EAX.
Code:
444:    8b c4                   mov    eax,esp
446:    24 f0                   and    al,0xf0
448:    3d f0 06 00 00          cmp    eax,0x6f0
44d:    0f 94 c0                sete   al
450:    0f b6 f8                movzx  edi,al
453:    0b ff                   or     edi,edi
455:    75 16                   jne    0x46d

And again on line 0x69d:
Code:
69d:    8b c4                   mov    eax,esp
69f:    24 f0                   and    al,0xf0
6a1:    3d f0 06 00 00          cmp    eax,0x6f0
6a6:    75 1a                   jne    0x6c2

(There is also a similar section where the stored CPUID is compared against 0xF60, the Netburst ID.)

This can be fixed by changing the AL mask from 0xF0 to 0x00 or 0x70.
 

Attachments

  • SEC core Petri CPUID fix v03.bin.zip
    2.4 KB · Views: 130

Larsvonhier

macrumors 65816
Aug 21, 2016
1,364
2,427
Germany, Black Forest
I managed to convert the SMC flash contents (MP2,1) to plain binary, so that now a disassembler can be used.
Even in ASCII there are some interesting aspects to see, as S0 to Sx transition, sleep/wake/hibernate stuff, wait-for-CPU, wait-for-reset etc., perhaps macro and PIN names and/or debug infos.

I´ll post the disassembly listing soon (have to use dosbox and a freeware x86 tool to do it, then paste the listing out somehow).
 

Attachments

  • SMC_2,1.bin.zip
    40.7 KB · Views: 111
  • Like
Reactions: Petri Krohn
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.