Jump to content

fabiosun

Recommended Posts

  • Moderators
1 hour ago, dtek said:

I have an old monitor that only supports hdmi.  Upgraded to the latest OC build but only sleep mode worked,  shutdown/restart froze

I'm not sure how to calculate hex values for disabled 4g.  I read it a few times and still didn't get it.

MMIO.zip 189 B · 0 downloads

 

The linked instruction is about as lucid as you'll find on such an esoteric build. But this makes me wonder did you actually create the debug file to generate your own hex values? 

 

Do you understand that OC comes in RELEASE and DEBUG versions, and you need to use the latter? (The link within the link, here, again, tells you how to make this file in steps A1 a + b.)

 

Look at the pop-up that has green/red numbers (4th spoiler) in first link (here again). Those are hex. The hex values are given in your debug text file. The white numbers in the right column are decimal. You calculate the decimals equivalent, from the hex values, derived from your debug file. (Even the built-in Mac calculator can convert; Google for other on-line calculators if you don't like that one.)

 

The left green/red values should be similar to those in your debug file. Look for a pattern. Your list created in the debug file should match up (as described).

 

Building a Hackintosh, and esp a TRX40, means having to sit and think about things on your own. Problem solving is part of building one, and will be for the life of the computer.  Develop those problem solving skills now.

 

  • Like 1
Link to comment
Share on other sites

  • Moderators
1 hour ago, Driftwood said:

 

Now PikerAlpha is a legend... works for Apple now I heard!

 

Oh, and there you are @fabiosun all over the comments! 🙂 I used to read his stuff. One of the best gurus around. 🙂

 

So we're back to looking for 0x3f 

 

Boy! Havent times moved on @fabiosun ?

 

 

2092763700_ScreenShot2020-09-08at23_18_51.png.7604fed0f29b042c51a8fc0bf7b33e2e.png

 

 

 

PikerAlpha used to work for Apple and stopped writing a few years ago after his wife was killed in an auto accident. (Whether he is working again for Apple, I don't know.)

Link to comment
Share on other sites

17 hours ago, iGPU said:

 

It should work on all of our mobos. Code is below to copy/paste (I added to comments to show how it is derived; data are basically ascii to hex conversions).

 


<key>Delete</key>
		<array>
			<dict>
				<key>All</key>
				<false/>
				<key>Comment</key>
				<string>Delete SHAKTOOH (hex=oemtab); hex SSDT=tablesig; 4271=0010AF (from "log show --last boot | grep ACPI")</string>
				<key>Enabled</key>
				<true/>
				<key>OemTableId</key>
				<data>
				U0hBS1RPT0g=
				</data>
				<key>TableLength</key>
				<integer>4271</integer>
				<key>TableSignature</key>
				<data>
				U1NEVA==
				</data>
			</dict>
		</array>

 

 

 

Initially had some trouble interpreting your comment but it dawned on me what it meant after I translated "SHAKTOOH" to hex. Fixed now. Thank you!

 

 

 

 

 

Edited by meina222
Issue fixed
Link to comment
Share on other sites

Big Sur Bare Metal Candle Test

(Not as Quick As Proxmox, however we are using a patched dylib library replacing BMDs own to get Davinci Resolve working under Big Sur / AMD bare metal - and AMD BM is not supported under Mac from Davinci..

 

But even with the patch, it's still very acceptable.

 

* On Proxmox I was getting apx 34fps on 66 Blur Nodes, Here around 20-24fps at moment of screen grab. Had a load of background apps going on if that didn't help.

 

Test is available from here: https://www.liftgammagain.com/forum/index.php?threads/resolve-standard-candle-benchmark.3718/. (top three links in comment 1 of thread)

 

Free Version of Davinci Resolve available here from BMD:  https://www.blackmagicdesign.com/uk/support/ (see latest downloads, bottom left hand pane of browser)

 

Davinci Patch For AMD:  AMD-Davinci-Fix .zip (from iGPU link)

 

1373510086_66BlurNodesCandleTestDavinci.png.5fc8c29aa543a863b27a212534f9f0ae.png83126566_6TRNNodes.png.1bf856cbd9ba04e5bb3a7de0a48a9a04.png

 

 

Edited by Driftwood
Link to comment
Share on other sites

7 hours ago, Ploddles said:

Yay, just updated to the latest 'release' version of OC, 0.6.1, and it appears to have solved my sleep problem. I need to do more testing but looking good so far.

Is the system as stable as before after disabling PAT patch? 

5 hours ago, meina222 said:

Gigabyte finally released their AGESA 1.0.0.4 BIOS-es. @Ploddles - if you upgrade your BIOS, you need to redo the MMIO list procedure highlighted by @iGPU and also reconfigure your VMs as the memory map has changed significantly.

Are there some stability (or other) benefits to upgrading the BIOS?

Link to comment
Share on other sites

41 minutes ago, Jaidy said:

Is the system as stable as before after disabling PAT patch? 

Are there some stability (or other) benefits to upgrading the BIOS?

For me yes - prior to version f4j (just preceding this one, I suspect they are very similar, it's internal and not public) I could not operate Slot 4 with the AIC NVME 4x4x4x4 card in Slot 3 and GPU in Slot 1. Slot 4 was crippled and only running at gen 1.0 speed not enabling use of TB add-in card or 2nd modern GPU. So it fixes a clear PCI resource allocation bug. I don't know what changes AGESA 1.0.0.4 brings or whether my BIOS already has it. If you don't have issues with your BIOS and do not want to go through the tedious steps of reconfiguring your MMIO and VM passthrough id's (they shifted) then you don't need to upgrade. Upgrading without any EFI / config changes will almost surely break your Bare Metal and VM boots.

Link to comment
Share on other sites

2 hours ago, iGPU said:

 

The linked instruction is about as lucid as you'll find on such an esoteric build. But this makes me wonder did you actually create the debug file to generate your own hex values? 

 

Do you understand that OC comes in RELEASE and DEBUG versions, and you need to use the latter? (The link within the link, here, again, tells you how to make this file in steps A1 a + b.)

 

Look at the pop-up that has green/red numbers (4th spoiler) in first link (here again). Those are hex. The hex values are given in your debug text file. The white numbers in the right column are decimal. You calculate the decimals equivalent, from the hex values, derived from your debug file. (Even the built-in Mac calculator can convert; Google for other on-line calculators if you don't like that one.)

 

The left green/red values should be similar to those in your debug file. Look for a pattern. Your list created in the debug file should match up (as described).

 

Building a Hackintosh, and esp a TRX40, means having to sit and think about things on your own. Problem solving is part of building one, and will be for the life of the computer.  Develop those problem solving skills now.

 

The file that I attached has my own hex values in it.  I used Fabiosun's mmiowhitelist because we have the same board.   Your instructions are very clear,  it's just that I'm very new at this.  It's literally my first build.  I definitely spent way more time on this than I'd like,.  Thanks for the tip tho,  appreciate your work

3 hours ago, Driftwood said:

@dtek

Do u have this in BIOS? Or equivalent?

 

I enabled S5 Soft off for USB wakeup and it seems it guarantees it in BS BM. 

DSC_0385.JPG

 

Havent tried the others yet...

I was able to change wakeup to OS/BIOS and it's working perfectly now. thanks

Link to comment
Share on other sites

4 hours ago, fabiosun said:

I see different stuff in your boot arg

npci=0x2000 shouldn't be there for our motherboard

and if use it 4g have to be off

I would try without that arg and with 4g enabled

also I do not use any SSDT, only one for NVRAM..but it is not mandatory to boot

 

By the way..I do not use intensively Big Sur so some your args could be mandatory for it...but IDK

@dtek

Do you by any chance use the 10g lan card that comes with the board?  Mine suddenly stopped working.  I don't know if it's  related to MMIO whitelist editing I just made and/or the removal of SSDT.  I have to revert the changes to see if it works again.

Link to comment
Share on other sites

@dtek

 

There is hardly any way to get all quirks worked out without spending time 😂. There’s an added benefit of being able to adapt to BIOS and hardware upgrades much more easily on your own. I think I burnt hundreds of hours on this - more than the cost of a brand new 28 core Mac Pro for sure in man-hours.

 

Edited by meina222
  • +1 2
Link to comment
Share on other sites

1 hour ago, meina222 said:

@dtek

 

There is hardly any way to get all quirks worked out without spending time 😂. There’s an added benefit of being able to adapt to BIOS and hardware upgrades much more easily on your own. I think I burnt hundreds of hours on this - more than the cost of a brand new 28 core Mac Pro for sure in man-hours.

 

Yeah for real I spent more time on this build than at my actual job lol. I agree it's a never ending learning curve.  All good tho, with everything going on, I take this opportunity to gain extra knowledge.  Also that's a crazy nice setup you got there.  I'm so jealous hah

Edited by dtek
Link to comment
Share on other sites

14 hours ago, Jaidy said:

Is the system as stable as before after disabling PAT patch? 

Are there some stability (or other) benefits to upgrading the BIOS?

 

Yes, the system is very stable. Updating the BIOS has benefits if you have more than 1 graphics card - Above 4G can now be enabled without it hanging the system. Big Sur and Catalina now boot fine with or without Above 4G enabled. The MMIO Whitelist hasn't changed, the values obtain with the Debug are the same as with the previous BIOS version. They are also the same with or without Above 4G enabled so you don't need to make any changes for that to your config file.

 

You do need to make changes to the config.plist if you update to OC 0.6.1, eg you need to add the Arch - String - Any values to all your Add (kexts) and Patch sections in the Kernel part. There are a few other bit dotted throughout the rest of the config as well.

 

If you want I can upload my updated config.plist file and you can see and compare with yours and see where the changes are.

  • +1 1
Link to comment
Share on other sites

  • Moderators
15 hours ago, dtek said:

Do you by any chance use the 10g lan card that comes with the board?  Mine suddenly stopped working.  I don't know if it's  related to MMIO whitelist editing I just made and/or the removal of SSDT.  I have to revert the changes to see if it works again.

 

Aquantia is supported natively through Mojave (and I thought ok in Catalina), but Big Sur requires a kernel patch. The inactivation has nothing to do with SSDT or MmioWhitelist.

 

Pavo has provided this on another forum. Here it is below (as written this will work on HS thru BS; if you only want for Catalina-BS, change 17.0.0 to 19.0.0):

 

AquantiaPatch.jpg.59e4e6a32930524d9031b97941c5763f.jpg

Link to comment
Share on other sites

  • Moderators
3 hours ago, Ploddles said:

 

Yes, the system is very stable. Updating the BIOS has benefits if you have more than 1 graphics card - Above 4G can now be enabled without it hanging the system. Big Sur and Catalina now boot fine with or without Above 4G enabled. The MMIO Whitelist hasn't changed, the values obtain with the Debug are the same as with the previous BIOS version. They are also the same with or without Above 4G enabled so you don't need to make any changes for that to your config file.

 

You do need to make changes to the config.plist if you update to OC 0.6.1, eg you need to add the Arch - String - Any values to all your Add (kexts) and Patch sections in the Kernel part. There are a few other bit dotted throughout the rest of the config as well.

 

If you want I can upload my updated config.plist file and you can see and compare with yours and see where the changes are.

 

Many changes occurred at the end of v061, carrying over into v062. These late changes are all in the Kernel section, adding "Force" and "Scheme" sub-sections as well as an "Arch" parameter for each Add, Block, Force, and Patch sub-section entry.

 

At the very end of v061, a new quirk was added, DisableLinkeditJettison. This new quirk is specifically for Big Sur and should be enabled. (To quote the Docs, "This option lets Lilu.kext and possibly some others function in macOS Big Sur with best performance without keepsyms=1 boot argument.")

 

OC-Kernel-Changes.jpg.11cb2a0f881a80b482d46749f8286eed.jpg

 

 

Edited by iGPU
  • +1 1
Link to comment
Share on other sites

Adobe Apps Patch LINK. As a reminder for the group ALL Adobe BETA products now work without patching EXCEPT Photoshop and Illustrator.

 

These Adobe Creative Cloud (2020) patches will do everything for current releases, but soon you wont need to do all of CC hopefully on final release (lets hope they do'nt recompile the Release candidates!).

 

https://gist.github.com/naveenkrdy/26760ac5135deed6d0bb8902f6ceb6bd

 

Screen Shot 2020-09-09 at 18.41.26.png

Edited by Driftwood
  • Like 1
Link to comment
Share on other sites

1 hour ago, iGPU said:

 

Aquantia is supported natively through Mojave (and I thought ok in Catalina), but Big Sur requires a kernel patch. The inactivation has nothing to do with SSDT or MmioWhitelist.

 

Pavo has provided this on another forum. Here it is below (as written this will work on HS thru BS; if you only want for Catalina-BS, change 17.0.0 to 19.0.0):

 

AquantiaPatch.jpg.59e4e6a32930524d9031b97941c5763f.jpg

That was a typo at the time I posted a screenshot of that. That patch only works with BigSur beta 3 and above.

  • +1 1
Link to comment
Share on other sites

On 9/8/2020 at 2:38 PM, Driftwood said:

It's Apple who keep dropping the hardware support. The last great bastion is encoding HEVC PQ Rec2020 420 10-bit for HDR TV/Netflix style delivery. 

I haven't seen any NLE that can beat x265 CPU encoding. And that's the way I do it and using Handbrake GUI. Threadripper with 32 cores64 threads beats them all at software CPU encodes.  Ridiculously fast!

 

At 8-bit HEVC or h264 Media Encoder and fcpx etc... work well. It's 10-bit and now 12-bit HEVC that is the problem as it is so mathematically challenging.

Davinci resolve gives me around 8fps in 10 bit. They're all slow outside x265.

 

True 10-bit HEVC hardware support will need to be sorted out in Mac. And Apple are directly responsible for stopping AMD and Nvidia in their tracks - certainly for 'prosumer' level cards.

We need encode, not just decode!

We wait with baited breath to see support returned.

I'm just worried that Apple's hardware "solution" is going to require After Burner card or at least T2, either way leaving us out in the cold.

Link to comment
Share on other sites

12 hours ago, Ploddles said:

 

Yes, the system is very stable. Updating the BIOS has benefits if you have more than 1 graphics card - Above 4G can now be enabled without it hanging the system. Big Sur and Catalina now boot fine with or without Above 4G enabled. The MMIO Whitelist hasn't changed, the values obtain with the Debug are the same as with the previous BIOS version. They are also the same with or without Above 4G enabled so you don't need to make any changes for that to your config file.

 

You do need to make changes to the config.plist if you update to OC 0.6.1, eg you need to add the Arch - String - Any values to all your Add (kexts) and Patch sections in the Kernel part. There are a few other bit dotted throughout the rest of the config as well.

 

If you want I can upload my updated config.plist file and you can see and compare with yours and see where the changes are.

@Ploddles please do upload your EFI. It’d be if great help!’

Link to comment
Share on other sites

  • fabiosun changed the title to [Discussion] - TRX40 Bare Metal - Vanilla Patches

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • There are no registered users currently online
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.