January 14, 2025
Introduction
Apple was one of the first manufacturers that started soldering its memory on their laptops. This has an effect on how the boot firmware handles its SPD configurations. With non-soldered ram the SPD configuration is stored on the memory modules themselves, with ram soldered the needed information is in the boot firmware. This brings a challenge when trying to install and boot with alternate firmware.
In this article we are going to look at how to extract to right information for memory management from a Macbook Pro 10,1 (A1398) and implement it in Coreboot, but the information should apply to similar macbooks from that era. Apple uses many different kinds of RAM chips in this model, as well as other macbooks. This makes it difficult to easily support a Macbook in Coreboot, since all of these different memory configurations have to be supported.
The Data
To be able to support the memory configuration, we would have to know what kind of memory is in this model. We will use a tool called “Inteltool” (part of the coreboot utils) to extract the information. To use inteltool on these macbooks it's easiest to boot from a Debian GNU/Linux Live USB and install the coreboot-utils though the apt package manager, copy the inteltool program from a different GNU/Linux system that has the coreboot-utils package installed or extract it directly from the coreboot-utils .deb package. When we run inteltool -m we will get a long output, but we will focus on the following part of the output:
/* CH0S0: 4096 MiB */ /* CH1S0: 4096 MiB */ /* SPD matching current mode: */ /* CH0S0 */ 00: 92 11 0b 03 03 00 00 09 03 52 01 08 0a 00 80 00 10: 6e 78 6e 32 6e 11 18 81 00 05 3c 3c 00 f0 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 06 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 /* CH1S0 */ 00: 92 11 0b 03 03 00 00 09 03 52 01 08 0a 00 80 00 10: 6e 78 6e 32 6e 11 18 81 00 05 3c 3c 00 f0 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 06 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Even though this is this is the exact SPD config of the modules, does not mean that it can boot with this configuration. We will get to this at a later part.
The early initialization
Before we go any further we will look at what is already supported. When we go to the repository we can look at the SPD configurations and the early_init.c. Which is currently this: (relevant part of) early_init.cstatic unsigned int get_spd_index(void)
{
const int spd_gpio_vector[] = {71, 70, 69, 68, -1};
int ramcfg = get_gpios(spd_gpio_vector);
const int spd_map[] = {-1, 0, -1, -1, -1, -1, 2, 1, -1, 2, -1, -1, -1, -1, -1, -1};
int spd_index = spd_map[ramcfg];
/*
* GPIO68 GPIO69 GPIO70 GPIO71 Memory Supported
* 0 0 0 0 4G Hynix 1600S No
* 0 0 0 1 1G Samsung 1600 Yes
* 0 0 1 0 4G Samsung 1600S No
* 0 0 1 1 1G Hynix 1600 No
* 0 1 0 0 4G Elpida 1600S No
* 0 1 0 1 2G Samsung 1600 No
* 0 1 1 0 2G Samsung 1333 Yes
* 0 1 1 1 2G Hynix 1600 Yes
* 1 0 0 0 4G Samsung 1600 No
* 1 0 0 1 4G Hynix 1600 Yes
* 1 0 1 0 2G Elpida 1600S No
* 1 0 1 1 2G Elpida 1600 No
* 1 1 0 0 4G Elpida 1600 No
* 1 1 0 1 2G Samsung 1600S No
* 1 1 1 0 2G Hynix 1600S No
*/
if (spd_index == -1) {
die("Unsupported memory, RAMCFG=%d. "
"Please contact the coreboot mailing list\n", ramcfg);
}
return spd_index;
}
Originally this information is extracted from the schematics of this
board (820-3332-a, page 5). It is possible to support RAM configuration
for boards that don't have schematics but it won't be possible to know
how many different configurations there are and what brand/speed chips
are connected to the GPIO values and SPD mappings.
Some memory configurations are already supported and are connnected to
an SPD map also in the repository. At this point there are only three
spd maps in the repository, even though we have 4 supported memory
configurations. How is that possible? Well in this case the model that
used 2G Samsung 1333 memory chips uses the same SPD map as the 4G hynix
1600. This seems very odd but is the case sometimes. It is also possible
the already existing naming scheme may not be entirely correct.
So how does our memory identify itself and how can we add the right SPD
config or maybe point to one that already exists? To find this out we go
to the next chapter: GPIO Values
GPIO Values
We can get all the SPD mappings there are, but how does the firmware know which one to pick for machine to boot? The Boot firmware will look at certain GPIO values that are present in the hardware to pick to right SPD mapping. As you can already see in the early_init.c, there are values for GPIO68, GPIO69, GPIO70 and GPIO71. A combination of 1s and 0s that will be unique for every memory configuration. Now we need to find out what the GPIO68-71 values are for our machine to look if it’s either already supported or support for what configuration we need to add. For this we need to run inteltool -g. Again we will get a long output but here is a snippet to focuses on the values we need:
gpiobase+0x0030: 0x13ff80fe (GPIO_USE_SEL2) gpiobase+0x0034: 0x1f04ffe2 (GP_IO_SEL2) gpiobase+0x0038: 0xfeaf9fc6 (GP_LVL2) gpiobase+0x003c: 0x00000000 (RESERVED) gpiobase+0x0040: 0x000006ff (GPIO_USE_SEL3) gpiobase+0x0044: 0x00000ff0 (GP_IO_SEL3) gpiobase+0x0048: 0x00000fe0 (GP_LVL3) gpiobase+0x004c: 0x00000000 (RESERVED)We need the record that includes the GPIO values for our memory. When we look at Intel Datasheets for chipsets from this era ( 13.10.16 GP_LVL3—GPIO Level for Input or Output 3 Register) . We can see the value GP_LVL3 included the GPIO64-75 values. Even though GPIO_USE_SEL3 and GPIO_IO_SEL3 also are related to these GPIO values, it does not include the right data for our RAM. So now that we know we need some values from GP_LVL3, we will look at how to extract them. GP_LVL3 has a hexidecimal value. To make it readable we will convert it to binary. When we convert “0x00000fe0” to binary we get “111111100000” Now each bit will refer to a GPIO value. Remember that we said this contained GPIO 64 to 75? Well that is exactly how the values correspond. To visualize it. Let’s put each bit to it’s respective GPIO value
GPIO75 = 1 GPIO74 = 1 GPIO73 = 1 GPIO72 = 1 GPIO71 = 1 GPIO70 = 1 GPIO69 = 1 GPIO68 = 0 GPIO67 = 0 GPIO66 = 0 GPIO65 = 0 GPIO64 = 0Now when we focus on GPIO68 to 71 have the following values: 0 1 1 1. At this point we can compare that to the the values present in early_init.c
* GPIO68 GPIO69 GPIO70 GPIO71 Memory Supported * 0 0 0 0 4G Hynix 1600S No * 0 0 0 1 1G Samsung 1600 Yes * 0 0 1 0 4G Samsung 1600S No * 0 0 1 1 1G Hynix 1600 No * 0 1 0 0 4G Elpida 1600S No * 0 1 0 1 2G Samsung 1600 No * 0 1 1 0 2G Samsung 1333 Yes * 0 1 1 1 2G Hynix 1600 Yes * 1 0 0 0 4G Samsung 1600 No * 1 0 0 1 4G Hynix 1600 Yes * 1 0 1 0 2G Elpida 1600S No * 1 0 1 1 2G Elpida 1600 No * 1 1 0 0 4G Elpida 1600 No * 1 1 0 1 2G Samsung 1600S No * 1 1 1 0 2G Hynix 1600S NoAs you can see the GPIO values 0 1 1 1 corresponds to 2G Hynix 1600 which is already supported. This is a quite common memory configuration and seems to be present in most (if not all) I7 8GB models. But for the sake of this exercise, let’s say it is not supported.
Supporting a new configuration
To support a new configuration you normally have to add the unsupported SPD mapping a new hex file, include it in the SPD makefile.mk and link to that file in the const int spd_map in early_init.c. Normally for us that would mean. We create /spd/2g_hynix_1600.spd.hex file. Copy the SPD information we extracted earlier with inteltool -m. Create a new line in spd/makefile.mk with the right filename and change the 8th value in const int spd_map from -1 (unsupported) to 1 (second SPD mapping). Sounds easy, right? Well unfortunately the SPD that we extracted will not work on this machine. Why?
Rank 1 mirroring
When we compare our extracted SPD map and compare it to the one in 2g_hynix_1600.spd.hex, we will see they do not correspond. This is because the memory uses Rank 1 mirroring. Rank 1 mirroring is a design choice and is not present in all memory configurations. For example the 1G Samsung 1600 memory does not use rank 1 mirroring. It may be possible to see which memory uses Rank mirroring and which doesn’t, either physically or in the software. But I haven’t found a conclusive way to find the right information. So it may be a case of trial and error for now. To see the difference between a rank mirrored configuration and without, look at the SPD mappings below:
2g hynix 1600 (rank 1 mirroring enabled) 92 11 0b 03 03 00 00 09 03 52 01 08 0a 00 80 00 6e 78 6e 32 6e 11 18 81 00 05 3c 3c 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2g hynix 1600 (rank 1 mirroring disabled) 92 11 0b 03 03 00 00 09 03 52 01 08 0a 00 80 00 6e 78 6e 32 6e 11 18 81 00 05 3c 3c 00 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00The only difference is that byte 63 is flipped. Without mirroring it has a value of 00 and with mirroring it has a value of 01. With DDR3 modules rank mirroring is always done with the 63rd byte. the following publication from simmtester describes it best:
Byte 63 Address Mapping from Edge Connector to DRAM
For ease of module PCB layout, sometimes “mirror” address mapping is used. “Mirror” address is to flip the address line sequence on the 2nd rank of the module. This byte describes the connection of edge connector pins for address bits to the corresponding input pins of the DDR3 SDRAMs.
Rank 1 Mapping Standard 00h Mirrored 01h
Last Words
RAM initialization has always been hard in Coreboot, but with soldered ram that doesn't provide the right information to the boot firmware it gets even more complicated. Hopefully this article will provide you with some insight on how this works. When you manage to support a new memory configuration yourself, you can follow ch1p's instructions in his blogpost "On the current state of coreboot on MacBooks" to compile and flash coreboot. Do not hesitate to contact me with any questions.
Updates
January 29, 2025:
Fixed some source and formatting errors and cleared up text about inteltool and and rank mirroring.
Sources
Relevant sources for this article:
https://ch1p.io/coreboot-macbook-support/ https://review.coreboot.org/c/coreboot/+/32673 https://review.coreboot.org/c/coreboot/+/32673/59/src/mainboard/apple/macbookpro10_1/early_init.c https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf
Both Ch1p and nic3 from the coreboot/libreboot community were a huge help to understand this material. Couldn't have done it without them.
Contact information
This project is funded by nlnet and NGI0 Entrust. Project page.