Updating a Mac (Pro)s CPU Microcode

[Petri Krohn]

Sorry for the late reply. I have spent the last year working on a quantum algorithm.

I went into more testing with mix of CPUs in the machine, it boots, but Lion crashes and I'm assuming it's because the systems sees first the E5440 and similar as when under Debian I get some time to time a "illegal instructions" message until I disable the 2 cores of the 5150.
Overall that means to me that the 5000x has no issues with managing the E5440.

This is the experiment I have been wanting to do for a long time, but have been too lazy to try it out myself. Yes, it shows that the Mac Pro 1,1 will work with a Harpertown 5400 series processor once it has booted. Our problem must thus be in the firmware, not the hardware.

I've ran a geekbench after disabling the 5150, but results are very bad :MP1,1-E5440 geekbench5

One reason for the low score might be the mismatch in the processor speeds. Your CPU was only running at 2.19 GHz. A better combination to try could be the 3 GHz X5365 and E5450.

In addition and until a modded ROM works with the E5440, the 5150 cores have to be disabled (not sure how in the EFI Shell) before trying to boot OS X

It may be possible to run macOS in a virtual machine with only the Harpertown cores allocated.

***

Time flies and this project is not making much progress. I have thus finally decided to "upgrade" one of my two Mac Pro 1,1s with a new motherboard. I found that the Chinese Machinist MR9A Pro X99 motherboard is a perfect fit for the Mac Pro case. It provides 40 PCIe 3.0 lanes but uses only six PCIe slots instead of the standard seven of ATX motherboards. (I ordered one from AliExpress for 69€ and it arrived in under two weeks.) I will soon be taking apart my Mac Pro. This will give me a chance to study the logic board more closely and test it on a test bench.

While searching for information on Intel's HD Audio interface and the Mac Pro front panel, I also made some new discoveries about the LPC bus and its connectors. I will write more in another post. I have also updated my old post on the topic from 2020.

I ordered a POST diagnostic card from AliExpress and installed it in my Mac Pro 1,1 in the mini PCIe slot in place of the Wifi card. I was hoping it would display something during the boot process. Unfortunately the card showed nothing. It only displayed a single zero when power was turned on and stayed that way...

 

[Larsvonhier]

If there was a way to get 5400 series cpu's to work on cMp 1,1 / 2,1.
I think it might involve differences in the voltage regulators between [1,1 / 2,1] and [3,1].

I don't have access to an image of the 3,1 board so i can't verify differences.
I have a 1,1 board laying around so i can send off pictures of the chips if someone wants try comparing part differences that might relate to getting 5400 series to boot.

VRMs: Been there, done that. See here.

 

[Larsvonhier]

I went into more testing with mix of CPUs in the machine, it boots, but Lion crashes and I'm assuming it's because the systems sees first the E5440 and similar as when under Debian I get some time to time a "illegal instructions" message until I disable the 2 cores of the 5150.
Overall that means to me that the 5000x has no issues with managing the E5440, also I've ran a geekbench after disabling the 5150, but results are very bad :MP1,1-E5440 geekbench5
I tend to think that what's missing to be able to use anything else that natively supported CPUs, is in addition to the microcode in the ROM, part of the drivers from the MP3,1 ROM & not touching the SMC, but I might be completely wrong...
To avoid bricking the box I guess going through the earlier discussion > EFI Shell thingies and start loading some of the MP3,1 drivers for the EFI shell might help to find what's missing in our MP2,1 ROM.
In addition and until a modded ROM works with the E5440, the 5150 cores have to be disabled (not sure how in the EFI Shell) before trying to boot OS X
I'm attaching the /proc/cpuinfo and the output of lscpu after disabling the 5150 cores for curiosity.

Just saw this by the reply of Petri Krohn and as I still have the bench MP2,1 mockup here, I tested this combination:
X5450 in socket A
5150 in socket B
Firmware with microcode addition for 10676 / 1067A Xeons.

Unfortunately, with this I do not have successful POST, status LED A goes red.

What was your exact setup for booting Linux (and crash-booting 10.7.x) ?

edit: found a pair of E5440 Xeons and will test with one of them on monday.

 

[Petri Krohn]

We need to get the LPC bus working!

LCP or Low Pin Count is a 4 bit, 33.3 MHz version of IBM PC AT's 16 bit ISA running at 8,33 MHz.

Most systems and interfaces on a modern PC, including the memory and the PCIe lanes need to be initialized by the pre-boot code in the firmware, but the LPC is and must be functional from the moment the computer is powered on. If it was not, there would be no way for the processor to access the firmware code it needs to execute. In the Mac Pro 1,1 - 3,1 the boot ROM flash memory chip is located on the LPC bus.

Accessing the LPC bus provides us with two facilities that are vital for this project; monitoring the boot code and writing new firmware to a bricked Mac Pro. Other uses for the LPC bus are connecting a TPM module for Windows 11 compatibility and even extending the PC with a 16-bit ISA bus for DOS gaming.

Note, that the flash memory chip on the Mac Pro in the TSOP-40 package also has a parallel interface for rapid factory programming. This interface can only be used offline, before soldering the chip to the motherboard.

The Mac Pro 1,1 logic board has a 30-pin connector marked "LPC" with a known pinout, but acquiring the needed adapter is beyond the 50€ budget I have allocated for this project.

When looking through information on the HD Audio interface, I came across this Intel document from 2005:

Front Panel I/O Connectivity Design Guide (archived PDF)

The last six pages of the document define the LPC (Low Pin Count) Debug Connector. The connector used is a regular 16-pin, 2,54 mm pitch "DuPont" header. I looked through my collection of photos of the Mac Pro 1,1 and Mac Pro 3,1 logic boards to see if they had holes for this connector. On the Mac Pro 3,1 I found the 16-hole pattern right where the Mac Pro 1,1 has the 30-pin LPC connector. On the Mac Pro 1,1 I only find a 6-hole header pattern in this location.

Unfortunately, on the Mac Pro 3,1 the header (marked J79) is unlikely to match the pinout specified by Intel. Pin 10 has a power delivery trace connected to it, possibly somehow related to the unpopulated 6 volt regulator situated next to the pin header. In the Intel pinout pin 10 should be LAD1#. The five lowest numbered odd pins have signal traces coming to them, connected via unpopulated resistors R247-R251. Intel says pin 9 should be VCC3.

TIP: download the photos and magnify them before inspecting them.

On the Mac Pro 1,1 the J6A1 header only has six pins. The Wikipedia page on the Low Pin Count bus says seven pins are needed. However, the documentation for POST cards says that the reset signal LRESET# is not needed for debugging. Wikipedia also says that LRESET# may be connected to PCIRST# on the PCI bus. I suspect PCIRST# is the same signal as PERST# on the PCIe bus. If we actually need LRESET# for programming the flash, then we may be able to use the PERST# pin on one of the PCIe slots.

From the photograph of the Mac Pro 1,1 logic board, we can see that the LPC connector likely matches the pinout of the other Apple 30-pin LPC+ connectors I posted earlier. Pins 6, 12, 28 sit next to through-hole vias that are likely grounded, as they should be. I cannot see any direct traces between the LPC pins of the 30-pin connector and the 6-pin header. Pins 1-4 of the header are connected to VCC through 10 kΩ resistors in resistor array RP6A1. This is compatible with the pins being LAD0-3# data lines.

My best guess for the pinout of the J6A1 header is the following:

1. LAD3# (LPC_AD<3>)
2. LAD2# (LPC_AD<2>)
3. LAD1# (LPC_AD<1>)
4. LAD0# (LPC_AD<0>)
5. LFRAME# (LPC_FRAME_L)
6. LCLK (PCI_CLK)

One way to confirm this pinout is to insert a probe between leads 8 and 10 of the 30-pin LPC connector and see if they are connected to any of the pins on J6A1. These pins are LAD2# and LAD3# of the Mac LPC bus.

LPC+ connector of a 2007 17-inch Macbook Pro.

***

I will write another post on POST codes and Port 80h.

(Off topic: The correct way to build a modern computer is to connect a 8-pin boot ROM chip directly to the CPU via the 4-pin SPI bus. Instead, Intel and AMD require the customer to also buy a south bridge chipset, that mainly provides legacy interfaces, unneeded in a state-of-the-art PC. The real purpose of the chipset is to lock and disable features that already exist on the CPU. A form of Digital Restrictions Management.)

Update, July 7, 2024: I squeezed a multimeter inside my Mac Pro and measured the conductivity between the the 30-pin LPC+ connector and the 6-pin header. The header is connected to the SMC pins of the LPC+ connector. It is not related to the LPC bus.

I cannot tell the exact pinout of the header, as I could only run the probe along the leads on the outside of the connector. My experiment however makes me more convinced that the connector follows the pinout of the LPC+ connector pictured above.

 

[Larsvonhier]

For completeness (and perhaps inspiration) here is the data sheet for a LPC-to-ISA chip.
Very cool finding, Petri!

 

[Petri Krohn]

Back to the drawing board. We need to get the 30-pin LPC+ connector working.

But first, an interesting video about the LPC bus and POST cards. Note the way fly wires are soldered directly to LPC pads on the logic board.

BIOS POST Card with the Raspberry Pi Pico and LPC bus explained. Ep.1

This project has stood still for four years because no one has bothered or managed to create an adapter for the LPC+ connector on the Mac Pro. For that we need the original Kyocera AVX connector and a 0.50 mm pitch breakout board.

I did a search for 0.50 mm pitch breakout boards four years ago, and found that they were difficult to obtain. I did the same this morning and got somewhat better results. Most 0.50 mm pitch PCBs are for flat cables with only one row of solder pads. China produces some 24 standard varieties of breakout boards, which are available on AliExpress and eBay for 15¢ a piece. Only one of these boards has any use in our project.

The simplest and cheapest way to create the adapter is to use the common double-sided SOP10 / SOT23 board. (Photo from Addicore)

The board only has 10 pins, but the LPC pins in the 30-pin LPC+ connector are all located between pin 3 and 12. The other 20 leads of the Kyocera connector can be left unconnected. The extra benefit of this breakout is the small size, it will not touch the PCIe connector right next to the LPC+ connector on the logic board. AliExpress offers ten pieces for €1.62 with free and tracked "Choice" shipping, if you order stuff for more than 10 euros. (With this shipping method stuff arrives in about 2 weeks. Any shipping method that does not include tracking, leaves China in a week and then spends the next two months in European EU post offices.)

A technically more advanced option is provided by a Marcin Kubis of KubisElectronics of Poland. He sells some 160 different kinds of breakout boards, at least 40 of them have 0.50 mm pitch. Here is one for a TSSOP30 component or connector. Note, that on this board the pin headers have a miniature 1.27 mm pitch. There is also another version available for normal 2.54 mm pitch pin headers.



The boards cost $1.80 (€) to $2.25 (€) each on eBay, with 8€ for shipping to the EU. Buying on eBay is a bit difficult. KubisElectronics has twelve different eBay shops for different counties. eBay refuses to show you items that are not in your local shop. The only shop that offers descriptions in English is the UK shop, but they only ship to the UK. The Spanish shop ships to Finland.

The items are also listed on Etsy. This Etsy page list all items that have a 0.50 mm pitch. But beware, Etsy will put you in a Captcha loop if you click on anything.

The connector

The exact part number for the plug needed to connect to the Mac Pro LPC connector is 145047030950829+. The part is available from Digikey in the US and from Mouser in Europe. The price from Mouser is 1,02 € in quantities of one. (I do not know what the minimum order from Mouser is.)

The part was 1,02€ four years ago, now it is 1,81€ each. Both Mouser and Digikey offer free shipping if one orders for over 50€ / $60, otherwise the shipping fee for Mouser is 18€ / $22 in Europe. I should have ordered the part four years ago, but never needed stuff for 50 euros. Instead, I always end up looking for cheaper stuff on AliExpress. If anyone regularly orders stuff from Mouser or Digikey, get a few of those Kyocera connectors.

Update: I checked, if the SEC core module actually writes anything to port 80h (0x80). There are some 10 calls to the x86 OUT instruction. These calls may be related to hardware initialization. The ports written to are 0xcf8, 0xcf9, and 0xcfc. Nothing is written to port 0x80 or any other ports listened to by any POST card. For an example of the calls see the first assembly listing photo in my old post.

We may need to modify the Apple code to add our code to write to the POST card. I will write more on this tomorrow.

 

[Larsvonhier]

Will add a few pcs. of this part with my next order at digikey or mouser. (We order frequently there for various customer projects, so the moq is not a problem).

 

[Larsvonhier]

Ok, I can confirm:
5150 in socket B and 5440 in socket A does successful POST!

As I can switch between two sets of firmware, I can also confirm that 10676/A is needed and does the trick in comparison to the "original" MP1.1 and 2.1 firmware that does lack the needed microcode.

I´m now getting an LPC POST-code card that can be connected directly to the 30pin socket (and hopefully does show more there than while connected to PCIe/Mini-PCIe etc.). Even if not, there is plenty of chance to see what´s going on by connecting a 4bit digital scope or Raspi-Zero for decoding. Good thing is now we can look for the differences on firing up the Xeon mix and two 5440 - and get more insight then...

 

[Petri Krohn]

Question to @Larsvonhier: Did we successfully pass the SEC_core stage in our experiments with the modified code in 2020? Did the Mac sound the beep! if you used E5440s and removed the memory risers?

I am now going through the SEC_core module, figuring out how to add OUT instructions to send POST codes to port 80h. As far as I can see, the the Mac firmware does not POST anything.

Update: Reworded question to be more specific about 2020 testing.

 

[Larsvonhier]

As for the 30pin connector: At least, the four GND and two supply pins are matching to the MacBook pinout. I checked on a bare MP1.1 board here.
So it´s highly probable that the rest is close or even identically wired.

 

[Larsvonhier]

Question to @Larsvonhier: Did we successfully pass the SEC_core stage? Does the Mac sound the beep! if we use E5440s and remove the memory risers?

I am now going through the SEC_core module, figuring out how to add OUT instructions to send POST codes to port 80h. As far as I can see, the the Mac firmware does not POST anything.

Yes, the fanfare after POST is there. RAM status LEDs go from 4x red to out (ok). Will check with a suitable GPU with boot screen what we get.

 

[Petri Krohn]

SEC core Hello World program

To see the greeting, place your POST card or your Mac upside down.

start: mov al, 0x80 out 0x34, al ; Writes the nibbles 3 and 4 to hardware port 80h.
mov ecx 100000000 loop $ out 0x77, al mov ecx 100000000 ; A 100 millisecond pause between posts, to make the text readable.
loop $ ; loop decrements ecx by one.
out 0x10, al mov ecx 100000000 loop $ ; "$" is the start address of the current instruction, loop jumps to itself.
jmp start

The code should produce hELLO! repeated over and over again on the POST card display. If this code was inserted at the start of SEC_core, the computer would never do anything else.

 

[Larsvonhier]

Let´s see once I receive the POST status card. Will take a while from China ;-)

 

[Larsvonhier]

And... action!

 

[Larsvonhier]

Memtest86 boots and shows the 5440 (but does not do "multi-CPU" because of mismatch).
And a real surprise is there also: The PC2-6400 RAM is initialized correctly by SEC for 800MHz clock, something the original MP1,1 and 2,1 never showed (the firmware/Xeon combination only clocked such RAM with 667MHz).

 

[Larsvonhier]

Also, rEFInd and rEFIt boot. These might also be a good starting point for testing.
(The AHT for Mac Pro 3,1 does not even start booting - would be interesting to see if the one for MP2,1 or 1,1 does?)

 

[Larsvonhier]

AHT "for all machinekind" can be found here.
The right version boots and reports, well, things... Otherwise not too interesting.

 

[Larsvonhier]

32bit Linux (LMDE 6) boots after looong time (USB 2.0 stick), but is quite performant then!
Saw no "illegal opcode warnings" but surfing web with Firefox often crashed the web page rendering. This might be a sign of mixed SSE4 capable an non-capable cores...

 

[Larsvonhier]

Combo 5150 with X5450 does not POST.
E5462 also not successful, but that one has a 1600MHz bus instead of 1333MHz, so no wonder.
Will test more combinations (4 core / 4 core) tomorrow.
Update: 5160 and E5440 POST successfully. Various tools still show 2.86GHz of the E5440 and not the 3 GHz of the 5160.
Tried also the 5160 and X5450 (both 3GHz) combo, no luck -> no POST.

Meanwhile I removed the insulation of the taped-off pins for bus multiplier / PLL from one of the E5440 here, both (taped and not) POST and boot into LMDE 6. Don´t see performance differences, but will do some benchmarks lateron.

 

[Petri Krohn]

Writing POST codes to port 80h

Once we get LPC working, we have two ways to proceed. I will describe the better and more general one in a separate post.

As far as I can see, the Mac Pro firmware does not send POST codes to port 80h. We would need to insert our own out <code>, al instructions into the firmware. The instructions need space. To get space we need to remove something or move around code.

The firmware now has superfluous CPUID checks and code for Pentium 4 based "Dempsey" Xeons and engineering samples of Woodcrest Xeons, both unneeded for our use case. These can be removed and replaced with no-ops or debug code. At least in the SEC_core module, I believe, I can move around some non-nested code without disturbing any jump targets. Larger rearrangements would require recalculating some jump targets, which can easily lead to a bricked machine.

The other option is to disassemble the code, make changes and reassemble. Putting the package back together is not trivial. Creating a working toolchain may be beyond my capabilities and resources.

(Why port 80h and not port 0x80? The 80h is the 1980s way of indicating hexadecimal numbers. Today the 0x notation is more common. I believe assemblers understand both.)

Update 11 July 2024: Here are two documents that describe the POST codes output by modern UEFI firmware. AMI BIOS via SuperMicro and InsydeH20. The range 0x00 to 0x0F is reserved for SEC core.

 

[Larsvonhier]

The third option would be to sniff the LPC lines, decode whats happening during init and possibly microcode transfer at an early stage. Comparison between stuck POST and succesful POST could give a clue. There are some interesting Raspi-Zero projects covering the LPC sniffing topic.

We circumvented the danger of bricking our machine(s) by double-banking the flash, so we can always switch back to the working setup. I can share in detail what we did to achieve this if anyone is interested.

The only obstacle here is that the turnaround times for testing new firmware variants or "creations" is in the 10min. range (due to first booting the known good state, possibly swap back to 1-2x 5150 Xeons, flash the test-firmware, power down, put in target XEON(s), try to power on, power off, go back to beginning). No problem as long as we know what we´re doing or have a clear goal of what to test, but in 2020 that was more looking for the needle in the haystack...

I asked in the "Sonoma on unsupported machines" thread if by modifying some Open Core config we could de-activate single cores or a whole processor. Perhaps some OC insider jumps in to help there?
(The idea here is to possibly allow just the 5440 booting into some macOS. I know that we still need a 32bit EFI OS system or a workaround like "SFOTT" that gave us up to OS X El Capitan on the MP1,1 and 2,1).

 

[Petri Krohn]

Tracing firmware execution with Pico LPC sniffer

The third option would be to sniff the LPC lines, decode whats happening during init and possibly microcode transfer at an early stage. Comparison between stuck POST and succesful POST could give a clue. There are some interesting Raspi-Zero projects covering the LPC sniffing topic.

This is actually my second option.

The LPC firmware interface reads the ROM in 128-byte "firmware read cycles". We can sniff the LPC bus and record the address of each firmware read. This gives us a code coverage mapping of the firmware execution. Using the ROM image file and UEFITool we can find the GUID and humanly readable name of each EFI and PEI module the execution has reached. We can even see the address of the last block reached.

Yes, the Raspberry Pico is truly amazing! Here is an interesting video on its use for LPC sniffing. Unfortunately most LPC sniffing projects only seem to be interested in cracking Microsoft's Bitlocker.

Breaking Bitlocker - Bypassing the Windows Disk Encryption

Each firmware read cycle takes 273 clock ticks at 33 MHz. This would give us 8.2 microseconds to store the address value.

If the Raspberry Pico runs out of memory, we can use a less precise resolution. Trim the least significant bits of the address, see if it is the same as the previous address block and store the new address only if it differs.

 

[Larsvonhier]

Yes, that´s what we had in mind since 2020. Before knowing about the LPC functionality, we had envisioned some flash replacement add-on PCB (self made) with some sort of FPGA on it and dual-ported RAM and USB interface to quickly fill in new firmware, emulate the flash and trace the invoked addresses while power-up to see exactly to what extent in which module (SEC, PEI etc.) the process would run.
Now it seems much easier with the PICO connected to the LPC.
Firmware side on the PICO should not be a problem, we have enthusiastic support here in the office... ;-)

So let´s get the 30pin connector (perhaps we can do without the breakout PCB and connect those few wires directly) and the PICO. But first we´ll have a look at the LPC-PICO firmware we can possibly build on and estimate the effort for setting up a sniffer we could use.
If we´re lucky, we could possibly transfer new firmware images to the PICO (via USB mass storage profile) and inject in real time (flash disabled of course)? Don´t know about the resources needed (both mem capacity and decode/inject speed).
Edit: PICO is too small for that, but other boards (STM32 etc.) could do the trick.

 

[Petri Krohn]

The 1980s called. They want their POST card back

One way to access the LPC bus would be to solder jump wires directly to the pins of the M50FW016 flash memory chip. Unfortunately, it has the same 0.50 mm pitch as the LPC connector, but at least the pins are easier to access. Another trick would be to route these wires to the undocumented "LPC" pins on the WiFi miniPCIe connector. We could then use the Chinese miniPCIe POST card for debugging, or better yet, create miniPCIe shield for the Raspberry Pi Pico and use it to sniff the LPC bus.

Set up an easy-access "eval board" also, with a dual Boot-Flash selector switch that makes it easy to dare to flash non-sense configurations like a 3,1 flash content to a 2,1 machine
View attachment 936712

The undocumented early 2000s pinout for the LPC bus on a miniPCIe connector uses the even pins from 8 to 16 plus pins 17 and 19 for LPC signaling. On your photo we can see that pins 10, 12, 14, and 16 are connected to vias. As these are likely through-hole vias, I suspect the are grounded. It should be possible to cut the traces to isolate the pins.

The POST card I used in the above photo is model ST8675 made by Shenzhen Sintech Electronic of China. Their web page listing their debug products was last updated in 2008. The links to documentation no longer work.

I found a few copy-paste versions of the user manual online. This version mentions IBM laptops, like the Thinkpad T60/61 and R60/61. Page 38 defines the pinout used by "most" laptop makers:

• 8: LFRAME
• 10: LAD3
• 12: LAD2
• 14: LAD1
• 16: LAD0
• 17: LRST
• 19: LCLK

A shield PCB that would connect the LPC pins of the PCIe connector to seven pins of a Raspberry Pi Pico might be of general interest. Should we ask the coreboot community to design one? Or should I ask ChatGPT to output the Gerber files?

Update July 12, 2024: I started wondering how Apple actually connected the unused LPC/SIM pins on the mini PCIe connector and scanned through my collection of Macbook and iMac schematics from 2006 to 2007 and found that in the iMacs they are left unconnected ("NC"). Yet, on the Mac Pro 1,1 they are connected somewhere!

2006 iMac:


2007 iMac:


I also found some other interesting stuff. The 2007 Macbook Pro has a strap pin (GNT0#) that determines, if the Mac loads the boot BIOS from LPC or from SPI ROM. Intel describes the function in this document from 2008:

Firmware Hub to SPI Flash Conversion

This page from the 2007 iMac schematic defines how to connect the CPU test pins for a Merom Core 2 Duo CPU.

 

[Larsvonhier]

Found that the signals of interest on the 30pin LPC connector are routed to an unpolulated 28pin IC (U5A2) with a much better/accessible pin density. See PDF for pinout.

(The U5A2 might have been some kind of TPM chip as on pins 13 & 14 a crystal would have been connected, also not populated on the board)*

So we have the following pinout on the TSSO28 footprint:
17 - LPC_AD<3>
20 - LPC_AD<2>
21 - PCI_CLK33M_LPCPLUS (note: disconnected from the clock source by missing resistor R6A1, probably 68R. That value is used to decouple pin 4 of the LPC connector)
22 - LPC_FRAME_L
23 - LPC_AD<1>
26 - LPC_AD<0>

Sidenote: LINDACARD_GPIO is used by cards that connect to the LPC port on other machines (MacBook/Pro) to indicate alternative boot source instead of the onboard flash. It is tied to GND with 100k pulldown resistor (R6A4). Quick test pulling it to 3v3 does not change anything, Mac Pro still boots. Perhaps other signals involved to actually do the switch?

* edit: Yes, this is the footprint of a TPM chip. Found this here: