Updating a Mac (Pro)s CPU Microcode

[Larsvonhier]

The FWH (firmware hub) flash chip M50FW016 holding the MP1,1 and MP2,1 firmware also "talks" LPC and its protocol is defined in this data sheet. All needed LPC signals are there as well. There is a control pin that switches between classic parallel flash (address / data) and FWH (LPC) mode. I´d guess it´s permanently driven for LPC comm. fashion. Will measure it soon to confirm.

So we now know how to bus-snoop in detail! ;-)

 

[Petri Krohn]

What is a Linda Card?

I looked at the references to the "Linda Card" in the 2006-2007 schematic diagrams. The name of the card may be a reference to Linda Dunn, who started at Apple as a summer intern in 2005. Her name appears last among the six or seven designers mentioned in some of the schematics, so guess her role would be in designing auxiliary systems related to programming and hardware testing.

One of the pins on the LPC+ connector is marked LINDACARD_GPIO. The line is connected to one of the GPIO pins of the ICH7/ICH8 southbridge. The Linda Card evidently signals its presence by pulling the line high. The schematics suggest the line may also serve the function of SMBALLERT and SV_SET_UP.

I searched Google for any information about the purpose of the Linda Card in Macs. I found only one public reference to a Linda Card made by Apple. It is in the block diagram on page 151 of the service manual for the 20-inch iMac from Late 2006.

 Service Source - iMac (20-inch Late 2006) — 13 December 2007

Interestingly, the iMac block diagram seems to show that the 2006 iMac has a TPM 1.2 module. The document also lists several optional systems that could be connected to the LPC bus, evidently using the LPC+ connector.

"Linda card"
Override ROM,
Port 80,
serial port access

"Port 80" is likely a POST card listening to port 80h. If so, this would indicate that the 2006 iMac sends POST codes to the LPC bus.

The "Override ROM" is likely a reference to a Matt Card, that is commonly used to unlock stolen Macbooks. Photos of the Matt cards show that they use 8-pin SPI ROM chip. This is strange, as the LPC+ connectors do not carry the SPI bus. (Maybe this has changed in 2010s Macs.)

The iMac block diagram shows that the BOOT ROM is connected to the ICH7 southbridge via a SPI bus. Would it be possible to override the SPI boot ROM with a LPC ROM? How about vice versa?

 

[Petri Krohn]

I have gone through my last version on the SEC core module from 2020. One "feature" of my code is that it will never load a microcode update for Harpertown 5400 CPUs (CPUIDs 0x10676 and 0x1067A), even if one is included in the firmware image.

In the original version of SEC core the CPUID in register eax is masked with the bit vector 0xfff3fff. In my modified version of the module I use the mask 0xfff. For Clovertowns this makes no difference, as they do not have an Extended Family or Model ID. For Harpertowns the Extended Model ID is 0x10.

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.)

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
...

On line 0x444 the stored value is accessed by moving the stack pointer back to EAX.

444:    8b c4                   mov    eax,esp
446:    24 f0                   and    al,0xf0
448:    3d f0 06 00 00          cmp    eax,0x6f0
...

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

The SEC core module is the first part of the firmware to be executed. Address 0x2b0 seems to be the entry point into module. The first thing the code does is load the microcode update. It scans through the microcode table and checks if they have a matching CPUID.

The code also stores the masked CPUID in the stack pointer register to be reused later in the code. In these later uses the CPUID is only masked by the lowest 8 bits (al) of the A register. This mask removes the stepping information. To achieve the same behavior for both Harpertowns and Clovertowns I would have to also mask out the Extended Model ID. This is not possible without moving or relocating the code, as the AND operation is only two bytes long.

One way to fix the code would be to remove and NO-OP all the code related to P4 Dempseys. Then there would be no need for these CPUID checks. This would also free up space to output POST codes to the LPC bus. On the other hand, I do not believe loading microcode updates is necessary to boot. The operating system will update the microcodes anyway.

To proceed, we need to find out if the boot process with Harpertowns clears SEC core. Only if it fails, should we tweak SEC core again.

 

[Matthew071998]

I recently bought a Mac Pro 6.1 and upgraded it to a 2667v2 and 64gb of ram. This got me back in the Apple scene.
I needed a mac to repair a iMac (upgraded to ssd but bootrom wasn't updated) I was checking everymac and I saw that the Macbook 2.1 (MA701LL/A) (A1181 (EMC 2121)) has a 32bit efi and the 2.1 (MB061LL/A) (A1181 (EMC 2139)) has a 64 efi. But the bootrom file is the same for both. Is this information correct? That would theorical mean that 32bit efi is updatable to a 64 bit.
Also the Macmini 1.1 (32bit efi) can be upgraded to a Macmini 2.1. I was wondering if it also goes to 64bit efi.

If the changes could be brought over to a MP1.1.

This would mean that the MP1.1/2.1 could run newer OSes (With some patches to remove other requirements)

 

[tsialex]

I recently bought a Mac Pro 6.1 and upgraded it to a 2667v2 and 64gb of ram. This got me back in the Apple scene.
I needed a mac to repair a iMac (upgraded to ssd but bootrom wasn't updated) I was checking everymac and I saw that the Macbook 2.1 (MA701LL/A) (A1181 (EMC 2121)) has a 32bit efi and the 2.1 (MB061LL/A) (A1181 (EMC 2139)) has a 64 efi. But the bootrom file is the same for both. Is this information correct?

Both are EFI32 and can only address 4GB total of RAM, this info is not correct. While the CPU of the later model is 64bits, the chipset and EFI are still 32bits.

That would theorical mean that 32bit efi is updatable to a 64 bit.

Nope.

Also the Macmini 1.1 (32bit efi) can be upgraded to a Macmini 2.1. I was wondering if it also goes to 64bit efi.

Only MacMini3,1 is EFI64.

If the changes could be brought over to a MP1.1.

This would mean that the MP1.1/2.1 could run newer OSes (With some patches to remove other requirements)

MacPro1,1/2,1 can’t run newer MacOS releases after ElCapitan essentially because the CPU does not support SSE4.1 and you can’t upgrade it to one that supports it.

 

[miko88]

Hello everyone! Is there any news? I am closely following the developments of this fantastic project. I am a mac pro 2.1 owner

 

[KestiriX]

its really interesting thread ngl, nice to see people trying to give those "coffe tables" more power.

 

[miko88]

The project is dead?

 

[jlawsonphill]

Both are EFI32 and can only address 4GB total of RAM, this info is not correct. While the CPU of the later model is 64bits, the chipset and EFI are still 32bits.



Nope.



Only MacMini3,1 is EFI64.



MacPro1,1/2,1 can’t run newer MacOS releases after ElCapitan essentially because the CPU does not support SSE4.1 and you can’t upgrade it to one that supports it.

That’s what this thread is about.. changing the microcode so these machines can run newer chips…

 

[pc297]

Anyone seen this? The OP in the following post is currently developing a patched kernel including SSE4.1 emulation for AMD K8s and he's tantalisingly close:

[AMD] Mojave 10.14.x - Test emulator including SSE4.1 instruction set - For older K8 - K10 and K15 FAMILY CPUs

Who among you still has an old AMD computer with a "K8, K10, or K15 CPU-FAMILY" and coincidentally also has a freshly installed macOS Mojave 10.14.6 on the internal or external hard drive to test a new kernel? If you have any questions about which CPUs we are talking about, you can find the appro...

www.insanelymac.com