This is not the bootROM reconstructed by you, that machine is still not in use at the moment.
This is from another 4,1->5,1 machine, running High Sierra in the last 90 days or so:
And after another reboot:
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 MacPro5,1: BootROM thread | 144.0.0.0.0
- Thread starter tsialex
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
This is not the bootROM reconstructed by you, that machine is still not in use at the moment.
This is from another 4,1->5,1 machine, running High Sierra in the last 90 days or so:
And after another reboot:
Well.. Because I'm lazy and I understand that the good practice of dumping from the vanilla installs is mainly to get it to flash and not just to check the VSS free space, I checked what happens after a deep nvram reset without disabling the OC and booting into Mojave. UEFI Tool shows now 52430 in first VSS und 65448 in second VSS store.
Many thanks tsialex for your help!
Because I have Open Core on a SATA SSD and Big Sur on NVMe there were no problems after reboot either.
I think this is probably good configuration f anyone is thinking about installing OC on cMP
I also don't see any other problems with Handoff or AirDrop so far....
However, I understand that it would be good to make a current dump from under Mojave to have a "backup", right?
Many thanks tsialex for your help!
Because I have Open Core on a SATA SSD and Big Sur on NVMe there were no problems after reboot either.
I think this is probably good configuration f anyone is thinking about installing OC on cMP
I also don't see any other problems with Handoff or AirDrop so far....
However, I understand that it would be good to make a current dump from under Mojave to have a "backup", right?
Correct, save your best BootROM image securely - you will need to flash it again. Also, if your SPI flash fail in the future you can replace the SPI/buy a MATT card and then flash your own BootROM image to it.
Here is interesting comparison of my Mac Pro 4.1>5.1 Dual Processor with 8 RAM DIMMS (8 x 4Gb)
Before and after NVRAM deep clean (4 chimes)
Before and after NVRAM deep clean (4 chimes)
Yep, UDIMMs if yours are the same as the photo. UDIMMs take a lot less SPD cache space inside the VSS store than RDIMMs, but unfortunately it's almost impossible to get UDIMMs bigger than 4GB at a reasonable cost.
Thanks for your input Here is the photo of them - same part number but look different....
If you had 8 RDIMMs you won't have so much available space since the configuration for registered RAM takes a lot more MemoryConfig space.
I have 3 OWC 8GB DIMMs here, also UDIMMs - donation from an Aussie MR user that was upgrading to a newer Mac Pro. Thx again if you read this!
Thanks Alex - very interesting, I learn a lot from these forums and yourself, you are a great asset
And yes the User who donated you RAM is a good dude...
Apple says garbage collection was declared deprecated in OS X Mountain Lion and removed from the Objective-C runtime library in macOS Sierra.
Last edited by a moderator:
Please explain me what the Apple flavor of the Intel TIANO EDK I EFI implementation have anything to do with Objective-C runtime?
Cross-flashed early-2009 Mac Pros are extremely susceptible of NVRAM corruption, lot's of people bricking these recently, cmizapper is probably very happy making and shipping MATT cards.
I'll send you a PM shortly.
Is it the case that UsbBusDxe is not present in 144.0.0.0.0?
Not likely but wondering why people need UsbBusDxe on the recent XhciDxe posts if already loaded by the firmware.
EDIT ... Possible Answer:
Apple might have used a tweaked version for 5,1
Still present, 10.14.6 144.0.0.0.0 MP51.fd.
GUID 240612B7-A063-11D4-9A3A-0090273FC14D - UsbBusDxe
Clearly tweaking it over time ... 3,1 version metadata:
Code:
Fixed: No
Base: AA208h
Header address: FFEAA208h
Data address: FFEAA220h
Offset: AA208h
File GUID: 240612B7-A063-11D4-9A3A-0090273FC14D
Type: 07h
Attributes: 40h
Full size: 2261h (8801)
Header size: 18h (24)
Body size: 2249h (8777)
Tail size: 0h (0)
State: F8h
Header checksum: 83h, valid
Data checksum: DFh, validMaybe it works because it's reloaded after the XHCI driver? Maybe you can just reload the UsbBusDxe from the firmware.
Comparing the protocols with and without UsbBusDxe may be interesting:
dh -d -v > dh_d_v.txtThe Usb Bus Driver (UsbBusDxe 240612B7-A063-11D4-9A3A-0090273FC14D) manages all the host controller drivers (protocols UsbHc and UsbHc2)
On my MacPro3,1, it seems that the Usb Uhci Driver is loaded before the USB Bus Driver (the Usb Uhci Driver has a lower handle number). After those is loaded the USB class/device drivers:
Usb Bot Mass Storage Driver
Usb Cbi0 Mass Storage Driver
Generic USB Mass Storage Driver
Usb Keyboard Driver
Usb Mouse Driver
Apple HID Interface Driver
etc.
Then later the USB PCIe devices have the host controller protocols (UsbHc and UsbHc2) from the host controller drivers attached to them.
It seems that there's only a UHCI driver that gets loaded (class code 0C 03 00). There's no EHCI driver or it doesn't get loaded (for class code 0C 03 00) for the EHCI host controller. Does that mean EFI only supports USB 1.1 speed?
macOS shows USB devices are connected to EHCI controller and not the four UHCI controllers - I suppose the devices are switched over from one controller to the EHCI controller.
It seems to be actually that the MacPro3,1 only provides USB 1.x speeds as while it comes with five USB 2.0 ports, Apple appears to have forgotten to provide the needed driver in the firmware and only included UhciDxe (USB 1.x).
MacPro5,1 has UhciDxe and EhciDxe (USB 2.x) and apparently, the Trashcan has XhciDxe (USB 3.x) in addition to those two.
Not sure why EhciDxe was not provided on the MacPro3,1 since the USB 2 ports are there. Could they have patched their UhciDxe? Doesn't make sense either way. Must be missing something.
Are you sure that the name is UsbHubDxe? What is the GUID?
Attachments
Typo ... I meant UsbBusDxe.
MP31 version has 240612B7-A063-11D4-9A3A-0090273FC14D as GUID.