MP 1,1-5,1 Open KickStart Project - kick new life to the cMP - polling interest

[RolfNoot]

I just woke this mornig with an idea, like to poll the interest for an opensource project for solving NVRAM / BootROM headaches and accelerate BootROM / UEFI / GPU Rom / GOP developments.

There are so many users around doing critical NVRAM / GPU card flashing which costs a lot of time while taking the risk of bricking. So the idea came to develop a small board which fits onto the 'Little Frank' connector, contains a (large) and modern QSPI Flash (8 .. 128MB), an ARM Cortex M0 microcontroller, an USB connection (HID & Mass storage Class) for updating NVRAM / Flash on-the-fly and a small header with a few General Purpose IOs for optional interfacing / physical switches for BootRom selection etc.

Just to get an idea what is possible with such a board:

• Simplifying the process of unbricking Macs with bricked BootROM
• Booting directly from/to OpenCore
• Mounting BootROM / Flash / Opencore as USB drive (easy access to UEFI / OpenCore config)
• Protection of unauthorized BootROM / NVRAM access / preventing NVRAM issues
• Storing / selecting multiple BootRom / UEFI interfaces (blessing or selecting with a physical switch)
• Utilizing GOP (eliminating the need of flashing GPUs for bootscreen)
• Quicker and easier development on BootROM / UEFI / OpenCore / GOP code
• Programming BootROM without the need of a CH341A programmer
• Many more!!

The goal is to develop an open-source small board with a target cost of around 10 euro:

• PCB, FR4 double sided 20x25mm: € 1,00
• MCU, ARM Cortex M0: € 1,50
• 512M-BIT QSPI: € 2,50
• Molex connector: € 3,00 ??? - info needed
• USB connector: € 0,50

Looking for:

• Fellow hard / software engineers to make this project possible
• Info on Little Frank connector (or having to reverse-engineer)
• Beta testers
• Enthousiasm
• Ideas
• Donations (hardware?, money only very optional!)

Ideas and suggestions are very welcome!

 

[Bmju]

This sounds very interesting!

For the normal user, I am not sure that making/using this to reprogram the system firmware is really easier than using software, when possible. I guess it does have the advantage, like a Matt card, of allowing someone to recover from a bricked firmware attempt.

Personally, what I would find really useful is just something that acts like a Matt card, with its own NVRAM chip - i.e. presumably exactly this - but which runs a switch to outside the machine, so that you can (effectively) disconnect or reconnect the Matt card while the system is running.

That sounds super dangerous, but I found that doing it (i.e. physically unplugging or replugging the Matt card, after the system had booted and was stable) worked and was essential - if you are developing with only a Matt card! - for recovering from bricks; I did it loads while developing EnableGop. (I think some other firmware developers may have developed their own solutions already, for something similar.)

 

[Macschrauber]

I always wanted to solder a 2nd flash on top of the flash ic in my open test rig with some kind of switch board.

Such an universal solution is way better of course.

Am open to this, of course. Also my dumper could support such a board.

 

[RolfNoot]

For the normal user, I am not sure that making/using this to reprogram the system firmware is really easier than using software, when possible. I guess it does have the advantage, like a Matt card, of allowing someone to recover from a bricked firmware attempt.

The USB connection can enumerate as mass storage device, giving direct R/W access to BootROM / NVRAM. For the user this would save a lot of steps (disabling SIP, pressing power button long time, rebooting). Of course safety measures can be implemented by implementing a password unlock function (disabling mass storage write protection).

Personally, what I would find really useful is just something that acts like a Matt card, with its own NVRAM chip - i.e. presumably exactly this - but which runs a switch to outside the machine, so that you can (effectively) disconnect or reconnect the Matt card while the system is running.

Exactly this, Flash memory is large enough to hold multiple images and the SPI functionality can be disabled as well in order to have the original NVRAM in use. Switches can be wired the onboard GPIOs.

That sounds super dangerous, but I found that doing it (i.e. physically unplugging or replugging the Matt card, after the system had booted and was stable) worked and was essential - if you are developing with only a Matt card! - for recovering from bricks; I did it loads while developing EnableGop. (I think some other firmware developers may have developed their own solutions already, for something similar.)

Depends on the implementation of the accompanying soft-/firmware. Security measures such as NVRAM selection only upon start are easy to implement: flipping the switch doesn't do anything up until reboot.

I am not a die-hard software engineer but I have worked (and almost dedicated) my life developing embedded hard- and firmware. As such, I am not able to do this project all by myself and hope to find fellow engineers.

Thanks for the feedback!

 

[RolfNoot]

I always wanted to solder a 2nd flash on top of the flash ic in my open test rig with some kind of switch board.

Such an universal solution is way better of course.

Am open to this, of course. Also my dumper could support such a board.

Perfect! and yes, it would make good sense to implement functionality to the dumper by reading/writing to NVRAM and have the BootROM checks available. Implementing mass-storage USB functionality would require some work, in the meanwhile the dumper can make use of HID or Virtual Com to do reading / writing.

 

[Macschrauber]

it's not just the NVRAM Volume, we have Syncretic working on bootrom additions what are of course outside the NVRAM area and also EnableGOP.

So such a Board should not just map another NVRAM in, it should be able to hold one or more variants of the whole 4MB Flash content

 

[RolfNoot]

Yes, not only the NVRAM but the complete bootrom.

Also, such a board also needs to 'mimic' the commands and registers of the Flash chip (page 11-28) (manufacturer/device ID, (block) erase etc.). That would take some time to develop. Starting point can be to use a recognized chip and add functionality step-by-step. It would already be nice to have an on-the-fly flashable 'secondary' selectable chip to start with.

Proposed 64MB flash chip can theoretically hold 16 complete bootrom images and is very cheap nowadays.

 

[Bmju]

Matt card IMO works by just patching an actual nvram chip (which ofc accepts actual nvram chip commands) to the Frank connector. And I guess the Frank connector and cMP mobo must already be designed to accept this. I am _guessing_ that some pin on the Frank just needs to be e.g. grounded to say that there is an nvram chip present on it (I do not know this, but I suppose it must be something like that). The Matt card is extremely simple - there basically appear to be no components on it, just board wiring (on the tiny board), a connector and a chip.

 

[Macschrauber]

no, the matt card contains a complete 4mb flash ic replacing completely the flash ic on the backplane.

NVRAM is just a 192KB Part of the 4MB Flash ic. If you open the dump with UEFI Tool you will see how it is organized.

 

[RolfNoot]

Matt card IMO works by just patching an actual nvram chip (which ofc accepts actual nvram chip commands) to the Frank connector. And I guess the Frank connector and cMP mobo must already be designed to accept this. I am _guessing_ that some pin on the Frank just needs to be e.g. grounded to say that there is an nvram chip present on it (I do not know this, but I suppose it must be something like that). The Matt card is extremely simple - there basically appear to be no components on it, just board wiring (on the tiny board), a connector and a chip.

I don't have one but yes, it's obviously designed to do a check if a chip / connection is present on the Little Frank connector. This can be done by just polling the SPI / I2C lines or by setting a logic state on (one of) the pins. I also see designs with resistors where value defines a function of what's connected (e.g. the iPod dock connector had such a functionality).

The board seems to just hold a flash chip, capacitor and some pullup/down resistors.

 

[tsialex]

Most of the suggestions here are very nice and useful, but from a developers perspective, the most important is a simply way to flash from another Mac/PC without entering Firmware Programming Mode. A circuit that could halt, flash/dump and reset the Mac Pro - space for more than one image is also very useful, with an image selection switch controlled from GPIO.

If we can implement that, a lot of friction would be removed from MacPro5,1 firmware development and testing.

Btw, the MOLEX connector for the LITTLE FRANK was something like $9 a piece back in 2018, when I bought some.

 

[RolfNoot]

Currently I don’t have information about whether a circuit on the Little Frank could halt, flash (the default SPI flash) and reset the MacPro. The proposed h/w comes close while you can dump, flash and select images using the onboard chip, without having to disable SIP, reboot, press button, reboot, enable SIP etc. It can be done on the fly, then selecting the newly flashed bootrom (space) and reboot.

Yeah, Molex can be very expensive however with larger amounts and buying directly at the distri, prices can be a fraction of that on Mouser.

 

[RolfNoot]

Btw, the MOLEX connector for the LITTLE FRANK was something like $9 a piece back in 2018, when I bought some.

Looks like SlimStack, you have the p/n?

 

[tsialex]

Looks like SlimStack, you have the p/n? View attachment 2177724

I'm at currently at work, I can check my previous purchases in the weekend and get the exact part/order number, but I think that is the one below, 30pins:

Board-to-Board Connectors Part - 5009130302 | Molex

SlimStack Board-to-Board Receptacle, 0.40mm Pitch, J-Bend Series, 1.80 or 2.30mm Mated Height, 4.20mm Mated Width, 30 Circuits

www.molex.com

 

[avro707]

This sounds very interesting!

Actually critical for our old Mac Pro machines! I had been thinking of exactly such an idea but didn’t post it before.

Bootrom fixing is great, but not for people who aren’t savvy with replacing chips on the board of their beloved computers. A way to avoid that would be excellent.

 

[tsialex]

Actually critical for our old Mac Pro machines! I had been thinking of exactly such an idea but didn’t post it before.

Bootrom fixing is great, but not for people who aren’t savvy with replacing chips on the board of their beloved computers. A way to avoid that would be excellent.

It's a combo. While you can solve the hardware issue with the SPI flash replacement, the logical one still exists.

Looking back with what we know now a decade and half later, the Mac Pro BootROM was definitively a bad initial design that Apple was correcting on the fly, putting out little fires with a new release each pair of months or so.

Look how much revisions Apple needed to get it really functional, these are only the versions that were used with production Mac Pros:

EFI Release vs BIOS Version vs BootBlock Version Reference Table:

EFI Release:	BIOS Version:	BootBlock Version:
MP41.0081.B03	MP41.88Z.0081.B03.0902231259	AAPLEFI1.88Z.0004.I00.0901121311
MP41.0081.B04	MP41.88Z.0081.B04.0903051113	AAPLEFI1.88Z.0004.I00.0901121311
MP41.0081.B??	MP41.88Z.0081.B??	AAPLEFI1.88Z.0004.I00.0908061259
MP41.0081.B07	MP41.88Z.0081.B07.0910130729	AAPLEFI1.88Z.0004.I00.0910130728
MP41.0081.B08	MP41.88Z.0081.B08.1001221313	AAPLEFI1.88Z.0004.I00.1001221311
MP51.007F.B00	MP51.88Z.007F.B00.1008031144	AAPLEFI1.88Z.0005.I00.1006041028
MP51.007F.B??	MP51.88Z.007F.B??	AAPLEFI1.88Z.0005.I00.1007141219
MP51.007F.B01	MP51.88Z.007F.B01.1008231310	AAPLEFI1.88Z.0005.I00.?
MP51.007F.B02	MP51.88Z.007F.B02.1009221128	AAPLEFI1.88Z.0005.I00.?
MP51.007F.B03	MP51.88Z.007F.B03.1010071432	AAPLEFI1.88Z.0005.I00.1010071430
MP51.0083.B00	MP51.88Z.0083.B00.1707271620	AAPLEFI1.88Z.0005.I00.1707271617
MP51.0084.B00	MP51.88Z.0084.B00.1708080528	AAPLEFI1.88Z.0005.I00.1708080525
MP51.0085.B00	MP51.88Z.0085.B00.1802021746	AAPLEFI1.88Z.0005.I00.1802021742
MP51.0087.B00	MP51.88Z.0087.B00.1804181525	AAPLEFI1.88Z.0005.I00.1804181521
MP51.0089.B00	MP51.88Z.0089.B00.1806081708	AAPLEFI1.88Z.0005.I00.1806081704
138.0.0.0.0	MP51.88Z.F000.B00.1807300628	AAPLEFI1.88Z.0005.I00.1807300627
139.0.0.0.0	MP51.88Z.F000.B00.1808171030	AAPLEFI1.88Z.0005.I00.1808171029
140.0.0.0.0	MP51.88Z.F000.B00.1809191555	AAPLEFI1.88Z.0005.I00.1809191554
141.0.0.0.0	MP51.88Z.F000.B00.1812191621	AAPLEFI1.88Z.0005.I00.1812191620
142.0.0.0.0	MP51.88Z.F000.B00.1902142049	AAPLEFI1.88Z.0005.I00.1902142048
144.0.0.0.0	MP51.88Z.F000.B00.1904121248	AAPLEFI1.88Z.0005.I00.1904121247

Also, it's beyond stupid that Apple never updates the hardware descriptor or the BootBlock after the backplane is flashed by the factory. MemoryConfig saved inside the main VSS store was also a very unfortunate design choice, later corrected with MacPro6,1 and newer Macs. Let me not start to talk how Firmware Programming Mode was another extremely poor design choice.

The lessons learned with all the issues with MacPro4,1/MacPro5,1 BootROM evolution changed the way newer Macs were later designed, from the hardware, firmware, endurance and usability standpoints.

 

[RolfNoot]

Looks like it’s a non specific 0.40mm board-to-board connector, different brands, widely available and not expensive.

10142890-030A3EHLF - Mezzanine Connector, Receptacle, 0.4 mm, 2 Rows, 30 Contacts, Surface Mount, Phosphor Bronze

The BergStak® 0.40mm self-alignment connectors come with a stack height of 3.50mm and 30 positions extendable up to 10 to 60 positions with 10 positions incremental. It has a unique self-alignment feature that supports blind mating, ensuring a reliable connection. The USCAR-2 compliant connector...

nl.farnell.com

Will be a sub 10 dollar board for sure.

 

[tsialex]

Looks like it’s a non specific 0.40mm board-to-board connector, different brands, widely available and not expensive.

10142890-030A3EHLF - Mezzanine Connector, Receptacle, 0.4 mm, 2 Rows, 30 Contacts, Surface Mount, Phosphor Bronze

The BergStak® 0.40mm self-alignment connectors come with a stack height of 3.50mm and 30 positions extendable up to 10 to 60 positions with 10 positions incremental. It has a unique self-alignment feature that supports blind mating, ensuring a reliable connection. The USCAR-2 compliant connector...

nl.farnell.com

This need to be test fitted.

Will be a sub 10 dollar board for sure.

BOM of less than $10 in volume is probably possible, but shipping/import costs of the parts, supplies, assembling and testing costs will make this prediction impossible.

 

[RolfNoot]

This need to be test fitted.



BOM of less than $10 in volume is probably possible, but shipping/import costs of the parts, supplies, assembling and testing costs will make this prediction impossible.

I dare to bet that I’m not far off, talking about approx. 20 panels with 10pcs/panel. Where I order, I do not pay for shipment or import costs. Boards produced in NL with modern pick & place equipment and this amount of parts at 0.40mm pitch minimum will yield a failure rate of < 1%. Would not opt for additional testing other than default AOI.

Of course when calculating development time, the project will never pay off. For me it’s not about the money.

 

[flat4]

I have read this and its something I could donate to however can someone dumb it down for me. what exactly will it do when/if it comes to fruition.

 

[RolfNoot]

I have read this and its something I could donate to however can someone dumb it down for me. what exactly will it do when/if it comes to fruition.

The general goal is to accelerate developments like opencore, contribute to bootrom insights by simplifying the work on it and also make repair a lot easier. In the first place, the benefit for developers is the highest, secondary users will benefit as well. Some examples from user-perspective:

- fix a bootrom bricked Mac by plugging in this (fairly cheap) device
- use new (unsupported) videocards out of the box (no need to flash the videocard) in the MacPro 4,1 and 5,1
- prevent bootrom corruption
- lower the barrier for contributing developments which are improving MacPro 4,1 and 5,1's lifespan

For me I'm not doing this for money, so any donations will go to the one(s) who is (are) able to give more information on the Little Frank connector:
- pinning
- description/details of the signals (protocols, voltages) on the connector

The above is needed to get started with the h/w design in the first place. As soon as I have enough information I will build a dozen of free boards for developers willing to beta test it and help writing the firmware / accompanying software.

PS: all ideas, materials and design files (schematics, layout source codes etc) will be subject to GPL.

 

[Bmju]

The general goal is to accelerate developments like opencore, contribute to bootrom insights by simplifying the work on it and also make repair a lot easier. In the first place, the benefit for developers is the highest, secondary users will benefit as well. Some examples from user-perspective:

- fix a bootrom bricked Mac by plugging in this (fairly cheap) device
- use new (unsupported) videocards out of the box (no need to flash the videocard) in the MacPro 4,1 and 5,1
- prevent bootrom corruption
- lower the barrier for contributing developments which are improving MacPro 4,1 and 5,1's lifespan

For me I'm not doing this for money, so any donations will go to the one(s) who is (are) able to give more information on the Little Frank connector:
- pinning
- description/details of the signals (protocols, voltages) on the connector

The above is needed to get started with the h/w design in the first place. As soon as I have enough information I will build a dozen of free boards for developers willing to beta test it and help writing the firmware / accompanying software.

PS: all ideas, materials and design files (schematics, layout source codes etc) will be subject to GPL.

Most OpenCore development as such doesn't involve modifying firmware at all, to be fair.

But something like this might well be beneficial to firmware developers (i.e. those who are developing things which _are_ typically flashed to firmware to test them, unlike almost all of OpenCore itself) - at least on the machines it's set up for, remembering that this I think will be MacPro5,1 specific.

If it makes any sense, feel free to do a dumbed down description of the developer benefits too, i.e. how you see a developer using (all the features of!) what you're thinking of.

 

[Macschrauber]

I, for myself, would do far more tests with messed up boot roms if I dont have to fiddle with it in case.

I can do it, but for trial and error that is even with an open test rig too much time consuming. So such a tool would be very helpful.

 

[RolfNoot]

Most OpenCore development as such doesn't involve modifying firmware at all, to be fair.

I am not a specialist on OpenCore tbh, but I can imagine there's not always such a clear demarcation as soon as firmware is very easily adaptable (ie. bootrom can integrate OpenCore functionality).

The cMP 4,1 & 5,1's BootROM / NVRAM is seen as Achilles heel, with today's components (larger / cheaper / better flash combined with an additional modern MCU) a lot can be done to overcome that burden.

Regarding developers benefit, I like to hear from themselves (I am just an embedded hardware engineer 🙂).

 

[Bmju]

I am not a specialist on OpenCore tbh, but I can imagine there's not always such a clear demarcation as soon as firmware is very easily adaptable (ie. bootrom can integrate OpenCore functionality).

The cMP 4,1 & 5,1's BootROM / NVRAM is seen as Achilles heel, with today's components (larger / cheaper / better flash combined with an additional modern MCU) a lot can be done to overcome that burden.

Regarding developers benefit, I like to hear from themselves (I am just an embedded hardware engineer 🙂).

Well since I am a firmware developer now, I guess, for me the single coolest thing would be to be able to just connect and disconnect an alternative nvram chip, without physically having to plug and unplug anything, so I guess by a switch which can be run to outside the case.

Just one chip and just the memory size of the native chip would be fine for me.

I guess it would be great if the alternative nvram chip was also replaceable without soldering, but that's just a 'nice to have'.

I think just those could be done with a yet simpler rig than you're suggesting. But if your rig can do that, plus features other people might use (or even other features I might use, once I've got my head round the use case) then who's complaining, and that would be great!