Contribute
Register

[Guide] ASUS ZENBOOK UX305FA for El Capitan

Status
Not open for further replies.
Definitely a bitbucket problem... It was working, now not.

I deleted the file and uploaded again and that seemed to fix the problem with that file.

Excellent, thank you both.


I wondered if you could help me with another problem... Same laptop etc but when I run ssdtPRGen script, all seems fine but upon reboot I get a cpu kernel panic... Should the script run fine with just ~/.ssdtPRGen.sh or does it need extra parameters? It seems to detect everything fine.

The guide didn't go too much over the generating of our own ssdt.aml so wondered if any other changes to config.plist were necessary after generating.


Thanks
 
Excellent, thank you both.


I wondered if you could help me with another problem... Same laptop etc but when I run ssdtPRGen script, all seems fine but upon reboot I get a cpu kernel panic... Should the script run fine with just ~/.ssdtPRGen.sh or does it need extra parameters? It seems to detect everything fine.

The guide didn't go too much over the generating of our own ssdt.aml so wondered if any other changes to config.plist were necessary after generating.


Thanks

Not really possible to give any specific advice without EFI/Clover and the specific panic you're getting...

http://www.tonymacx86.com/el-capita...01-guide-native-power-management-laptops.html
 
I wondered if you could help me with another problem... Same laptop etc but when I run ssdtPRGen script, all seems fine but upon reboot I get a cpu kernel panic... Should the script run fine with just ~/.ssdtPRGen.sh or does it need extra parameters? It seems to detect everything fine.

One thing ssdtPRGen.sh is sensitive about is your current SMBIOS--in particular, your board-id/product-name. I'm interested in which board-ids are broken on this machine.

I've been pushing ssdtPRGen.sh changes at Pike lately. It's possible *I* broke the script. If you could paste a copy of what ssdtPRGen.sh prints, that would be helpful.
 
One thing ssdtPRGen.sh is sensitive about is your current SMBIOS--in particular, your board-id/product-name. I'm interested in which board-ids are broken on this machine.

I've been pushing ssdtPRGen.sh changes at Pike lately. It's possible *I* broke the script. If you could paste a copy of what ssdtPRGen.sh prints, that would be helpful.

Thank you and RehabMan so much. I have an UX305FA (Core M) and UX305LA (i5) that have been both working 'fine' on my ghetto-rigged setup: https://bitbucket.org/spigots/ux305-el-capitan

Just converted both machines over to the Clover DSDT patching method with your SSDTs and things are running great. Running MacBookAir7,2 SMBIOS on the i5.

Oh, random fun fact: If you set Clover's resolution to 1024x768, launch CSM can be disabled without any display artifactics at startups. Just in case you're weird like me and prefer to keep it disabled.
 
Excellent, thank you both.


I wondered if you could help me with another problem... Same laptop etc but when I run ssdtPRGen script, all seems fine but upon reboot I get a cpu kernel panic... Should the script run fine with just ~/.ssdtPRGen.sh or does it need extra parameters? It seems to detect everything fine.

The guide didn't go too much over the generating of our own ssdt.aml so wondered if any other changes to config.plist were necessary after generating.


Thanks

ssdtPRGen on Broadwell has been a pain for me occasionally. Assuming you're using the default MacBook8,1 SMBIOS in this guide try compiling this to SSDT.AML: https://bitbucket.org/spigots/ux305...e7dc6bfa3876520a36b/DSDT/custom/SSDT-pr-m.dsl
 
Thanks for the replies everyone,

Here's the output and the current SMBIOS minus the serials

Code:
[B]➜  [/B][B]~[/B] ~/ssdtPRGen.sh   




[B]ssdtPRGen.sh[/B] v0.9  Copyright (c) 2011-2012 by † RevoGirl
             v6.6  Copyright (c) 2013 by † Jeroen
             v18.2 Copyright (c) 2013-2016 by Pike R. Alpha
-----------------------------------------------------------
[B]Bugs[/B] > https://github.com/Piker-Alpha/ssdtPRGen.sh/issues <


[B]System information[/B]: Mac OS X 10.11.3 (15D21)
[B]Brandstring[/B]: "Intel(R) Core(TM) M-5Y10c CPU @ 0.80GHz"


[B]Version[/B]: models.cfg v160 / Ivy Bridge.cfg v0




Scope (_PR_) {222 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)


[B]Notice[/B]: The LFM frequency in Mac-BE0E8AC46FE800CC.plist is set to 1300MHz!
	This problem can be fixed with help of freqVectorsEdit.sh from:
	https://github.com/Piker-Alpha/freqVectorsEdit.sh


Generating ssdt.dsl for a 'MacBook8,1' with board-id [Mac-BE0E8AC46FE800CC]
Broadwell Core M-5Y10c processor [0x306D4] setup [0x0b06]
With a maximum TDP of 4.5 Watt, as specified by Intel
Number logical CPU's: 4 (Core Frequency: 800 MHz)
Number of Turbo States: 12 (900-2000 MHz)
Number of P-States: 16 (500-2000 MHz)
Adjusting C-States for detected (mobile) processor
Injected C-States for CPU0 (C1,C3,C6,C7)
Injected C-States for CPU1 (C1,C2,C3,C6,C7)
[B]Warning[/B]: 'cpu-type' may be set improperly (0x0b06 instead of 0x0906)


[B]Compiling:[/B] ssdt_pr.dsl
Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20141107-64 [Jan  2 2015]
Copyright (c) 2000 - 2014 Intel Corporation


ASL Input:     /Users/ash/Library/ssdtPRGen/ssdt.dsl - 293 lines, 8673 bytes, 49 keywords
AML Output:    /Users/ash/Library/ssdtPRGen/ssdt.aml - 1622 bytes, 16 named objects, 33 executable opcodes


Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations


Do you want to copy /Users/ash/Library/ssdtPRGen/ssdt.aml to /Extra/ssdt.aml? (y/n)? n
Do you want to open ssdt.dsl (y/n)? n
[B]➜  [/B][B]~[/B]

Screen Shot 2016-02-29 at 19.16.09.png



@spigots - Do I put that SSDT in the input folder? does it need to be renamed?

Cheers
 
Thank you and RehabMan so much. I have an UX305FA (Core M) and UX305LA (i5) that have been both working 'fine' on my ghetto-rigged setup: https://bitbucket.org/spigots/ux305-el-capitan


Very cool. I'll add the UX305LA to the list, along with the fact that MacBookAir7,2 is known to be working with it.

Does AppleHDA layout 28 help? AppleHDA patching is black magic to me.

Oh, random fun fact: If you set Clover's resolution to 1024x768, launch CSM can be disabled without any display artifactics at startups. Just in case you're weird like me and prefer to keep it disabled.

I do prefer to keep it disabled. I'll probably put 1024x768 in my config.plist, and document CSM in the notes section at the end. I'm starting to triage changes by the level of difficulty in documenting them...
 
@spigots - Do I put that SSDT in the input folder? does it need to be renamed?

When you compile that SSDT-pr-m.dsl with iasl, the compiler will spit out a file "ssdt.aml" (the output filename is in the DefinitionBlock.) Put ssdt.aml in EFI/CLOVER/ACPI/patched.

I've been a little wary of MacBook8,1, since everybody says "I've had some problems with that" :) Still going to test it tonight. There's some frequency vector hackery I should be doing too, since anerik70 went to the trouble of working it out with Pike.

Anyway, your larger point is taken: I should document what I did with ssdtPRGen.sh.
 
When you compile that SSDT-pr-m.dsl with iasl, the compiler will spit out a file "ssdt.aml" (the output filename is in the DefinitionBlock.) Put ssdt.aml in EFI/CLOVER/ACPI/patched.

I've been a little wary of MacBook8,1, since everybody says "I've had some problems with that" :) Still going to test it tonight. There's some frequency vector hackery I should be doing too, since anerik70 went to the trouble of working it out with Pike.

Anyway, your larger point is taken: I should document what I did with ssdtPRGen.sh.

Thanks for the info!

I've used MacBook8,1 and ig-platform-id 0x161E0000 with both this guide and the yosemite one.. always worked fine for me - 0x161E0001 also works fine (except hdmi) and gives 1.5Gb Graphics memory too. vs 1Gb with 0x161E0000. Also loads to login screen right away without a delay of black.

I'll try the .dsl file you gave me after work tomorrow and feed back. Thanks again!
 
Does AppleHDA layout 28 help? AppleHDA patching is black magic to me.

The layout-id is an arbitrary choice by the person who created the patched AppleHDA.

There is info in the FAQ regarding patched AppleHDA (and info in the ACPI patching guide that provides details on determining layout-id from a given AppleHDA).
 
Status
Not open for further replies.
Back
Top