Coreboot

[65a]

Is there generally interest in coreboot porting more of these? The following are already supported: https://github.com/coreboot/coreboot/tree/main/src/mainboard/apple. This seems to be the current state of the world: https://ch1p.io/coreboot-macbook-support/

I started to write a long guide on how to port coreboot to new boards, but realized it was probably better to start the discussion first.

Pros would be: We can probably configure a bunch of stuff Apple hid or disabled at a low level, run me_cleaner.py (Intel ME delete/disable), update FSP/refcode, mess with GOP settings, whatever (within the limits of Intel docs, and our understanding of the Apple EC, etc). It should be possible to run standard BIOS or EFI, which is probably not that interesting, or grub directly in fw (can be nice for linux, since disk can be decrypted and booted from firmware). Usually the FSP has a nice long list of things that can be changed, and in the future it's possible we escape the FSP (Intel blob for RAM and CPU bringup).

Cons would be: I have no idea if TianoCore can actually boot OS X directly. It can run in 32 bit or 64 bit mode, and it can definitely be modified to do whatever to make OS X happy. Things like me_cleaner can break weird stuff, and it can take a lot of iteration to make a port good enough for you, and even more to make it good enough for everyone. There are boards that cannot yet be ported, e.g. X99 (some iMacs, I think), and really only depends on having similar north/southbridge & CPU (and probably FSP) in coreboot already.

Disclaimer, I don't have a working intel mac, but I have ported quite a few x86 boards over the years, and these older intel macs might be easier than more recent boards. I don't think they have Intel BootGuard enabled, which means custom firmware should be possible if desired. I wouldn't flash anything you find on the internet, and I would definitely take an external backup of the flash chip first!

 

[Nixontheknight]

I have to wonder if Coreboot would work on a 2006 iMac

 

[65a]

It looks like Imac5,2 is in the coreboot main tree, is that the right one, or is it iMac5,1?

 

[Nixontheknight]

It looks like Imac5,2 is in the coreboot main tree, is that the right one, or is it iMac5,1?

yup, 5,2 is the one I have

 

[65a]

It looks like that has a SOIC-8 BIOS ROM. Do you know how to dump those (e.g. with a CH341A)? Before doing anything, you'll need a full flash backup, both for recovery if things don't work, and for extracting the blobs coreboot may need (e.g. Intel ME, GBE ROM). If you don't have a backup or a solution for reading or writing the chip externally, do not proceed.

 

[65a]

ISP (flashing/reading without removing from the board) gets tricky. It will require being sure of the clip orientation, and I strongly recommend a powered USB hub and being relatively quick. I have seen cases where attempting ISP powers up all the USB devices, IPMI, or other peripherals, and cheap programmers like the CH341a are happy to source "unlimited" (all your USB port has to give) current. There are more cowboy options, but usually those programmers are dumb enough to work, despite potentially getting quite warm. There is potentially risk to the USB port providing the power, hence the powered USB hub. Be careful with clip orientation and surrounding components. That being said, I haven't killed a board or USB port by reading the flash yet, but there's always a first time.

 

[Nixontheknight]

It looks like that has a SOIC-8 BIOS ROM. Do you know how to dump those (e.g. with a CH341A)? Before doing anything, you'll need a full flash backup, both for recovery if things don't work, and for extracting the blobs coreboot may need (e.g. Intel ME, GBE ROM). If you don't have a backup or a solution for reading or writing the chip externally, do not proceed.

I'll have to buy a programmer and a clip attachment so I can program it in circuit

 

[65a]

Definitely make multiple backups, I usually try to have a dedicated working directory separate from where I keep BIOS rom backups. SeaBIOS.

Here's some general information:

Coreboot uses a bunch of modules (cpu, northbridge, etc) of common code to build a ROM. These modules are pulled together into a mainboard, which combined with various blobs and a payload, result in a flashable ROM.

In some cases, the mainboards are so similar they are represented as variants of a common mainboard, which is the case for imac5,2. The code and definitions are here: https://github.com/coreboot/coreboot/tree/main/src/mainboard/apple/i945_macs

The common modules are here: https://github.com/coreboot/coreboot/blob/main/src/mainboard/apple/i945_macs/Kconfig

devicetree.cb can be viewed as an Openfirmware/DTS like config for the board: https://github.com/coreboot/coreboot/blob/main/src/mainboard/apple/i945_macs/devicetree.cb

Another fairly critical file would be: https://github.com/coreboot/coreboot/blob/main/src/mainboard/apple/i945_macs/gpio.c which is defining GPIO configs/setup. I haven't broken a board by getting this wrong, but it seems possible. Modern CPUs have maybe hundreds of these with various native functions, i945 looks much more sane.

The actual imac5,2 is defined as an override here: https://github.com/coreboot/coreboot/tree/main/src/mainboard/apple/i945_macs/variants/imac5_2 which is basically just some changes to information, the sound chip configs and the display.

For actually building, first I'd look for any docs from the contributor of imac5,2. They probably have specifics, and ideally the .config file for a working build. In general:

I will usually clone the entire coreboot repository into a new directory (such as git clone --recursive https://github.com/coreboot/coreboot coreboot-myboardname, replacing myboardname with something specific). Then you would want to run 'make crossgcc' in that directory and let it go, and possibly 'make iasl' as well. Finally, in util/ifdtool, run make. This is the tool for extracting firmware blobs from a copy of the backup ROM. I usually create a folder for any needed blobs in the repo, make a copy of the original firmware backup, and run ifdtool -x on the ROM. This will spit out a copy of the discrete ROM regions including GBE, ME, flash descriptor, etc.

At this point, I'd run 'make menuconfig'. There are a lot of options, and many require a lot of care or are unstable. I'd leave most at default for now after picking the desired board (imac5,2). You probably need to provide the paths to at least the flash descriptor, maybe GBE and ME blobs. Graphics usually require some poking (this board seems to be able to use the display without dealing with vbios blobs, which is good). For payload, I'd probably recommend SeaBIOS for test boots, or even just memtest.

If you don't get fairly far in the boot (e.g. screen on but SeaBIOS not responsive), not having serial for debugging is going to be hard. There are options there: USB debugport, telling coreboot to log to BIOS flash, or carefully trying to find a serial output on an unstuffed debug header (probably near the CPU). They all have drawbacks. I usually go for the last one, but another approach can be to add beep commands at various boot stage callbacks is faster if beep works.