# mmga: Make MacBook Great Again

**mmga** is a script to help flashing coreboot on some MacBook Air and Pro
models without using external SPI programmer. See
[this blog post](https://ch1p.io/coreboot-macbook-internal-flashing/) on how to
do the same manually.

### Supported devices

As of time of writing, following devices are supported in coreboot. Other models
might be supported in future.

* MacBook Pro 8,1 (13'' Early 2011) (`macbookpro8_1`)
* MacBook Pro 10,1 (15'' Mid 2012 Retina) (`macbookpro10_1`)
* MacBook Air 5,2 (13'' Mid 2012) (`macbookair5_2`)
* MacBook Air 4,2 (13'' Mid 2011) (`macbookair4_2`).
  
  **Attention!** This model hasn't been tested by me, simply because
  I don't have it. There were reports that it doesn't work, and by the nature of
  those reports I suggest that coreboot port for MBA 4,2 is somehow broken.
  Please don't try to use mmga on 4,2 until it's fixed or confirmed to work.

iMac 13,1 is a candidate for support too, but [coreboot port](https://review.coreboot.org/c/coreboot/+/38883)
for this device is not actively maintained at the moment and it may fail to build.
I'll add iMac 13,1 support later when it's fixed.

### System requirements

* Recent Linux distribution booted with `iomem=relaxed` kernel parameter
  (required for internal programmer to work);
* Build dependencies. Here's a list for Debian-based distros:
    ```
    # apt install bison build-essential curl flex git gnat libncurses5-dev m4 zlib1g-dev make libpci-dev libusb-1.0-0-dev
    ```

    If you plan to use GRUB2 as a payload:
    ```
    # apt install libfreetype-dev unifont
    ```

    On other distros package names might differ. Be sure to install **gnat**
    prior to building coreboot toolchain.

### Building flashrom

First of all, grab recent flashrom sources and build it:
```
$ git clone https://review.coreboot.org/flashrom.git && cd flashrom
$ make
```

Optionally, install it to `/usr/local/sbin`:
```
$ sudo make install
```

## How it works

The firmware of the devices covered by this project is stored on SPI chip. It
consists of various regions: `fd` (Flash Descriptor), `me` (Intel ME) and `bios`
(BIOS, or Apple EFI). Sometimes there are more regions, for example there may be
`gbe` region for Gigabit Ethernet or `ec` region with EC firmware, but for now,
let's focus on our MacBooks.

The most important region in context of this story is `fd`, the Intel Flash
Descriptor.

The Intel Flash Descriptor is a data structure of fixed size (4KB) stored on
the flash chip (resides in `0x0000-0x0fff`), that contains various information
such as space allocated for each region on the flash, access permissions, some
chipset configuration and more. In particular, it contains access permissions
for `fd` and `me` regions.

This is the flash chip layout used in MacBook Air 5,2 (which has 8 MiB flash chip).
It can be extracted from stock ROM image with `ifdtool`:
```
00000000:00000fff fd
00190000:007fffff bios
00001000:0018ffff me
```

Normally, the `fd` and `me` regions should be read-only in production, but this
is not the case with MacBooks. Apparently, Apple's "Think Different" thing
applies to firmware security as well.

Instead, they decided to use SPI Protected Range Registers (PR0-PR4) to set
protection over `fd`, but here they failed again. Due to a bug (I hope),
`0x0000-0x0fff` is not write-protected after cold boot and becomes read-only
only after resuming from S3.

You can dump PRx protections on your device by running `flashrom -p internal`.
If it doesn't work, make sure to boot with `iomem=relaxed` or try
`-p internal:laptop=force_I_want_a_brick`.

This is what you should see after a cold boot (and, if so, mmga should work on
your device):
```
PR0: Warning: 0x00190000-0x0066ffff is read-only.
PR1: Warning: 0x00692000-0x01ffffff is read-only.
```

And this is after resuming from S3:
```
PR0: Warning: 0x00000000-0x00000fff is read-only.
PR1: Warning: 0x00190000-0x0066ffff is read-only.
PR2: Warning: 0x00692000-0x01ffffff is read-only.
```

So, after cold boot flash descriptor is protected neither by PRx registers nor
by access permission bits on the flash descriptor itself. Under certain
circumstances, **writable flash descriptor allows flashing whole SPI flash** by
using a couple of neat tricks, and that is what mmga script does.

Writable `me` region gives us around 1.5 MiB of writable space. The idea is that
we can shrink ME firmware image with me_cleaner to about ~128 KiB and use the
freed space for a small temporary coreboot image. Writable `fd` gives us ability
to change flash layout and move reset vector. We combine all this, flash modified
regions, then power off (new flash descriptor becomes active on cold boot, so
reboot won't work). Then boot our small temporary coreboot and flash the whole
SPI chip, as there will be no more PRx protections set. So this is a two-stage
process.

Let's write a new layout:
```
00000000:00000fff fd
00001000:00020fff me
00021000:000fffff bios
00100000:007fffff pd
```

In this layout, we allocate 128 KiB for `me` and 892 KiB for `bios`. To fit the
original 1.5 MiB ME image into the 128 KiB region, it has to be truncated with
[me_cleaner](https://github.com/corna/me_cleaner) with `-t` and `-r` arguments,
the size of resulting image is ~92 KiB. We also have to allocate the remaining
`0x100000-0x7fffff` region for *something*, to be able to address and flash it
in future. So we just mark it as `pd`, which is commonly used for "Platform Data".

After the new layout is ready, we build small coreboot ROM that fits into the
allocated 892 KiB bios region. Then we flash **`fd`** (`0x0000-0x0fff`),
**`me`** (`0x1000-0x20fff`) and **`bios`** (`0x21000-0xfffff`) according to the
new layout. On the next cold boot, coreboot will be loaded from the
`0x21000-0xfffff` region, and the old firmware, which still resides in
`0x190000-0x7fffff`, will be ignored. This is **stage1**.

After we boot with small temporary coreboot ROM, we're able to flash the whole
8 MiB chip, because there are no more PRx protections set. We repartition the
chip again, and the new layout looks like this:
```
00000000:00000fff fd
00001000:00020fff me
00021000:007fffff bios
```

It's almost the same, except that `bios` fills all the remaining space. Then we
build coreboot again, flash `fd`, `me` and `bios` and power off again. On the
next cold boot we will have completely corebooted MacBook. This is **stage2**.

## Usage instructions

The **mmga** script automates steps described above and does all the dirty work.

### Usage:

```
./mmga <options> ACTION
```

##### Options:

```
-h, --help: show help
```

##### stage1 actions:

```
          dump: dump flash contents
         fetch: fetch board tree from Gerrit (if needed)
prepare-stage1: patch IFD, neutralize and truncate ME
 config-stage1: make coreboot config (for manual use)
  build-stage1: make config and build ROM (for auto use)
  flash-stage1: flash ROM ($COREBOOT_PATH/build/coreboot.rom)
```

##### stage2 actions:

```
prepare-stage2: patch IFD (if needed)
 config-stage2: make coreboot config (for manual use)
  build-stage2: make config and build ROM (for auto use)
  flash-stage2: flash ROM ($COREBOOT_PATH/build/coreboot.rom)
```

##### other actions:

```
     flash-oem: flash OEM firmware back
```

### Warning

You **should** have external means of flashing for a backup, **just in case**.
The procedure described above is quite delicate and error-prone and any mistake
may lead to a brick. In that case, you should have a copy of your original ROM
**on external drive**. Please make a backup of `work/oem/dump.bin` after
running `mmga dump`, or just copy the whole mmga directory.

These posts may be a little helpful if you ever need to flash externally: 

- [MacBook Air 5,2](https://ch1p.io/coreboot-mba52-flashing/)
- [MacBook Pro 10,1](https://ch1p.io/coreboot-mbp101-flashing/)

### Choosing the payload

Currently, SeaBIOS and GRUB are supported by mmga. SeaBIOS supports legacy boot,
it will most probably boot from an old school MBR partition. On the other hand,
it may not boot from GPT (I'm not sure about it, correct me if you know more)
and certainly it will not boot an EFI installation.

Sometimes GRUB is a better choice, but it all depends on your system. If you are
not sure, do some research before flashing or seek for help.

It may be a good idea to prepare a USB drive with some live system. I can imagine
a situation where you have chosen the wrong payload and cannot boot into your
system after power off/on cycle to complete the second stage, because, for instance,
SeaBIOS doesn't recognize your partition. In that case, you could try to boot
from live USB to fix your system (if possible) or to complete second stage and
change the payload.

Of course, in order to do that, you should backup the whole mmga directory after
the completion of the first stage but **before** the reboot.

### Configuration

Before you start, you have to update variables the `config.inc` file:
- **`PAYLOAD`**: which payload to use, supported values are `grub` and `seabios`
- **`MODEL`**: put your macbook model here, example: `macbookair5_2`
- **`GRUB_CFG_PATH`**: only if you use `grub` payload; if empty, default
  `grub.cfg` will be used
- **`COREBOOT_PATH`**: path to cloned coreboot repository (see below)
- **`FLASHROM`**: path to flashrom binary
- **`FLASHROM_ARGS`**: in case if flashrom detects multiple flash chips, put
  `"-c CHIP_MODEL"` here
- **`STAGE2_USE_FULL_ME`**: if you want to use original Intel ME image in the
  final ROM for some reason, set to `1`

#### stage1

Get coreboot:
```
$ git clone --recurse-submodules https://review.coreboot.org/coreboot.git && cd coreboot
```

Build coreboot toolchain. You must have gnat compiler installed, it is required
for graphics initialization (libgfxinit is written in Ada):
```
$ make crossgcc-i386 CPUS=$(nproc)
$ make iasl
```

Dump the flash chip contents:
```
# ./mmga dump
```

**Create a backup of the stock ROM dump on external drive!**

Create patched FD and neutralize ME:
```
$ ./mmga prepare-stage1
```

If your board's port hasn't been merged to coreboot master yet or you don't know,
run:
```
$ ./mmga fetch
```

Create coreboot config and build the ROM:
```
$ ./mmga build-stage1
```

(If you're experienced coreboot user or developer, you may want to configure and
build coreboot yourself. In that case, run `config-stage1` instead of
`build-stage1`. It will create config that you can then copy to `$COREBOOT_PATH`,
make your changes and build.)

Flash it:
```
# ./mmga flash-stage1
```

If it's done and there were no errors, you have to **shutdown** the laptop.
Do not reboot, the new flash descriptor is only active after cold boot, so it
won't work and may lead to weird stuff as you've just messed with firmware. Wait
a few seconds and power it back on.

#### stage2

Make patched flash descriptor for the next flash:
```
$ ./mmga prepare-stage2
```

Create new coreboot config and build the ROM (for experienced users,
`config-stage2` is also available):
```
$ ./mmga build-stage2
```

Flash it:
```
# ./mmga flash-stage2
```

This may take a while, don't interrupt it and let it finish.

Again, if there were no errors, power off the machine again, wait a few seconds,
and power on.

## FAQ

**My device is not listed, will it work?**

No, but it might be possible to support it.

**Will macOS continue to work with coreboot?**

No. It's theoretically possible to turn a corebooted MacBook into a hackintosh
by using TianoCore and Clover or OpenCore. Basically, if you want to use macOS,
don't install coreboot.

**Switching between iGPU and dGPU on MacBook Pro 10,1**

Last time I checked, [hacks](https://wiki.archlinux.org/index.php/MacBookPro10,x#Graphics_2)
were needed to use Linux with integrated GPU on this model. It seems that Apple EFI
forces dGPU when OS is not macOS. I've integrated hybrid graphics driver into
coreboot, it automatically switches to the configured GPU and you don't need to
care about it anymore. By default, integrated GPU is used. The setting is stored
in CMOS and you can change it with `nvramtool`.

Note that to use discrete GPU you need to extract VGA ROM from the stock firmware
dump and add it to CBFS, and configure coreboot to run VGA Option ROMs.

## TODO

- Support custom FMAP for larger first-stage `bios` partition
- Support multiple payloads at once
- Support TianoCore as a payload

## Misc

The script was tested on MacBook Air 5,2, MacBook Pro 8,1 and MacBook Pro 10,1.
If you have successfully corebooted your macbook with it and it worked, please
let me know.

If you have any problems, contact me via GitHub issues or by email (see the
copyright header in the script).

## License

GPLv2