Jump to content

Duvel300

Members
  • Content count

    19
  • Joined

  • Last visited

About Duvel300

  • Rank
    InsanelyMac Protégé
  1. Duvel300

    DSDT fixes for Gigabyte boards

    Sorry to hear that, I am not sure what could be causing this. GraphicsEnabler is working fine on my board, alho normally I use the DSDT for this. If any else is experiencing similar issues please let me know.
  2. Duvel300

    DSDT fixes for Gigabyte boards

    Hey MC, first of all make sure you use the latest version I just posted, it was overwriting certain offset that it shouldn't. you will need the following file which I forgot to include: acpi.h.zip
  3. Duvel300

    DSDT fixes for Gigabyte boards

    Sure, I was thinking about that as well, then again I wasn't (still am) sure if the fix will not cause any problems. When it proves to work properly I will update this. Hrmm... that's weird. The changes I made have nothing to do with portion of the code that controls the GraphicsEnabler. Were you using the Chameleon RC04 boot loader before or the PC-EFI version? EDIT: Sorry, I had to update the code, a new version can be downloaded from post 916. Let me know how it works out.
  4. Duvel300

    DSDT fixes for Gigabyte boards

    Hi All, after releasing my restart fix I noticed that modifying the "FADT.aml" might not that easy for all us. I came up with a much cleaner solution that will eliminate the FADT.aml file all together. The boot loader will actually patch your own FADT with the information needed for a successful restart. The 'com.apple.Boot.plist' will have to be updated and will need to contain the following key: 'RestartFix=YES' <key>RestartFix</key> <string>YES</string> And copy the included boot loader to your OSX root. It is patched for both ACPI 1.0 and 2.0. I don't have a ACPI 2.0 board so I couldn't test this. Good luck! I hope it works for everyone! RestartFix_v2.1.zip
  5. Duvel300

    DSDT fixes for Gigabyte boards

    It might look that it's using the same address each time, but it's definitely dynamic. The offset depends on several factors like the size of the boot loader (boot loader changes in size so will the offset, well in a 1024k boundary). Also the size of the DSDT and other factors will come in to play. If you are using your original FADT and are adding the reset registers to it make sure to update the length indicator in the header as well. EDIT: What I totally forgot to mention is that this will only work if you have a ACPI 1.0 table. (oops). I will see if I can update the source to include ACPI 2.0 as well.
  6. Duvel300

    DSDT fixes for Gigabyte boards

    I am not completely sure about this, I tried it as well with no result. It seems Apple doesn't use this at all. Also comparing the FADT from different Mac's they all contain the max value for those fields which means it's not in use. I might be wrong tho and it doesn't hurt to give it a try. Hey The King, you are right and I might make a little tutorial around it. I have read some of your work with regards to sound etc, great work! (hint.. ). Master Chief is correct, this is the missing piece of the puzzle. That's the bummer here so to say, you can't compile the dsl file, you can only decompile it to show you the contents of the file. So we will have to resort to editing the binary or aml file directly. You can do this with any decent hex editor. Personally I use Hex Editor Neo Free (Windows....). To take your example of editing the value for your PM2 address, look up the offset for PM2 in your DSL file and you'll see it's at offset 0x48 and 4 bytes in length. Open the AML file with a hexeditor go to offset 0x48 and change the bytes to 0x00, and save the file. Take a look at the 2 included pictures. Oh and good work you got it already ported to PC EFI!
  7. Duvel300

    DSDT fixes for Gigabyte boards

    Hey guys, Back after a long absence.... Anyway I noticed still a lot of people have problems restarting their hack and are using some type of kext file to accomplish this. I solved this a while back by modifying the boot file to load a different FADT file (also known as FACP). Hack's that will not reboot are missing some information in the FADT table that the OS needs to initiate a successful restart. I included both the boot file which is based on the latest Chameleon RC4 and a FADT.aml that should get you started. the aml file should work on all Gigabyte EP45 boards, EP35 users might need to remove the PM2 address. You will need a hex editor for this and use the DSL file as a reference for the offsets. But always compare the address offsets in the included FADT file with your own FADT to be sure. The boot file will take care of the CRC after modifying the file. How to Install: - Copy the boot file to the root of your OSX partition. - Copy the FADT.aml to the same folder where you have your DSDT.aml file. - Reboot The other 2 files included in the package is the source file with the changes I made and the decompilation of the FADT.aml file. Good Luck! RestartFix.zip
  8. Hi Master Chief, First of all thanks for all your hard work, your DSDT work was a real 'eye-opener' for me. But back to speed stepping. Having EIST enabled or disabled in the BIOS and using "DropSSDT=YES" will actually not make any difference. The Intel Speed Step Technology is software driven, Windows got it's own drivers to deal with this and are integrated with Windows other PM features. So stepping is not regulated by hardware. Enabling EIST will merely provide the OS with the layer need to control the 'stepping process'. This layer is usually provided through the SSDT (PM_REF etc). Enabling/Disabling EIST and the C states will just update the CFGD to indicate if EIST is enabled, which C stated are supported how many cpus/cores etc. which the OS can query.
  9. Hi Guys, Just a quick note on my findings with regards to the 'SSDT' (Gigabyte boards). On most Gigabyte boards all SSDT's are dynamicly loaded except one, this one does the actual loading. Which means that you always will see at least one SSDT in your ACPI table (IORegistry Explorer). Of couse assuming you have "DropSSDT=no". The BIOS will only include a offset for the SSDT in the RSDT when the EIST function is enabled in the BIOS. So an easy way to make sure no SSDT is loaded without using the DropSSDT option is to make sure you disable EIST, again I am talking about Gigabyte boards (35 and 45 series, probably other boards like MSI implement a similiar feature). However disabling EIST means that your DSDT have to provide ALL the information nessecary to get speedstep working properly. Some DSDT's I have seen use an external reference to PDC0 - PDC4 which is used by the PNOT method in the DSDT, these variables will not be initialized properly if the original SSDT is not loaded (PDC's are initialized by the _PDC method for each proc.), although not really important for what we are trying to achieve but still nice to have the proper values in there.
  10. No problem, as soon as someone sends it, I will let you know.
  11. Great work, thanks! I really appreciate it!
  12. Hi all, Currently I am working on modifying the Chameleon EFI boot loader to support certain hardware in such away that we will not needed patched drivers anymore. (This will only work best with native supported hardware). In some respect it will do the same as the current injectors but injecting the correct EFI information during the boot stage. This will eliminate a lot of problems as Software Update etc. But I need help, in oder to figure out what needs to be injected I need some information from orginal Mac owners. I am looking for people with a Mac that either have a ALC885/ALC889a or a geForce 8800GT 512mb and send me an extract of their IOReg. People with an Mac and ALC885/ALC889a audio: - Open Terminal - Type "sudo -s", type your password and press enter - Type: "ioreg -l -w0 -p IODeviceTree | grep device-properties > dump.txt" - or: "ioreg -l -w0 -p IODeviceTree | grep PinConfigurations > dump.txt" - Please send me the dump.txt file. People with a Mac and a geForce 8800 GT 512Mb: - Open Terminal - Type "sudo -s", type your password and press enter - Type: "ioreg -l -w0 -p IODeviceTree | grep device-properties > dump.txt" - Please send me the dump.txt file. By only sending the device-properties or configurationpins key 's, no personal information is included. So if you have some time to spare, you will greatly help me out! (for now I just need information for those two devices for testing) Thanks!
  13. Duvel300

    unable to find SMBIOS table

    Your problem is with PC EFI, PC EFI uses a PnP call to get the offset to the DMI table (containing the SMBIOS information) in the BIOS. On older boards this PnP call to get the correct offset is not support. Normally if this is the case it would initiate a search from a particular offset in the BIOS (that I forgot right now..) looking for the DMI marker and get the correct offset that way, this is not supported by PC-EFI right now. In short there is not much that you can do except upgrade to the latest BIOS and hope it supports the PnP call needed. If the BIOS upgrade doesn't work, upgrading to another board might not be a bad idea. Good Luck!
  14. Duvel300

    Discontinued

    iNoob, send me your source code, I will add it in for you. It might take a while before you get it back as I am busy with other things right now.
  15. Duvel300

    Discontinued

    Add the following source code in order to get the "Network Link down" fixed for certain cards. Some chipsets need the ledstatus included in the reset. void com_nvidia_ethernet::saveLEDstats() { UInt32 reg=0; UInt32 value=0; int i=0; reg = 22; value = 3; miiRW(phyAddr,reg,value); IODelay(5); reg = 16; for(i=0;i<3;i++){ led_stats[i]=miiRW(phyAddr,reg+i,MII_READ); } reg = 22; value = 0; miiRW(phyAddr,reg,value); IODelay(5); } void com_nvidia_ethernet::restoreLEDstats() { UInt32 reg=0; UInt32 value=0; int i=0; reg = 22; value = 3; miiRW(phyAddr,reg,value); IODelay(5); reg = 16; for(i=0;i<3;i++){ miiRW(phyAddr,reg+i,led_stats[i]); IODelay(1); } reg = 22; value = 0; miiRW(phyAddr,reg,value); IODelay(5); } bool com_nvidia_ethernet::phyReset(UInt32 bmcr_setup) { UInt32 miiControl; unsigned int tries = 0; saveLEDstats(); miiControl = BMCR_RESET | bmcr_setup; if( miiRW(phyAddr, MII_BMCR, miiControl) ) { return false; } IOSleep(500); while( miiControl & BMCR_RESET ) { IOSleep(10); miiControl = miiRW(phyAddr, MII_BMCR, MII_READ); if (tries++ > 100) return false; } restoreLEDstats(); return true; } Of course update your header file with the two new ledstatus methods and change the PhyReset method to accept a new parameter. You also will have to add the correct parameters to the reset call in the source file: miiControl = miiRW(phyAddr, MII_BMCR, MII_READ); miiControl |= BMCR_ANENABLE; // reset the phy if( !phyReset(miiControl) ){ IOLog("ForceDet: PHY reset failed.\n"); return PHY_ERROR; } Even is this is done you will still experience freezing, see my post a few back. But you will get the 88E1116 PHY and lot of others working. Follow the installation instructions in MikeInNs post (switching of computer for 30 secs etc), in order to get a valid link. And please, no GPL licenses were viololated by MikeInNs, I can tell you a whole lot about licensing after working years for Microsoft.
×