Jump to content
InsanelyMac Forum

Signal64

Members
  • Content count

    142
  • Joined

  • Last visited

  1. @bcc9, nice job. A couple of questions for you: 1. How do you determine the index of the table used based on mac model? 2. To confirm, it's only by trial and error to map out the port connector to row in the table?
  2. The 0 lengths I'm seeing are typically showing up in a ResourceTemplate which is valid if it is populated before being used. It's a scenario I've been finding more in AMI BIOS boards than Award so far. Example: Scope (PCI0) { Name (CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, // Granularity 0x0000, // Range Minimum 0x00FF, // Range Maximum 0x0000, // Translation Offset 0x0100, // Length ,, ) IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08, ) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, // Granularity 0x0000, // Range Minimum 0x0CF7, // Range Maximum 0x0000, // Translation Offset 0x0CF8, // Length ,, , TypeStatic) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, // Granularity 0x0D00, // Range Minimum 0xFFFF, // Range Maximum 0x0000, // Translation Offset 0xF300, // Length ,, , TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000A0000, // Range Minimum 0x000BFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // ------------------------------- _Y1E Length ,, , AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x000C0000, // Range Minimum 0x000DFFFF, // Range Maximum 0x00000000, // Translation Offset 0x00020000, // Length ,, _Y1E, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0x00000000, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // ------------------------------- _Y1F Length ,, _Y1F, AddressRangeMemory, TypeStatic) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, // Granularity 0x00000000, // Range Minimum 0x00000000, // Range Maximum 0x00000000, // Translation Offset 0x00000000, // ------------------------------- _Y20 Length ,, _Y20, AddressRangeMemory, TypeStatic) }) CreateDWordField (CRS, \_SB.PCI0._Y1E._MIN, MIN5) CreateDWordField (CRS, \_SB.PCI0._Y1E._MAX, MAX5) CreateDWordField (CRS, \_SB.PCI0._Y1E._LEN, LEN5) CreateDWordField (CRS, \_SB.PCI0._Y1F._MIN, MIN6) CreateDWordField (CRS, \_SB.PCI0._Y1F._MAX, MAX6) CreateDWordField (CRS, \_SB.PCI0._Y1F._LEN, LEN6) CreateDWordField (CRS, \_SB.PCI0._Y20._MIN, MIN7) CreateDWordField (CRS, \_SB.PCI0._Y20._MAX, MAX7) CreateDWordField (CRS, \_SB.PCI0._Y20._LEN, LEN7) Method (_CRS, 0, NotSerialized) { // If Local0 then we store a value in _Y1E Length, else we just use // what is already in the resource template Store (MG1L, Local0) If (Local0) { Store (MG1B, MIN5) Store (MG1L, LEN5) // <------------------------------- _Y1E Len Add (MIN5, Decrement (Local0), MAX5) } // We outright store values for _Y1F and _Y20 Store (MG2B, MIN6) Store (MG2L, LEN6) // <------------------------------- _Y1F Len Store (MG2L, Local0) Add (MIN6, Decrement (Local0), MAX6) Store (MG3B, MIN7) Store (MG3L, LEN7) // <------------------------------- _Y20 Len Store (MG3L, Local0) Add (MIN7, Decrement (Local0), MAX7) Return (CRS) } } Setting the 0x00000000 length to 0x00000001 for _Y1F and _Y20 is harmless in this case since it is always overwritten later. Probably more of an explanation than it deserves but there you are.
  3. Alright, bad example then. On the Gigabyte EP45-UD3P with an E6850 we have C2=0x5A and C3=0x384 which would indicate it being supported. Getting the same values on the EP45-DS4P with Q9550. Point being on these boards where you don't get CST tables (like all three of the gigabytes in my sig) it doesn't appear your just stuck with C1 (if C2 < 100 [0x64] and C3 < 1000 [0x3E8] )
  4. Defining it in that case would be to just get rid of the LPC CST error on boot unless there is a better way. In regards to the 8.4.2.1 _CST description if you look in FACP and you see latency values for C2 C3 don't you have support for C1-C3 anyway? Just being done through P_BLK P_LVLx values and P_LVLx_LAT from FADT instead of the "optional" _CST method. [05Fh 0095 1] _CST Support : 00 [060h 0096 2] C2 Latency : 0065 [062h 0098 2] C3 Latency : 03E9 If that's true then your not just limted to C1 and should be able to safely define _CST for C2 and C3 right?
  5. Signal64

    Auto Sleep on GA-EP45-UD3 MOBOs

    BTW - hard disks are not automatically going to sleep when that option is enabled. If that was the reason behind DVD drives holding up autosleep then it would be a place to start.
  6. Signal64

    Auto Sleep on GA-EP45-UD3 MOBOs

    Lately I've been working on an EP45-UD3P and EP45-DS4P and see the same issue with autosleep and snow. POSSIBLE CAUSES 1. DVD optical drive: Well, the simplest way to tell is to unplug it and try without. I have Pioneer and Sony Optiarc's that work fine in Leo with autosleep but still see the same issue with or without them on the Gigabyte. BTW, these work on my asus mcp79 boards with snow and autosleep. On those boards the "old" issue with some dvd drives and autosleep still exists. 2. Bad DSDT patch: Wouldn't say it's a bad patch but rather something we are missing. 3. Overclock settings: Run at default, non-OC'd settings and you see the same issue. 4. USB/PCI device/adapter or other hardware: May not be a particular piece of hardware but rather how something is not setup right - back to item 2. 5. Some piece of software: I'm running "virgin" installs and see the issue, however even according to Apple the proverbial "it depends" comes into play even with a default install. Best practice for testing is to boot, not run anything, and wait for the timeout. Keep in mind it may not happen right on the dot at the timeout minute specified (I'd wait for up to 5min afterwards to make sure). http://support.apple.com/kb/HT1776 6. A combination of some or all of thee above: It's a quirk for sure and it'll be a pita to compare ami vs award dsdt to find something that helps but can give it a shot. What makes this a bit harder to determine is most folks put this on the bottom of the list in terms of importance.
  7. Hi munky, I noticed your using -iso -hfs to build the iso. Is there any advantage to that? If you change it to -iso -joliet it will stop the "Press any key to boot cd or press F8 for options" message cycle and instead just bring you to boot: as some of the earliest boot132 iso's do. I find it a bit cleaner to work with.
  8. Signal64

    [HOW TO] Patch AppleHDA - Knowledge Base

    Just keep in mind that there are at least 5 versions of HDAEnabler.kext that I have found floating around. MD5 File Size ------------------------------------------------------------------------------------------ 2c9fb3832f40d952223b066b0aa60d9d ./0d9d/HDAEnabler.kext/Contents/MacOS/HDAEnabler 26168 034465caca7733ccdd3e492013df57e7 ./57e7/HDAEnabler.kext/Contents/MacOS/HDAEnabler 29256 848cb12dd136614f360d89b91e61ca99 ./ca99/HDAEnabler.kext/Contents/MacOS/HDAEnabler 26328 9921ab5db77c3c9a1c9a3ed5fa21e8bd ./e8bd/HDAEnabler.kext/Contents/MacOS/HDAEnabler 25732 a19878d2a73865a39eb50fe35447ec58 ./ec58/HDAEnabler.kext/Contents/MacOS/HDAEnabler 28504 They can have different Info.plist files as well and the majority report version 1.0.0d1. The one THe KiNG has linked appears to be the most recent (0d9d above at version 1.0.1) and will work with 10.5.7 without modification.
  9. Signal64

    Asus P5N7A-VM

    In regards to modifying apple usb for ehci handoff, it's already been done. Original Thread: http://www.insanelymac.com/forum/index.php?showtopic=28559 Updated with 10.5.6 flavors: http://www.insanelymac.com/forum/index.php?showtopic=117029 Go down to the "DISCUSSION THREAD STARTS BELOW:" part of the original topic to see the basic mod done for handoff. I personally don't mess with these at all and just turn off legacy usb. I prefer to keep things as vanilla as possible and that works. As suggested at one point you can also enable "High Speed" instead of "Full Speed" which in essence disables EHCI (USB 2.0) speeds as well (not my fav solution either). What I would rather see is a kext that can load up, handle the handoff, then load appleusb (or just exits and let the apple usb load on it's own). DFE does something similar with his NullCPUPowerManagement where it can take priority over the power managment kext or let it load based on a boot flag. That would be more useful for other boards as well.
  10. Signal64

    Asus P5N7A-VM

    I use Nexus LOW7000's to take care of the nb cooling on all of the 730i boards I have. No additional fan needed, large enough for decent air flow at a slow speed. But in the end if you run your board horizontal you just need a breeze on the nb. http://signal64.osx86.me/p5n7avm/100_4223-1.jpg http://signal64.osx86.me/p5n7avm/100_4217-1.jpg http://www.nexustek.nl/NXS-LOW-7000_silent...-CPU-Cooler.htm I think Thermalright or Thermaltake make one like it. BTW - the thermal grease on the nb is actually "grease" and not a thermal pad or hard grey {censored} like you find on other boards. There isn't any gain in replacing it.
  11. Signal64

    Macbook 13" Right click mod

    I just make the bottom right corner of the touchpad right click via touchpad preferences. Guess I'm missing the point of the mod.
  12. Signal64

    Gigabyte's Nvidia 9400 powered M-ATX MOBO

    Yea, It's acpi.. that's what i said. Since I don't get kernel panics it was something to test anyway. Where in DSDT.. If your refering to the WMI info, no that's not it. What heading are you looking under?
  13. Signal64

    Gigabyte's Nvidia 9400 powered M-ATX MOBO

    The test was with a very simple ACPI table called MCFG.CFG which is a "Memory Mapped Configuration table". The Gigabyte one looks like: /* * Intel ACPI Component Architecture * AML Disassembler version 20061109 * * Disassembly of MCFG.dat, Thu Nov 27 19:59:58 2008 * * ACPI Data Table [MCFG] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 000 4] Signature : "MCFG" /* Memory Mapped Configuration table */ [004h 004 4] Table Length : 0000003C [008h 008 1] Revision : 01 [009h 009 1] Checksum : 14 [00Ah 010 6] Oem ID : "GBT " [010h 016 8] Oem Table ID : "GBTUACPI" [018h 024 4] Oem Revision : 42302E31 [01Ch 028 4] Asl Compiler ID : "GBTU" [020h 032 4] Asl Compiler Revision : 01010101 [024h 036 8] Reserved : 0000000000000000 [02Ch 044 8] Base Address : 00000000E0000000 [034h 052 2] Segment Group Number : 0000 [036h 054 1] Start Bus Number : 00 [037h 055 1] End Bus Number : 1F [038h 056 4] Reserved : 00000000 Raw Table Data 0000: 4D 43 46 47 3C 00 00 00 01 14 47 42 54 20 20 20 MCFG<.....GBT 0010: 47 42 54 55 41 43 50 49 31 2E 30 42 47 42 54 55 GBTUACPI1.0BGBTU 0020: 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 E0 ................ 0030: 00 00 00 00 00 00 00 1F 00 00 00 00 ............ That table on all of the other 730i boards I have in my sig looks like /* * Intel ACPI Component Architecture * AML Disassembler version 20080926 * * Disassembly of acpitbls/MCFG.aml, Wed Jan 28 18:25:06 2009 * * ACPI Data Table [MCFG] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 000 4] Signature : "MCFG" /* Memory Mapped Configuration table */ [004h 004 4] Table Length : 0000003C [008h 008 1] Revision : 01 [009h 009 1] Checksum : 38 [00Ah 010 6] Oem ID : "010809" [010h 016 8] Oem Table ID : "OEMMCFG " [018h 024 4] Oem Revision : 20090108 [01Ch 028 4] Asl Compiler ID : "MSFT" [020h 032 4] Asl Compiler Revision : 00000097 [024h 036 8] Reserved : 0000000000000000 [02Ch 044 8] Base Address : 00000000FC000000 [034h 052 2] Segment Group Number : 0000 [036h 054 1] Start Bus Number : 00 [037h 055 1] End Bus Number : 1F [038h 056 4] Reserved : 00000000 Invalid zero length subtable Raw Table Data 0000: 4D 43 46 47 3C 00 00 00 01 38 30 31 30 38 30 39 MCFG<....8010809 0010: 4F 45 4D 4D 43 46 47 20 08 01 09 20 4D 53 46 54 OEMMCFG ... MSFT 0020: 97 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC ................ 0030: 00 00 00 00 00 00 00 1F 00 00 00 00 ............ See the difference in address? Anyway I tried a bios with the Gigabyte's addressed changed to FC and I didn't see the video memory range move up in memory like I thought it would. In the end it looks like it just relocated ACPI. Didn't do any further tests as it looked like we were back to needing a vgabios update. So here's the deal with that - the DFI is the only other 9400 board on the market as far as I can tell. I couldn't directly use that vga bios on the Gigabyte as their video out ports are different and has a different nvcap. You basically end up with non-working video on boot because of it. Arti's tool for decoding nvcap (nvcapmaker) for our hackintosh use knows where to locate this information in a nvidia vgabios but damn if I can. It's encoded (as in not the same hex you see generated by nvcap maker) and could possibly be in several locations. I've tried contacting Arti through email to ask him about this but he hasn't responded and doubt he will. Only way to easily compare is to get vgabios's that are identical releases for the same gpu with different ports on each card (i.e. let's say a 7300GT with dual dvi vs. a 7300GT with vga+dvi). That's been a needle in a haystack. Reverse engineering Arti's program (nvcap located in NVCapMaker's resources directory) isn't something easy for me to do either. If anybody finds that info out, let me know. My only other choice is to take one of the 9300 vgabios's and make it think it's a 9400 for a test. Those vgabios's share the same nvcap. Anyway, here's the bios for the Gigabyte with the one byte MCFG.CFG change and nothing else touched. It's based on F3a. I doubt it helps at all but you can give it a shot if you like. f3amod1.zip
  14. Signal64

    [HOW TO] Patch AppleHDA - Knowledge Base

    Is there an agreement on what to do with 71d Misc values that are >1 ? I've come across a couple of codec dumps that have alternate values such as 6, 8, and c in that field. I can guess what to do but I'm trying to help automate the verb conversion process with a script. Sample: -------------------------------------------------------------------------------------------------------- Verbs from Linux Codec Dump -------------------------------------------------------------------------------------------------------- Codec: Realtek ALC1200 Address: 0 Vendor Id: 0x10ec0888 Subsystem Id: 0x104382fe Revision Id: 0x100101 Jack Color Description Node PinDefault Verbs -------------------------------------------------------------------------------------------------------- ATAPI Unknown SPDIF Out at Int ATAPI 17 0x11 0x99430140 01171c40 01171d01 01171e43 01171f99 1/8 Green Line Out at Ext Rear 20 0x14 0x01014010 01471c10 01471d40 01471e01 01471f01 1/8 Black Line Out at Ext Rear 21 0x15 0x01011012 01571c10 01571d10 01571e01 01571f01 1/8 Orange Line Out at Ext Rear 22 0x16 0x01016011 01671c10 01671d60 01671e01 01671f01 1/8 Grey Line Out at Ext Rear 23 0x17 0x01012014 01771c10 01771d20 01771e01 01771f01 1/8 Pink Mic at Ext Rear 24 0x18 0x01a19850 01871c50 01871d98 01871ea1 01871f01 1/8 Pink Mic at Ext Front 25 0x19 0x02a19c60 01971c60 01971d9c 01971ea1 01971f02 1/8 Blue Line In at Ext Rear 26 0x1a 0x0181305f 01a71c50 01a71d30 01a71e81 01a71f01 1/8 Green HP Out at Ext Front 27 0x1b 0x02214c20 01b71c20 01b71d4c 01b71e21 01b71f02 ATAPI Unknown CD at Int ATAPI 28 0x1c 0x593301f0 01c71cf0 01c71d01 01c71e33 01c71f59 Optical White Speaker at Ext N/A 29 0x1d 0x4015e601 01d71c00 01d71de6 01d71e15 01d71f40 Optical Orange SPDIF Out at Ext Rear 30 0x1e 0x01456130 01e71c30 01e71d61 01e71e45 01e71f01 1/8 Black Speaker at Ext Rear 31 0x1f 0x411111f0 01f71cf0 01f71d11 01f71e11 01f71f41 -------------------------------------------------------------------------------------------------------- I'm forcing Sequence to 0 and have the idea on what to do for port/location. Just wanted to find out about these "high" values for Misc as they do cause assertion errors.
  15. Signal64

    Forum optimisations

    I'd like to backup onemanstrash's statement here. While on IRC we saw this being experienced by multiple people around the globe and not just a local isp issue. While things have calmed down right now it's still slower than [insert your favorite slow metaphor here].
×