Contribute
Register

How to build your own iMac Pro [Successful Build/Extended Guide]

Status
Not open for further replies.
kgp said:
D.3
3.) Yet we have to make our iMac Pro macOS USB Flash Drive Installer also bootable. This can be partly done by means of the following terminal commands:

cd /Volumes/USB_VOLUME
mkdir .IABootFiles
cd .IABootFiles
cp /Volumes/USB_VOLUME/System/Library/CoreServices/boot.efi .
Click to expand...

Hi KGP, I tried these terminal commands but i think the "cp /Volumes/USB_VOLUME/System/Library/CoreServices/boot.efi ." has some issues, this command is missing something.... any ideas?

Thanks for your guide!
 
filmafx said:
Hi KGP, I tried these terminal commands but i think the "cp /Volumes/USB_VOLUME/System/Library/CoreServices/boot.efi ." has some issues, this command is missing something.... any ideas?

Thanks for your guide!
Click to expand...

Yes it misses the real name of YOUR_USB_VOLUME! ;):lol:
 
kgp said:
Yes it misses the real name of YOUR_USB_VOLUME! ;):lol:
Click to expand...
haha, I see my issue now, its fixed... there was a space before the period, but it deleted it, thinking it was a mistake.
 
NucFlan said:
When updating Clover, I'm unsure about what I really need to set as a custom install or is the standard better?
Click to expand...
I suppose there is not a clear answer for this. The default is definitely not better, since there are a few drivers that are best left out. However, I prefer to have extra work: I install all drivers, and then manually go to the drivers64UEFI and remove the ones I don't need. I place them in a backup folder, in case I discover that I need them after all. Others perhaps prefer to not install some drivers from the beginning. Remember to only use one of the AptioFix drivers, and to always select "Install for UEFI booting only".

NucFlan said:
My M2 (main drive) has a weird naming convention, I get the idea of APFS containers, but the disk numbers in Clover don't align with what I see in Disk utility. There is a FAT32 in the main container that has the EFI for booting.
Click to expand...
I don't understand what you mean by "disk numbers in Clover". Does Clover use disk numbers somewhere?

I think you might be confusing something about APFS. I think "Disk Utility" has a very bad interface, and I prefer to use the command line diskutil:

An APFS partition is mounted as a whole virtual disk (it shows as "synthesized" in diskutil). But this virtual disk does not have the fat32 partition, that belongs to your real boot disk. And that fat32 partition, like you said, is the special one -- it has some special flags that mark it as ESP (EFI System Partition), where the UEFI looks for *.efi files to boot.

Here's my partition configuration:

Code: 
$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.1 TB     disk0
   1:                        EFI ESP_SSD                 536.9 MB   disk0s1
   2:                  Apple_HFS Local                   930.0 GB   disk0s2
   3:                 Apple_APFS Container disk3         65.9 GB    disk0s3
   4:       Microsoft Basic Data Data                    53.5 GB    disk0s4

/dev/disk1 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         250.1 GB   disk1
   1:                        EFI ESP_NVME                536.9 MB   disk1s1
   2:       Microsoft Basic Data Win10                   93.5 GB    disk1s2
   3:           Windows Recovery                         889.2 MB   disk1s3
   4:                 Apple_APFS Container disk2         104.9 GB   disk1s4
   5:           Linux Filesystem                         50.3 GB    disk1s5

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +104.9 GB   disk2
                                Physical Store disk1s4
   1:                APFS Volume macOS                   45.2 GB    disk2s1
   2:                APFS Volume Preboot                 21.0 MB    disk2s2
   3:                APFS Volume Recovery                515.1 MB   disk2s3
   4:                APFS Volume VM                      17.2 GB    disk2s4

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +65.9 GB    disk3
                                Physical Store disk0s3
   1:                APFS Volume Test                    12.9 GB    disk3s1
   2:                APFS Volume Preboot                 21.3 MB    disk3s2
   3:                APFS Volume Recovery                514.8 MB   disk3s3
   4:                APFS Volume VM                      17.2 GB    disk3s4

I have 2 disks, disk0 and disk1.

Both have an ESP, in disk0s1 and disk1s1. This is not necessary, but I always keep one with an old Clover that I know is bootable, and install new stuff Clover and new configs in the other.

Then you'll see that disk0 has an APFS partition in disk0s3 and that disk1 has another in disk1s4.

Each APFS partition shows up has a virtual disk: disk0s3 is disk3 and disk1s4 is disk2. Finally, each of these virtual disks shows the partitions they have: disk3s1 and disk2s1. But since each of these partitions has a full macOS inside (I use disk2s1="macOS" as my normal boot partition and disk3s1="Test" as a test partition), each APFS virtual disk also has a Preboot and a Recovery partition.

But you see, the container (the APFS partition in the real disk) does not have the ESP.
 
Last edited:
interferenc said:
Okay so I've done some more research.

Based on Pike's work here:
https://pikeralpha.wordpress.com/2016/08/10/checks-for-two-unused-processor-models-found/

I have pinpointed that the _xcpm_core_scope_msrs patch does only one thing: disables writes the MSR 0xE2. For our skylake X processors, the kernel wants to write 0x7e000003. With the patch disabled, I get the E3 error on wake. BUT I checked the KP report, like the others here and this part
Code: 
0xfffffd000004c6d0 : 0xffffff801698c6b4 mach_kernel : _xcpm_perf_bias_set + 0x294
0xffffffa7644dbc20 : 0xffffff801698c9be mach_kernel : _xcpm_init + 0xde
Points to the exact wrmsr instuction the patch disables.

In fact, the processor register dump clearly shows
Code: 
*** Panic Report ***
panic(cpu 0 caller 0xffffff801696e349): Kernel trap at 0xffffff801698c6b4, type 13=general protection, registers:
CR0: 0x0000000080010033, CR2: 0x000000010a141000, CR3: 0x000000002c354000, CR4: 0x00000000003627e0
RAX: 0x000000007e008003, RBX: 0xffffff8017057320, RCX: 0x00000000000000e2, RDX: 0x0000000000000000
RSP: 0xffffffa7644dbbf0, RBP: 0xffffffa7644dbc20, RSI: 0x0000000000000003, RDI: 0xffffff80170572c0
R8:  0x0000000100000201, R9:  0xffffff801a80101f, R10: 0x0000000000000003, R11: 0xffffff8016f70eeb
R12: 0xffffff8016f78896, R13: 0x0000000000000001, R14: 0x0000000000000000, R15: 0xffffff8016f7887c
RFL: 0x0000000000010046, RIP: 0xffffff801698c6b4, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x000000010a141000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 0

RAX gets written to the lower 32 bits of the MSR named in RCX, and that is exactly what I tought it is: 7e008003 to 0xe2!

So in essence, on wake, the kernel tries to write to the MSR 0xE2 again, and this time it fails. I think it might be locked at that point. Because I just checked, and with an unlocked register, I can write to it whatever I want without a KP. So maybe, just maybe, the BIOS has another point where it locks the register, probably on s3 wake. That's my best guess so far, and I will look into the bios again.
Click to expand...

This was exactly my suspicion which you herewith impressively confirmed :thumbup:

Do you think we will be able to add another patch?
 
ccozmo said:
The iMacPro is using RAID 0 with two drives - giving it better performance.

I tried back on Sierra to use Apple RAID on 2 x NVME drives, however the performance was not much better than a single drive.\

Does anyone know how the iMacPro is doing RAID ? Is it BIOS or using the Apple RAID ?

Would like to try and create the RAID and see if performance is now improved
Click to expand...

Hi @ccozmo,

Did you ever get a response to this question? Or have you tried one on your own?

I'm interested in setting up a RAID and was wondering what the best configuration was.

@Thireus, I think you said you set up a RAID, would you mind sharing what mechanism you used?

Thanks!
 
Hi

I have just followed these instructions to get up and running with an ASUS X299 deluxe and High Sierra 10.13.3.
For some reason I could not get the patched Nvidia drivers installed so I am using the latest ones for 10.13.3 (17D2047) and they seem to be working well for me with 2 x EVGA GeForce 970 cards in SLI. No obvious lagginess.

I am having trouble with the sound though. When playing music in iTunes there is a crackling. It seems to get worse the more complex the music is. Same applies if playing sound on a video in safari on you tube.

I used the VoodooHDA method, putting the edited kext into EFI/CLOVER/Kexts/Other and the other file in the PreferencePanes folder. This has made sound work, but either through the front audio jack or the rear I am getting this interference in sound.

Anyone have any ideas on how to solve this at all please?

Rob
 
robham said:
I am having trouble with the sound though. When playing music in iTunes there is a crackling. It seems to get worse the more complex the music is. Same applies if playing sound on a video in safari on you tube.

I used the VoodooHDA method, putting the edited kext into EFI/CLOVER/Kexts/Other and the other file in the PreferencePanes folder. This has made sound work, but either through the front audio jack or the rear I am getting this interference in sound.

Anyone have any ideas on how to solve this at all please?

Rob
Click to expand...

You have to install the VoodooAudio Preference Panel and move one slider a bit. That should remove the noise. It happens to me after each reboot.

I have used the VoodooAudio on several hacks, and I always had this problem that after restart it is necessary to tweak the controls a bit.
 
System froze just now... :( after more than 2 days of uptime. So none of the changes I've made are relevant to fix the issue.

Now I'm thinking that it might be GPU related. What I just did before the freeze happened is to put the screens to sleep. The screens are off now, so I cannot turn them back on, I can't ssh to the system, hard drive LED doesn't blink either (meaning the system isn't working).

Sorry for the false hope :(.

EDIT: The panic report is now different from what I had earlier...

Code: 
Anonymous UUID:       3016C5F0-081C-315F-2D7E-D03EF4FFBBA3

Wed Jan 31 06:47:13 2018

*** Panic Report ***
panic(cpu 4 caller 0xffffff801816e349): Kernel trap at 0xffffff8018000a2c, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0xffffff832deffaf8, CR3: 0x00000018bdb440d6, CR4: 0x00000000003627e0
RAX: 0xffffff8017d06020, RBX: 0x000000000000a75a, RCX: 0xffffff8129da9a10, RDX: 0x0000000062c3f35b
RSP: 0xfffffd000004e720, RBP: 0xffffff8e2a9b3dd0, RSI: 0x0000000000000008, RDI: 0xffffff801880af78
R8:  0x0000000000000000, R9:  0x0000000000000001, R10: 0x0000000000000000, R11: 0x0000000000000202
R12: 0x0000000000000000, R13: 0x0000000000000000, R14: 0xffffff8018775ff7, R15: 0xfffffd000004e720
RFL: 0x0000000000010002, RIP: 0xffffff8018000a2c, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0xffffff832deffaf8, Error code: 0x0000000000000000, Fault CPU: 0x4, PL: 3, VF: 5

Backtrace (CPU 4), Frame : Return Address
0xfffffd000004dec0 : 0xffffff801804f606 mach_kernel : _handle_debugger_trap + 0x506
0xfffffd000004df10 : 0xffffff801817c744 mach_kernel : _kdp_i386_trap + 0x114
0xfffffd000004df50 : 0xffffff801816e159 mach_kernel : _kernel_trap + 0x5e9
0xfffffd000004dfd0 : 0xffffff8018001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004dff0 : 0xffffff801804f03c mach_kernel : _panic_trap_to_debugger + 0x25c
0xfffffd000004e120 : 0xffffff801804edbc mach_kernel : _panic + 0x5c
0xfffffd000004e180 : 0xffffff8018179e08 mach_kernel : _mp_kdp_enter + 0x468
0xfffffd000004e1d0 : 0xffffff801804f16a mach_kernel : _handle_debugger_trap + 0x6a
0xfffffd000004e220 : 0xffffff801817c744 mach_kernel : _kdp_i386_trap + 0x114
0xfffffd000004e260 : 0xffffff801816e159 mach_kernel : _kernel_trap + 0x5e9
0xfffffd000004e2e0 : 0xffffff8018001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004e300 : 0xffffff801804f03c mach_kernel : _panic_trap_to_debugger + 0x25c
0xfffffd000004e430 : 0xffffff801804edbc mach_kernel : _panic + 0x5c
0xfffffd000004e490 : 0xffffff801816e349 mach_kernel : _kernel_trap + 0x7d9
0xfffffd000004e610 : 0xffffff8018001120 mach_kernel : _return_from_trap + 0xe0
0xfffffd000004e630 : 0xffffff8018000a2c mach_kernel : _ks_32bit_entry_check + 0x16c
0xffffff8e2a9b3dd0 : 0xffffff80181776f3 mach_kernel : _mp_cpus_call_cpu_init + 0x3e3
0xffffff8e2a9b3e40 : 0xffffff8018177278 mach_kernel : _cpu_signal_handler + 0x3c8
0xffffff8e2a9b3f50 : 0xffffff8018176053 mach_kernel : _lapic_interrupt + 0x43
0xffffff8e2a9b3f70 : 0xffffff801816d856 mach_kernel : _interrupt + 0x136
0xffffff8e2a9b3fd0 : 0xffffff80180012d6 mach_kernel : _hndl_allintrs + 0x126
0xffffffce85b43df0 : 0xffffff801816503f mach_kernel : _usimple_lock + 0x2f
0xffffffce85b43e30 : 0xffffff8018036afd mach_kernel : _ipc_mqueue_copyin + 0x8d
0xffffffce85b43e60 : 0xffffff8018044897 mach_kernel : _mach_msg_overwrite_trap + 0x97
0xffffffce85b43ef0 : 0xffffff801815858d mach_kernel : _mach_call_munger64 + 0x1fd
0xffffffce85b43fa0 : 0xffffff8018001926 mach_kernel : _hndl_mach_scall64 + 0x16

BSD process name corresponding to current thread: ccminer
Boot args: -v dart=0 keepsyms=1 debug=0x100 

Mac OS version:
17D2047

Kernel version:
Darwin Kernel Version 17.4.0: Tue Dec 19 10:52:05 PST 2017; root:xnu-4570.47.16~1/RELEASE_X86_64
Kernel UUID: 29EF1F85-10C5-3F25-AED6-5529E5948D42
Kernel slide:     0x0000000017c00000
Kernel text base: 0xffffff8017e00000
__HIB  text base: 0xffffff8017d00000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)

System uptime in nanoseconds: 184007461548435
last loaded kext at 92605088619172: com.apple.driver.CoreStorageFsck    546 (addr 0xffffff7f9b863000, size 98304)
last unloaded kext at 92785996583668: com.apple.driver.usb.cdc    5.0.0 (addr 0xffffff7f9b854000, size 28672)
 
Last edited:
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top