I just saw 'another' product which is able to read and write the SPI flash via Little Frank for a MacBook Pro, so when enough info available, it 'may be' be possible.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Open KickStart Project - kick new life to the cMP - polling interest
- Thread starter RolfNoot
- Start date
- Sort by reaction score
Just found this...
It's from a 2009-2011 iMac, so it wouldn't differ too much with the cMP 4,1 / 5,1
External ROM is selected by pulling SPIROM_USE_MLB low...
Another layout:
It's from a 2009-2011 iMac, so it wouldn't differ too much with the cMP 4,1 / 5,1
External ROM is selected by pulling SPIROM_USE_MLB low...
Another layout:
Attachments
Last edited:
Getting away from soldering opens things up to a lot more people who aren’t confident on soldering things.
Bigger memory size would be great, but also if it’s more dependable over the long run.
Being able to keep a pristine version of a rebuilt bootrom that can be reverted to in case of disaster also would be good.
Having a bigger replacement SPI Flash memory is only useful to keep more images, a MacPro5,1 BootROM image is hardwired to 4MB and you can't change that.
There is no need to program the native SPI Flash itself, like the cmizapper MEDUSA, if we can program one of the images/slots for images and select it for the next boot via GPIO, this will help immensely.
Just found this...
View attachment 2178155
It's from a 2009-2011 iMac, so it wouldn't differ too much with the cMP 4,1 / 5,1
External ROM is selected by pulling SPIROM_USE_MLB low...
Another layout:
DEBUG_RESET and SMC_RESET are what will be very interesting for developers testing the images, since reseting programmatically the Mac Pro will eliminate an enormous point of friction.
I would wonder how. SPI just continues after 0x3FFFFF to 0x400000 … Is serially hardwired to the CPU, so unless the instruction set doesn’t allow for more than 22bit addressing, it would work IMHO
You are forgetting how the X86 Reset Vector works, you will have to change all the offsets. Currently more or less 2/5 of the Mac Pro SPI flash is just 0xffs, why you gonna change for a bigger image?
If you gonna go crazy and remove binary compatibility, then something like CoreBoot is a better option.
Yes, will need a rebuild of course, not a hardwired limitation though.
I have no idea whether that would be good, I've no experience with that.
Hardwired was probably a wrong choice of word, but effectively is, since we don't have the source code of the BootROM to change everything needed or we want to remove binary compatibility.
You might wanna look here:
GitHub - gch1p/mmga: Script for flashing coreboot on MacBooks without using external SPI programmer
Script for flashing coreboot on MacBooks without using external SPI programmer - gch1p/mmga
github.com
I have a different idea. Why not create a coreboot firmware with modern UEFI-2 and maybe even updating the ME region keeping the original hardware identifiers so OpenCore would work out of the box? Then use that firmware with a switch on the LF connector?
Last edited:
I was thinking more in depth about this proposal and while I think that will be really useful for several use cases, one thing that become clear about it is that name choice OpenNVRAM and some of the first post info are currently misleading, this is a SPI flash memory replacement board, exactly like a MATT card is, with added BootROM switcher and not solution for the NVRAM volume logical problems.
The exact same logical problems that the MacPro5,1 BootROM have with the NVRAM volume will continue to happen, hardware can't solve that. You can eliminate the NAND failure issues with the SPI flash replacement board, but not the garbage collection issues, the NVRAM volume problems, the cross-flashing adverse effects or the several BootBlock issues, to cite some. Changing to another BootROM image/slot, like an Amiga Kickstart switcher does, partially address that indirectly, since you can move to a fully working BootROM image, but this continues to be a SPI flash replacement on steroids.
Another thing, without a previously saved BootROM image to the SPI replacement board, you can't get anywhere, this have to be clearly explained, when a newbie reads the first post it gives the impression that everything about his brick will be solved with this future device and is just to connect it to the backplane and the backplane will be magically revived. This is literally impossible, unless you want to mess with Apple copyright real hard like cmizapper currently does or will use CoreBoot instead, but like @startergo correctly suggested above, you still need the factory saved hardware-IDs that are completely lost if the SPI flash memory failed without a BootROM backup.
The exact same logical problems that the MacPro5,1 BootROM have with the NVRAM volume will continue to happen, hardware can't solve that. You can eliminate the NAND failure issues with the SPI flash replacement board, but not the garbage collection issues, the NVRAM volume problems, the cross-flashing adverse effects or the several BootBlock issues, to cite some. Changing to another BootROM image/slot, like an Amiga Kickstart switcher does, partially address that indirectly, since you can move to a fully working BootROM image, but this continues to be a SPI flash replacement on steroids.
Another thing, without a previously saved BootROM image to the SPI replacement board, you can't get anywhere, this have to be clearly explained, when a newbie reads the first post it gives the impression that everything about his brick will be solved with this future device and is just to connect it to the backplane and the backplane will be magically revived. This is literally impossible, unless you want to mess with Apple copyright real hard like cmizapper currently does or will use CoreBoot instead, but like @startergo correctly suggested above, you still need the factory saved hardware-IDs that are completely lost if the SPI flash memory failed without a BootROM backup.
Last edited:
I admit the topic name was wrongly chosen, but I am not able to modify it unfortunately.
I wouldn’t compare it with a Matt card which is a pretty dumb device. There’s a lot of logic and functionality added which makes it a different device. An MCU could prevent nvram/bootrom issues when we know when it’s being messed with. It can protect nvram like opencore does and can even switch back to ‘virgin mode’ when needed.
I’m not telling that it can restore bootrom. It can simplify the procedure for the user but we still need tech guys like @tsialex for BootROM reconstruction. I foresee an increased interest in the reconstruction services once users can program it with a ‘virgin’ reconstructed BootROM to switch back to at any moment.
I wouldn’t compare it with a Matt card which is a pretty dumb device. There’s a lot of logic and functionality added which makes it a different device. An MCU could prevent nvram/bootrom issues when we know when it’s being messed with. It can protect nvram like opencore does and can even switch back to ‘virgin mode’ when needed.
I’m not telling that it can restore bootrom. It can simplify the procedure for the user but we still need tech guys like @tsialex for BootROM reconstruction. I foresee an increased interest in the reconstruction services once users can program it with a ‘virgin’ reconstructed BootROM to switch back to at any moment.
Also, I had this idea initially, not even knowing if and how much it could contribute to the community. I had some ideas but it needs maturing.
I like the idea of @startergo, but I’ve no idea what all would be possible in the end. I am just an embedded hardware ‘nerd’ focusing on improving the poor SPI ROM design of the MacPro and hoping to contribute in a way to enhance the lifespan of these beautiful machines.
I like the idea of @startergo, but I’ve no idea what all would be possible in the end. I am just an embedded hardware ‘nerd’ focusing on improving the poor SPI ROM design of the MacPro and hoping to contribute in a way to enhance the lifespan of these beautiful machines.
Will make an initial run of about 20-40 devices to handout for free (ex shipping) to the ones contributing with ideas and development.
You are thinking for newer Macs, no? Apple did not implemented Intel ME with Mac Pro platform until late-2013 Mac Pro.
You can always edit the topic title or ask a moderator to do it.
First thing, I'm not trying to discourage you in any way, I can see several ways that a solution like you propose can be extremely helpful. I here to help the discussion.
Sure, I'm not doubting that in the long run we can do that, but it's like the end goal. You will have to initially implement a SPI flash replacement + BootROM switcher and then interact/develop on that, no?
OpenCore protection of the NVRAM is very narrow and with some very specific issues that happen at boot time
Yeah, some things are easy to avoid, like corrupted headers, I'm sure your logic can scan for some of the most common NVRAM/BootROM errors with some validation/checksum verification/etc.
Anything that can be done for improving our Mac Pros, will surely be most welcome.
Just one other thing to add and going back to my suggestion of the first implementation, a lot of the Mac Pro user base have zero or little interest running anything newer than Mojave.
A lot of Logic Pro guys still run Snow Leopard/El Capitan/High Sierra. Adobe CS6 people can't even go anything newer than High Sierra. Studios and production houses that still run MacPro5,1, most are using it with legacy applications like FCP7.
So, for a good chunk of the perspective public for a solution like this, CoreBoot or even OpenCore have no attractiveness whatsoever.
Last edited:
I don’t have much two offer on the programming skills. But I am willing to contribute upfront like 50-100 euro? So some test materials can be bought. Also I’m not a complete idiot and willing to experiment and alpha or beta test.
My interest would be to stay current with the latest macOS release and improve hardware support.
My interest would be to stay current with the latest macOS release and improve hardware support.
As an enhanced programmer/smart Matt card, this device has a lot of potential.
Some ideas:
Some ideas:
- One functionality that I envision is to automatically switch to a clean BootROM image periodically or even based on (MCU-sensed) pre-corruption indicators.
- We should also look into SMC interaction via Frank. It might be possible to fix the racing fan bug (perhaps with a simple reset) that affects some machines and graphics cards.
- The USB connection could be provided internally through my olá module (or similar).
- It is important to minimize the strain on the Little Frank connector (I don’t think it’s rated for many plug-unplug cycles). This is something that should be kept in mind when testing connectors and should also be incorporated in the design.
It would be a combination of hard- and software. For example scanvss from @Syncretic can be used to check the variables and UefiExtract for checking the CRC32 sums. I use both tools for my dumper in the background.
An emergency mode could contain the generic mp51.fd file what has no machine IDs (nor Fsys, Gaid, lbsn). The user has to flash that firmware on it in a pre installation procedure (for copyright issues I would not ship it with a firmware pre installed).
This does not take away the need for having a bootrom backup of course like @tsialex said.
I would add some functionality to my dumper to serve such a firmware board.
An emergency mode could contain the generic mp51.fd file what has no machine IDs (nor Fsys, Gaid, lbsn). The user has to flash that firmware on it in a pre installation procedure (for copyright issues I would not ship it with a firmware pre installed).
This does not take away the need for having a bootrom backup of course like @tsialex said.
I would add some functionality to my dumper to serve such a firmware board.
Just a comment on this: OpenRuntime is present though, so I believe the protection extends beyond boot time.
That's an interesting olá module! 😀 The design can embrace the same functionality as well. Currently I am thinking to use PSoC4200L as I can create the firmware and multiplexing of the SPI signals in almost no time (have done each aspect of the design earlier and it's just a matter of connecting the Lego blocks).
Eventually I will look into RP2040 or similar to see which chip can have the desired functionality utilized.
I will hook the SMC & LPC signals on the LF to the MCU, so any SMC interaction can be developed in f/w when there's interest.
Would incorporating the mp51.fd image raise any copyright issues? I was thinking though to change the chime AIFF so users would notice the difference
Last edited:
Please don't. I think as someone else said, Mac owners trend to be quite aesthetically sensitive, and to just want their machines to work nicely, in the standard Apple way.
Yes, OpenRuntime and OpenVariableRuntimeDxe remain present and continue to provide the protections that they respectively provide while the OS - any OS - is running
as I understand this is for the emergency firmware without identity. So a special emergency firmware chime is imo helpful to separate and to warn if it was chosen.