Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MP 1,1-5,1 Guide: How to rebuild/update Mac Pro 4.1/5.1 bootrom with template files

B

Borowski

macrumors 6502
Original poster
Oct 22, 2018
270
82
Hello,

i want to show a way how to rebuild or update the bootrom of Mac Pro 4.1 and 5.1 on your own, using complete pre-build bootrom templates without individual data.

Some members won’t be happy bunnies about that and may try to delete the topic, but i’ll publish it on other platforms. I’m not interested in gatekeeping, now it is open to public.

Disclaimer: I am not responsible for any damages or bricks of your machine. If you have difficulties or doubts, contact a member with experience. Double- and triple check your work before flashing the generated bootrom file.

What you need:
What is the purpose?
  • The templates contain the latest bootrom version 144.0.0.0.0, you’re able to update your Mac Pro 4.1 or 5.1 in one step without need of netkas-tool, installing High Sierra, Mojave, a Metal-supportet card or bootscreen capability.
  • This will also avoid the common VSS-problem of crossflashed 4.1, NVRAM is empty, you have to set your preferred bootvolume after flashing the bootrom.
  • Firmware-password will be deleted also, so this is also a way to unlock soft-bricked machines.
  • I attached 2 bootrom-templates, one modded with latest EnableGOP 1.4. Decide what you need. Topic: https://forums.macrumors.com/thread...mac-pros.2378942/?post=31924217#post-31924217
  • The templates contain the latest known hardware descriptor overrides (Base_21) and Fsys-/Gaid-version 0x0D
Attention:
  • If your bootrom lacks data or has serious corruption, this guide may not help you
  • This guide is only valid for Mac Pro 4.1 and 5.1
  • All data seen on screenshots are public or invented
  • I won’t support any builds faking serial no
Steps in short:
  • Transferring individual data inside Fsys- and Gaid-store from your own dump to the bootrom-template. Unfortunately, UEFITool can’t recognize NVRAM, Fsys- and Gaid-store, so we have to do this manually with hexeditor
  • Correcting both checksums in Fsys- and Gaid-store
  • Transferring individual data from last volume (MAC address, LBSN and build date) to raw-template
  • Exchange Section_Raw_Volume_Top_File_Volume_Top_File inside the (pre-) modified bootrom-template with the raw-template, using UEFITool 0.28
  • Check if all mods are correct and succesfull
Lets begin....
  • Open your bootrom-dump and one of the bootrom-templates (v144.0.0.0.0_template_EnableGop_v14.bin or v144.0.0.0.0_template.bin) with hexeditor
  • Search in your bootrom-dump inside the Fsys-stream containing ssn, hwc and son (maybe more); unfortunately the position is not fixed and depends from the lenght of previous content. You can generally try to search for textstring „ssn“, most editors will show the code converted to ANSI on the right.
  • Check if ssn, hwc and son are present and the order matches: All values are human-readable in ANSI.
  • Copy the string, including 03 (before ssn), ending with 46 (last digit of „EOF“). The lenght may also vary, in my example it has 0x2C lenght (donor right, template left):
    insertion_Fsys.png
  • In bootrom-template navigate to offset 0x1486A5, this is the position you’ll put in the string.
  • Overwrite (NOT insert!) in bootrom-template:
    insertion_Fsys_finished.png
  • Now navigate in your dump to position 0x14880B (Gaid-entries). This position is fixed:
    insertion_Gaid.png
  • Copy the string including 04 (before „tsth“ begins), ending with 46 (last digit of „EOF“). It has 0x43 lenght and yet i did’t saw dumps with more or less entries.
  • Navigate in template to position 0x14880B and overwrite (NOT insert!) the string:
    insertion_Gaid_finished.png
  • Save the template file.
  • Open modified template with UEFITool_NE and navigate to „EFISystemNvDataFvGuid“, „Fsys store“ and „Gaid store“: On the right window it will identify both CRC32-checksums as invalid. For luck, UEFITool_NE will show us the correct checksum, you have to write them manually in hexeditor.
    uefitool_checksum_Fsys_invalid.png
    uefitool_checksum_Gaid_invalid.png
  • Open the template in hexeditor: The checksums are 4 bytes long and located at fixed offsets 0x1487FC (for Fsys store) and 0x149FFC (Gaid store). Pay attention: The bytes are swapped, a suggested checksum e.g. 732FD5CB has to be written in hexeditor as CBD52F73. Thats why you can’t simply copy the checksum from UEFITool_NE and insert it directly with hexeditor, leave both apps open and type by hand. Checksum position Fsys store seen here:
    checksum_fsys.PNG
  • And here for Gaid store:
  • checksum_gaid.PNG
  • Save the template file, open again with UEFITool_NE and navigate to „EFISystemNvDataFvGuid“, „Fsys store“ and „Gaid store“: Both CRC32-checksums should now recognized as valid:
    uefitool_checksum_Fsys_corrected.png
    uefitool_checksum_Gaid.png
  • Open your bootrom-dump and Section_Raw_Volume_Top_File_Volume_Top_File.sct with hexeditor
  • In bootrom-dump navigate to offset 0x3FFF00 and copy the whole block with lenght 0x80. Check if it contains valid data; you can easy identify the LBSN (in example: J50324H3FBH9A) and build date (here: 100811100811=11 Aug. 2010) in ANSI in the pictures (right donor, left empty raw_volume).
    section_raw.PNG
  • In Section_Raw_Volume_Top_File_Volume_Top_File.sct navigate to offset 0x10 and overwrite (NOT insert!) the block.
    section_raw_inserted.PNG
  • Save the Section_Raw_Volume_Top_File_Volume_Top_File.sct.
  • Open the modified template with UEFITool 0.28 and navigate to last volume „04ADEEAD-61FF-4D31-B6BA-64F8BF901F5A“, last file „1BA0062E-C779-4582-8566-336AE8F78F09“, last section „Raw section“.
  • Select „Replace as is“ (not any other command!) and choose your modified Section_Raw_Volume_Top_File_Volume_Top_File.sct.
    uefitool_replace.png
  • Save image file. UEFITool will correct ZeroVector and checksum, no manual editing needed.
    save_image_file.png
  • Open the modified template with UEFITool_NE and check:
  • If all checksums are valid
  • All entries in Fsys- and Gaid-store are present
  • Last volume is marked as „AppleCRC“, this indicates a corrected ZeroVector (CRC32-checksum of body).
    uefitool_finished.PNG
  • example of a non-corrected ZeroVector, seen on many dumps, "AppleCRC" missing:
    wrong_zero_vector.PNG
  • For analyzing and flashing i recommend the linked dumper tool from „Macschrauber“: It is a handy tool with GUI and easy to use.
Now you’re ready to flash it to the machine. Good luck!
 

Attachments

  • templates.zip
    3.4 MB · Views: 104
  • uefitool_finished.PNG
    uefitool_finished.PNG
    62.8 KB · Views: 114
  • checksum_fsys.PNG
    checksum_fsys.PNG
    33.1 KB · Views: 110
  • checksum_gaid.PNG
    checksum_gaid.PNG
    31.3 KB · Views: 119
Last edited:
  • Like
  • Love
Reactions: avro707, sheapuppy, mulholland13 and 10 others
Outstanding guide and relatively simple to do so many thanks for the comprehensive explanation!
 
There is no reason for anyone to delete your post for sharing the knowledge. 90% of worlds forum wouldn't exist if there is global prohibition to share knowledge, instructions, ideas etc.

Anyway, thanks for sharing this !
 
Borowski said:
Hello,

i want to show a way how to rebuild or update the bootrom of Mac Pro 4.1 and 5.1 on your own, using complete pre-build bootrom templates without individual data.

Some members won’t be happy bunnies about that and may try to delete the topic, but i’ll publish it on other platforms. I’m not interested in gatekeeping, now it is open to public.

Disclaimer: I am not responsible for any damages or bricks of your machine. If you have difficulties or doubts, contact a member with experience. Double- and triple check your work before flashing the generated bootrom file.

What you need:
What is the purpose?
  • The templates contain the latest bootrom version 144.0.0.0.0, you’re able to update your Mac Pro 4.1 or 5.1 in one step without need of netkas-tool, installing High Sierra, Mojave, a Metal-supportet card or bootscreen capability.
  • This will also avoid the common VSS-problem of crossflashed 4.1, NVRAM is empty, you have to set your preferred bootvolume after flashing the bootrom.
  • I attached 2 bootrom-templates, one modded with latest EnableGOP 1.4. Decide what you need. Topic: https://forums.macrumors.com/thread...mac-pros.2378942/?post=31924217#post-31924217
  • The templates contain the latest known hardware descriptor overrides (Base_21) and Fsys-/Gaid-version 0x0D
Attention:
  • If your bootrom lacks data or has serious corruption, this guide may not help you
  • This guide is only valid for Mac Pro 4.1 and 5.1
  • All data seen on screenshots are public or invented
  • I won’t support any builds faking serial no
Steps in short:
  • Transferring individual data inside Fsys- and Gaid-store from your own dump to the bootrom-template. Unfortunately, UEFITool can’t recognize NVRAM, Fsys- and Gaid-store, so we have to do this manually with hexeditor
  • Correcting both checksums in Fsys- and Gaid-store
  • Transferring individual data from last volume (MAC address, LBSN and build date) to raw-template
  • Exchange Section_Raw_Volume_Top_File_Volume_Top_File inside the (pre-) modified bootrom-template with the raw-template, using UEFITool 0.28
  • Check if all mods are correct and succesfull
Lets begin....
  • Open your bootrom-dump and one of the bootrom-templates (v144.0.0.0.0_template_EnableGop_v14.bin or v144.0.0.0.0_template.bin) with hexeditor
  • Search in your bootrom-dump inside the Fsys-stream containing ssn, hwc and son (maybe more); unfortunately the position is not fixed and depends from the lenght of previous content. You can generally try to search for textstring „ssn“, most editors will show the code converted to ANSI on the right.
  • Check if ssn, hwc and son are present and the order matches: All values are human-readable in ANSI.
  • Copy the string, including 03 (before ssn), ending with 46 (last digit of „EOF“). The lenght may also vary, in my example it has 0x2C lenght (donor right, template left): View attachment 2421686
  • In bootrom-template navigate to offset 0x1486A5, this is the position you’ll put in the string.
  • Overwrite (NOT insert!) in bootrom-template: View attachment 2421687
  • Now navigate in your dump to position 0x14880B (Gaid-entries). This position is fixed: View attachment 2421688
  • Copy the string including 04 (before „tsth“ begins), ending with 46 (last digit of „EOF“). It has 0x43 lenght and yet i did’t saw dumps with more or less entries.
  • Navigate in template to position 0x14880B and overwrite (NOT insert!) the string: View attachment 2421689
  • Save the template file.
  • Open modified template with UEFITool_NE and navigate to „EFISystemNvDataFvGuid“, „Fsys store“ and „Gaid store“: On the right window it will identify both CRC32-checksums as invalid. For luck, UEFITool_NE will show us the correct checksum, you have to write them manually in hexeditor. View attachment 2421692View attachment 2421693
  • Open the template in hexeditor: The checksums are 4 bytes long and located at fixed offsets 0x1487FC (for Fsys store) and 0x149FFC (Gaid store). Pay attention: The bytes are swapped, a suggested checksum e.g. 732FD5CB has to be written in hexeditor as CBD52F73. Thats why you can’t simply copy the checksum from UEFITool_NE and insert it directly with hexeditor, leave both apps open and type by hand. Checksum position Fsys store seen here: View attachment 2421851
  • And here for Gaid store:
  • View attachment 2421712
  • Save the template file, open again with UEFITool_NE and navigate to „EFISystemNvDataFvGuid“, „Fsys store“ and „Gaid store“: Both CRC32-checksums should now recognized as valid: View attachment 2421698View attachment 2421699
  • Open your bootrom-dump and Section_Raw_Volume_Top_File_Volume_Top_File.sct with hexeditor
  • In bootrom-dump navigate to offset 0x3FFF00 and copy the whole block with lenght 0x80. Check if it contains valid data; you can easy identify the LBSN (in example: J50324H3FBH9A) and build date (here: 100811100811=11 Aug. 2010) in ANSI in the pictures (right donor, left empty raw_volume). View attachment 2421700
  • In Section_Raw_Volume_Top_File_Volume_Top_File.sct navigate to offset 0x10 and overwrite (NOT insert!) the block. View attachment 2421701
  • Save the Section_Raw_Volume_Top_File_Volume_Top_File.sct.
  • Open the modified template with UEFITool 0.28 and navigate to last volume „04ADEEAD-61FF-4D31-B6BA-64F8BF901F5A“, last file „1BA0062E-C779-4582-8566-336AE8F78F09“, last section „Raw section“.
  • Select „Replace as is“ (not any other command!) and choose your modified Section_Raw_Volume_Top_File_Volume_Top_File.sct. View attachment 2421702
  • Save image file. UEFITool will correct ZeroVector and checksum, no manual editing needed. View attachment 2421705
  • Open the modified template with UEFITool_NE and check:
  • If all checksums are valid
  • All entries in Fsys- and Gaid-store are present
  • Last volume is marked as „AppleCRC“, this indicates a corrected ZeroVector (CRC32-checksum of body). View attachment 2421707
  • example of a non-corrected ZeroVector, seen on many dumps, "AppleCRC" missing: View attachment 2421710
  • For analyzing and flashing i recommend the linked dumper tool from „Macschrauber“: It is a handy tool with GUI and easy to use.
Now you’re ready to flash it to the machine. Good luck!
Click to expand...
i make this and my mac no run
 
With ZERO information i can't help you.

Btw., you can send me the dump and your generated bootrom-file (PM please, not public), i'll have a look whats wrong with it.
 
  • Like
Reactions: Jhonjhon236
Thank you for sharing your knowledge. Very straightforward guide! Successfully upgraded from MP51.0089.B00 to 144.0.0.0.0 w/o natively supported metal GPU (currently running w5500 Pro)
 
  • Like
Reactions: sheapuppy
Desoldered, flashed reconstructed via this guide into 4.1 with LPT port and resistor-based schema using spipgm by Rayer.
It booted, chimed and showed "no disk" image. I didn't research further.
 
Maybe a hardware issue or your DIY-made image or flashing went wrong, i can't judge this from here. This has nothing to do with the rebuilding process itself.
 
Brilliant work. I had previously tried other methods, downgrading OS's everything failed, with cryptic codes or just simply doing nothing. This worked with only very minor issues. The only things I would point out is, from Yosemite I could not run the A_65 version of the UEFITool_NE, but I was able to run the A_61 version. The second is on this image and in the text it was unclear if the "67 DC 05 CC" was expected to be identical, but as the checksum was valid I went for it.

1733859232657.png


Finally I had to go round the firmware write twice as the first time the Macschrauber tool reported the device was not in write mode. But the tool did give the information to correct the state and booting via the Firmware route and then running the Macschrauber tool again solved the problem. I guess starting the process after booting through the firmware startup would have solved this.

Once again @Borowski stunning bit of work, upgraded from a 4.1 B07 to 5.1 144.0.0. Now more cores more clocks and faster RAM is on the Christmas list.
 
  • Like
Reactions: sheapuppy
Hammerthief said:
The second is on this image and in the text it was unclear if the "67 DC 05 CC" was expected to be identical, but as the checksum was valid I went for it.
Click to expand...
The calculated value in Zero Vector is indivual to every bootrom and will differ, a correct calculation of Zero Vector will be indicate the volume as "AppleCRC32", compare the two example pictures in the last spoiler.

And to be clearly: Neither a wrong checksum nor false Zero Vector will brick a Mac Pro, especially in last volume, which is read-only. Technically yes, it is wrong, but nothing to worry about - or reason for paid reconstruction.
 
  • Like
Reactions: Hammerthief
Great job done, @Borowski!

I see no VSS sections on your screenshots.

I checked images with UEFITool and in my case firmware VSS1+padding+VSS2 is 131000 bytes, but in templates padding is 131000. Seems like both sections where not initialized.

Would be initialized on next boot?
 
Yes, exactly. See also my screenshots, the empty VSS is being reported.

Dump the bootrom after restart and open w/ UEFITool NE, both VSS will be present.

I didn't tried correctly dummy-formatted, but empty VSS1+2 yet.
 
  • Like
Reactions: max_verem
Borowski said:
I didn't tried correctly dummy-formatted, but empty VSS1+2 yet.
Click to expand...
Done:

formatted_nvram_volume.PNG


As i wrote, this is only a cosmetic "issue" and won't affect function or rebuilding the bootrom and is gone after the first boot.
Nevertheless i adjusted both template files to show a correctly formatted, empty VSS1+2 in UEFITool, look inside the zipped file attached. Anyway, this isn't mandatory and you can also use the old files instead.
 

Attachments

  • templates_II.zip
    3.4 MB · Views: 33
  • Like
Reactions: max_verem
I recently purchased a replacement backplane for my 2009 cMP4,1, due to breaking the battery clip on the original backplane. I had previously updated the bootrom to 144.0.0.0.0 and modified the machine quite heavily, but that was several years ago. I haven't done anything to the replacement backplane other than install it, along with the original CPUs, RAM, GT120 GPU, and an old Mavericks boot disk to verify the replacement works.

As I was re-researching the process to bring the replacement backplane up to 5,1 and 144.0.0.0.0, I read some threads indicating the need to have the proper SN, build date info, etc. in the bootrom for applications requiring serialization. I have rom dumps from the original backplane as well as the replacement. However, it doesn't seem like there is any value or use for the romdumps from the replacement backplane given the templates provided.

If I'm understanding the information and process above correctly, this should save me several steps, including adding EnableGOP, which I hadn't yet done, but was planning to do. Would you please confirm if my understanding is correct and let me know if there is anything else I should be considering? This will hopefully allow me reinstall my faster CPUs, 128GB of RAM, Radeon VII and NVMe RAID drive and start using Monterey again sooner. Much thanks for this valuable information!
 
If you have a blank (maybe unserialized) backplane, it is possible to insert parts of the old board, but that is not exactly the same process.

Do you habe dumps of both boards?
 
Borowski said:
If you have a blank (maybe unserialized) backplane, it is possible to insert parts of the old board, but that is not exactly the same process.

Do you habe dumps of both boards?
Click to expand...
Yes, I have both rom dumps. The original rom dump ssn matches the sn printed on the back of my case. It also has the ssn, hwc, and son details in the correct order as well as what looks like the logic board sn and build date. Although, the logic board sn in the rom dump does not match the logic board sn as presented in "About This Mac". The first seven characters are the same, but the last six are different. The replacement backplane rom dump does not contain these additional details.
 
It is possible to merge the data. This is what Apple does when replacing backplane by service provider, but there are known cases, they forgot to do it correctly.
 
Which parts should be merged? Would I use the replacement backplane ssn with the hwc and son details of the original as well as the lbsn and build date of the original and then insert into your template?
 
If your backplane is a used part coming e.g. from a scrapped machine, do the rebuilding as described. Only cosmetic issue are the non-matching IDs (serial no. and ethernet) on the grey sticker.
Check if all needed IDs are present in your bootrom, look at the screenshots.

Reefwalker said:
Although, the logic board sn in the rom dump does not match the logic board sn as presented in "About This Mac". The first seven characters are the same, but the last six are different. The replacement backplane rom dump does not contain these additional details.
Click to expand...
The LBSN (logic board serial no.) is not the same as the ssn, LBSN is printed on a sticker, but the ssn isn't and only readable from "about this Mac" or dumped rom.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back