Jump to content

fabiosun

Recommended Posts

1 hour ago, meina222 said:

MMIO between 1,1 and 7,1

MMIO addresses will change when using 'Above 4G' and into the higher memory space.

I don't see how changing SMBIOS will affect MMIO.

 

As you can see by my earlier post you can see the comparative shift from Above 4G Disabled (red) to Above 4G Enabled (Blue) spreadsheets.

Edited by Driftwood
Link to comment
Share on other sites

35 minutes ago, fabiosun said:

@Jaidy about your kext problem 

have you put them in config in right order?

in Big Sur does not work well latest version

about encoding 39 value I do not understand your question

I read online that Lilu has to be the first kext followed by VirtuaSMC. Afterwards it’s fine. So is there a correct order to enter these two kexts? I tried using ProperTree, but the config.plist generates by it doesn’t allow me to boot at all.

 

When I enable Above 4g encoding, another option appears in the BIOS below it, “encoding limit” which is set to 39 by default. As when I enabled it, I could not boot, so I thought may be there is another value for this limit?

Link to comment
Share on other sites

@Jaidy,

 

My EFI and BIOS files are on page 22.

 

Copy the BIOS file onto a USB drive and plug that in before you turn the machine on. Go to the last tab in BIOS where you save and exit. Select the Load settings option and you can then load the file from the USB drive. This overwrites your current settings so make sure you have saved your settings first. After loading the file save and exit.

 

@fabiosun, do you know if removing the boot argument and enabling above 4G Encoding change the MMIO values we use in the Whitelist? If so, do you want me to disable the Whitelist or go through the process of replacing them with new values?

  • +1 1
Link to comment
Share on other sites

38 minutes ago, Ploddles said:

@Jaidy,

 

My EFI and BIOS files are on page 22.

 

Copy the BIOS file onto a USB drive and plug that in before you turn the machine on. Go to the last tab in BIOS where you save and exit. Select the Load settings option and you can then load the file from the USB drive. This overwrites your current settings so make sure you have saved your settings first. After loading the file save and exit.

 

@fabiosun, do you know if removing the boot argument and enabling above 4G Encoding change the MMIO values we use in the Whitelist? If so, do you want me to disable the Whitelist or go through the process of replacing them with new values?

@Ploddles @fabiosun lemme know if you'd ever need an organ donor 😉 

  • Haha 1
  • whahahah 2
Link to comment
Share on other sites

  • Moderators

TB Update.

I've spent hours working on the TB USB-C issue: so far no luck. So I contacted some people way smarter than me and they've kindly included me in their PM loop as they've been working on the same issue. It seems that TB USB-C is flaky on other systems too. The main difference is that they get USB-C functionality if the device is connected before boot, but not if hot-plugged after boot. While I get no USB-C either way.

 

Bottom line, people are working on it, but it will take some time.

  • Like 2
Link to comment
Share on other sites

  • Moderators
1 hour ago, fabiosun said:

About kext order for amd cpu power gadget

you have to declare two needed kext in correct order

see in App’s github for it

in my bios 4g can be enabled or disabled

so you have to read  your manual and test by yourself 

@Jaidy

 

fabiosun,

 

1) I could not boot with Above 4G enabled unless I also enabled CSM. Even with 4G enabled, if npc=0x2000 is present as boot-arg, it still boots. I'm not certain I see the downside of leaving npc=0x2000 present; are there problems in the log that I'm missing?

 

2) From reading recent posts, I don't quite understand what you're recommending for MmioWhitelist.

    a) Are you saying it should be the same for all TRX40 mobos?

    b) And that you found something different with Pavo from the list I'd originally posted for the MSI Creator?

 

3) Were you able to get AMDRyzenCPUPowerManagement.kext to work in Big Sur?

 

Link to comment
Share on other sites

24 minutes ago, iGPU said:

 

fabiosun,

 

1) I could not boot with Above 4G enabled unless I also enabled CSM. Even with 4G enabled, if npc=0x2000 is present as boot-arg, it still boots. I'm not certain I see the downside of leaving npc=0x2000 present; are there problems in the log that I'm missing?

 

I don't need Above 4G not npci=0x2000 as boot-arg and boots fine, also CSM disabled. You might need Above4G because of duel GPUs though. My MMIOWhite list is the from the ones I got from using OpenCore debug version and only disabled the last 2 entries.

Link to comment
Share on other sites

  • Moderators
3 minutes ago, Pavo said:

I don't need Above 4G not npci=0x2000 as boot-arg and boots fine, also CSM disabled. You might need Above4G because of duel GPUs though. My MMIOWhite list is the from the ones I got from using OpenCore debug version and only disabled the last 2 entries.

 

Thanks for feedback. Originally, I had 4G and CSM disabled, but only tried as fabiosun was discussing. I'm don't know if I see advantage one way or the other.

 

And for disabling LAN wake-up, we don't seem to have this option on the MSI Creator. (I usually keep disabled on Intel Hackintoshes.)

Link to comment
Share on other sites

  • Moderators

There were a few posts above discussing built in audio and the AppleALC kext. I took a different approach to examine the issue, not by listening, but from looking at loaded drivers (in Big Sur).

 

What happens to the audio drivers when AppleALC is disabled: the Audio Control drivers are not loaded. This is shown in the first image below.

 

Also shown is a parallel example of a driver not loading for BT/Wifi. I disabled the BT/Wifi kexts (which were included in the EFI's that I uploaded). (I'm using a swapped macOS compatible card.) If these BT/Wifi kexts are disabled, the BCM4352 drivers are not loaded and there is no BT (top image). If they're enabled, the driver is loaded and BT is working (bottom image).

 

Now the only reason you can even see what's happening in this PCI section is because I've entered many devices into OC/DeviceProperties section (which I did not upload in previous EFIs).  See the Spoiler below for the Audio example. A few of the PCI entries are also supplied by SSDT files.

 

DeviceProperties Example:

Spoiler

DevProp.png.1999832aef2ae1850d6f837c540f1c5e.png

 

 

I realize that many don't like using SSDT and DeviceProperties, but if these are not used, you'll miss out on some interesting information. This information is normally seen in Macs and if not entered into OpenCore, it won't be seen in our Hackintoshes. So what really is more Vanilla?

 

A more significant example applies to Thunderbolt. If there is not a proper SSDT, no drivers are loaded and you'll get no Thunderbolt functionality.

 

 

The first image is SystemInfo/PCI when the AppleALC and BT kexts are disabled:

NoAppleALC.png.b1b39014686ddc9364f3d7d1cfcba3e8.png

 

 

Now, AppleALC and BT kexts are enabled:

WithAppleALC.png.aaf3a5dd5e50876703d530e0d7a55ce9.png

 

 

 

Edited by iGPU
  • Like 2
Link to comment
Share on other sites

  • Supervisor
1 hour ago, iGPU said:

 

fabiosun,

 

1) I could not boot with Above 4G enabled unless I also enabled CSM. Even with 4G enabled, if npc=0x2000 is present as boot-arg, it still boots. I'm not certain I see the downside of leaving npc=0x2000 present; are there problems in the log that I'm missing?

 

2) From reading recent posts, I don't quite understand what you're recommending for MmioWhitelist.

    a) Are you saying it should be the same for all TRX40 mobos?

    b) And that you found something different with Pavo from the list I'd originally posted for the MSI Creator?

 

3) Were you able to get AMDRyzenCPUPowerManagement.kext to work in Big Sur?

 

a) never said that

every mb could be different and I have ‘said’ also at dortania guide maintainer to change trx40 advice in this subject

i am saying and I can confirm also for your motherboard that using the schema I tested about MMIO skip 0/1 you can have a working sleep,shutdown, restart
b) sorry this is not clear for me

the list is in every debug log and it could differ from bios and user the page skipped or not for each MMIO is similar and I act on this in my schema

 

to be clear if a user take a your or a mine working config for us using mmio without modifying mmio value conversion is a....dork 🙂

 

3) for Big Sur you need old kext for that app

find an aluveie message on shanee’s forum for correct version working in BS

About ssdt

i agree on device properties and ssdt if they add functionality to our hack

i do not agree in ssdt use in this alpha stage of functionality of our bare metal hack..

 

  • Thanks 1
Link to comment
Share on other sites

  • Supervisor

Here it is about 3 am so my english could be less accurate

😊

about audio discussing

 

i have asked to test something i know from time is a problem for our trx40 system

now i miss only an asus user to say it is a common problem for all

 

i explain

if you have a jack connected on green output of mb backplate (could be also gold as color and if possible to test with speakes or headphone), starting pc and entering in osx produces a missing realtek2.0 usb audio device and a not working audio

this audio is not related to applealc.kext and it is working usually without it

i have to read all @iGPUmessage above when it is morning and i will connect better my brain 😂 to see his studies in this subject

 

this problem could be solved in this way

no jack connected on it and connected only after Osx login

or to have it connected not on backplate but in derivated case audio outpup ( for this it is mandatory to have internal audio connected to case’s audio cable i have posted a picture of my motherboard connector in this thread

  • Like 1
  • whahahah 1
Link to comment
Share on other sites

Testing out Pavo/iGPU's Big Sur EFI with my MMIO memory maps & Fabiosun's schema and all looking hunky dory.  Excellent work guys.

 

The great news about the latest Beta 5 is that Apple's Firewire drivers have been updated and the RME Fireface800 continues to work great as in Catalina BM.

 

BS BM flys!

Screenshot 2020-08-31 at 02.42.26.png

 

 

Screenshot 2020-08-31 at 02.54.35.png

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

Off-Topic, but if anyone here lives in an area that has painfully internet speeds, and have both the Ethernet port and WiFi working on your Hack, you'll likely benefit from this.

 

Quick backstory - I used to have 1gbps internet speeds, but the new place I'm at unfortunately only offers 50mbps. I searched everywhere, and unfortunately, there were zero other options. (*cough* ATT *cough*)

 

Anyways, this is a hack I use to increase my download speeds. It uses internet bonding, basically combining your two separate network connections into a single one. It works on my normal iMac, and wanted to verify that the WiFi from AX200 was working, I tested it on here as well. YMMV.

 

No Internet Bonding:

image.png.b3af571b8f7141eea41be4436e97f6ab.png

 

With Internet Bonding from same server:

image.png.9c2811f1be608bfcfd99a76cfca88cfa.png

 

Doesn't do much for Uploads unfortunately.

 

Spoiler

 

Quick How-to:


# install npm from brew

brew install npm



# install dispatch-proxy

npm install -g dispatch-proxy



# start dispatch

dispatch start

 

Should look something like this

 

image.png.3a01189ff215049236ec4a36e239ff8f.png

 

Credit belongs to this person on Github.

 

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, iGPU said:

I realize that many don't like using SSDT and DeviceProperties, but if these are not used, you'll miss out on some interesting information. This information is normally seen in Macs and if not entered into OpenCore, it won't be seen in our Hackintoshes. So what really is more Vanilla?

 

Yeah I get you - it certainly seems to help in my Big Sur tests. Thanks for the terrific work you've been doing @iGPU. Appreciate it man.

 

BTW @iGPU you using iMacPro1,1 profile or MacPro7,1 after the last round of tests? Be interesting to hear your thoughts?

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

26 minutes ago, fabiosun said:

@Driftwood your @Pavo big sur config in what differs from @iGPU one prposed also to Pavo some messages above?

 

Yeah Im just catching up after a hectic day of failed attempts and work.

 

@fabiosun Did you take a look to see if Realtek driver is registering the correct address COEF values? ie the device gets re-addressed after using Windows or Mac reboot?

Edited by Driftwood
Link to comment
Share on other sites

  • Moderators
1 hour ago, fabiosun said:

 

3) for Big Sur you need old kext for that app

find an aluveie message on shanee’s forum for correct version working in BS

 

 

 

Thanks!

 

v034 is the latest one that works with Big Sur: here 

 

Use this kext and this app (the latest app v064 won't work with the older kext).

 

452427641_ScreenShot2020-08-30at7_16_53PM.png.3056c270eb50384e1a8f0b5f71c2f102.png

  • Like 1
Link to comment
Share on other sites

  • Moderators
15 minutes ago, Driftwood said:

 

Yeah I get you - it certainly seems to help in my Big Sur tests. Thanks for the terrific work you've been doing @iGPU. Appreciate it man.

 

BTW @iGPU you using iMacPro1,1 profile or MacPro7,1 after the last round of tests? Be interesting to hear your thoughts?

 

I've stuck with iMacPro1,1. When I did a battery of tests in each system, there was no difference with the two Radeon VIIs or the CPU in either. So I kept on iMacPro1,1.  Apple may target some of their software to perform differently on newer machines, but I think for the vast majority of things, it won't matter.

 

It probably means nothing, and I don't know what Apple tracks, but I figure the older SMBIOS will more likely fly under the Apple radar than newer machines that may not be selling in the same volume as the older ones.

  • Ok 1
Link to comment
Share on other sites

@iGPU - something in BIOS must be the preventer for shutdown. It's worthwhile playing with those settings if you consider this issue serious enough to warrant the time spent.

 

Wanted to look at sleep again. Looking at the kernel logs I found this suspicious entry. Any ideas if this could be the issue?

 

2020-08-30 23:01:05.576075-0400 0x74       Default     0x0                  0      0    kernel: PMRD: System sleep prevented by kPMCPUAssertion

 

2020-08-30 23:36:20.248221-0400 0xab99     Default     0x0                  0      0    kernel: PMRD: System sleep prevented by kPMPCIUnsupported

 

Ok so apple open sources the xnu kernel I see references to these in the code although I don't really know how up-to-date this code is. It seems that it doesn't like neither the CPU nor one of my PCI devices sleep capabilities. Makes me wonder how anyone else's is working if CPU itself is an issue. Maybe because GB is still running old AGESA 1.0.0.3B ?

 

Anyways, not the biggest issue but I don't think I can do anything. I am curious to know though if these messages show in your logs @fabiosun and @Driftwood. You can check by sleeping and then e.g. looking at result of terminal command log show --predicate 'processID == 0' | grep prevented

 

Update: after I changed to latest daily build 8/30/2020 version of OC (including making the structural changes suggested by @iGPU in the config.plist) the kPMCPUAssertion error is gone and I only get the kPMPCIUnsupported one. So there is hope - I need to find out which device is the culprit. Could be a USB controller.

 

https://opensource.apple.com/source/xnu/xnu-6153.81.5/iokit/Kernel/IOPMrootDomain.cpp.auto.html

 

                if (getPMAssertionLevel( kIOPMDriverAssertionCPUBit ) ==
		    kIOPMDriverAssertionLevelOn) {
			err = kPMCPUAssertion; // 5. CPU assertion
			break;
		}

		if (pciCantSleepValid) {
			if (pciCantSleepFlag) {
				err = kPMPCIUnsupported; // 6. PCI card does not support PM (cached)
			}
			break;
		} else if (sleepSupportedPEFunction &&
		    CAP_HIGHEST(kIOPMSystemCapabilityGraphics)) {
			IOReturn ret;
			OSBitAndAtomic(~kPCICantSleep, &platformSleepSupport);
			ret = getPlatform()->callPlatformFunction(
				sleepSupportedPEFunction, false,
				NULL, NULL, NULL, NULL);
			pciCantSleepValid = true;
			pciCantSleepFlag  = false;
			if ((platformSleepSupport & kPCICantSleep) ||
			    ((ret != kIOReturnSuccess) && (ret != kIOReturnUnsupported))) {
				err = 6; // 6. PCI card does not support PM
				pciCantSleepFlag = true;
				break;
			}
		}
Edited by meina222
  • Like 1
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.