Jump to content

Big problem with X3100 & Mac OS


makondo
 Share

14 posts in this topic

Recommended Posts

Hi guys.

I need to install Mac OS (10.6 or later) on my laptop (Dell Inspiron 1525; Intel X3100; Core 2 Duo; 2GB RAM).

Well, i tried to install Kalaway,iDened,iAtkos or whatever.

I managed to install them but everywhere the same result. I mean that when my laptop is loading you can seen this {censored} (see attached photos).

I have installed only those versions, where there were the drivers for Intel X3100.
Any ideas?
P.S. Options like "-x -v" don't help.
P.S.S. I'm able to install Mac OS only from USB because DVD Rom is broken,unfortunately.
 

post-1364747-0-47674400-1403342560_thumb.jpg

post-1364747-0-02510500-1403342563_thumb.jpg

post-1364747-0-41301900-1403342574_thumb.png

Link to comment
Share on other sites

  • 6 months later...

Make sure you're booting with GraphicsEnabler=No and kernel flag arch=i386.

 

EDIT

Preliminary findings indicate that what you're seeing is the X3100 being in "broken mirror" mode

Try connecting an external display + USB mouse and keyboard and close the lid. With a little luck this should make the external display primary, allowing you to work from there.

/EDIT

 

I get similar behavior when hotplugging an external display on the VGA port and clicking 'detect displays'. On both displays (stuck in mirrored mode). If I boot with the external display already connected it works, but I have no rotation support on the external display which is a bummer since it's rotated.

 

I'm currently working on fixing those issues (display corruption and rotation) and get brightness control working as well.

 

*Brain dump* current status/issues

 

dmesg says "IG: Invalid firmware max backlight setting"

 

I compiled a 32-bit version of Rehabman's ACPIBacklight driver and got brightness slider + hotkeys (still need remapping) responding, the sun decal appears but brightness doesn't change. I found the backlight code in the first SSDT table but I guess it needs something done to it for ACPIBacklight.kext to work with it. If I don't load the backlight SSDT table the brightness level changes but it's busted (full brightness -> wobbly-dark -> pitch black).

 

I saw a DSDT patch for an HP laptop that had the Backlight methods moved into the PNLF device but I can't figure out how to do that with the code I have. But I don't think that's relevant...? The SSDT table with backlight code seems to be picked up just fine, it's just that the values are wrong, or interpreted wrong.. I think.

 

Oh yeah this is a Thinkpad T61 7658 CTO.

 

X3100 kexts etc are unmodified and there's no X3100/display related injection anywhere besides PNLF device + renaming VID to GFX0. It's running 10.7.5

 

Every time i try to tamper with GFX0 and reboot I just get a black screen! At least it doesn't freeze, I can use the power button to reboot blind.

 

I see a permanent, rogue "display@2,1" outside of the GFX0 device in IOREG that I don't know how to get rid of. The internal LCD and external display, when connected, show up inside GFX0 device as you'd expect. dmesg has a line that says "Display not usable".

 

The T61 DSDT has duplicated code for the main 0x00020000 VID device (which is now GFX0 - I left the duplicate named VID) as well as LCD, CRT and DVI inside another device called AGP. It looks like this code is supposed to "take over" when the T61 is docked...?

The backlight SSDT table also refers to the duplicate devices inside "AGP". Next trial will be stripping or commenting out all of that and see what happens because I suspect that these duplicate displays are causing at least some of the issues I'm seeing.

 

I'd like to get it to work with the "duplicates" intact though because the T61 mini dock currently goes for a whopping 20 dollars on Amazon and I'd like to get one just to play around with it

 

The FakeSMC GPU sensors plugin does not attach to the X3100.

HWMonitor.app window graphics are corrupted, but only the blue part!

HWMonitor.app shows CPU to be running at 796MHz + multiplier x4.0 but that can't be true.

 

Another strange issue is that FileNVRAM.dylib (tried current 1.14 and 1.13) will sometimes generate a new nvram.plist after reboot - but with a different name - but it's not because the T61's UUID is changing, the UUID stays the same! I don't know what's wrong, but the nvram.plist does not have a .plist file extension..it has no extension...it's like the filename is too long or something, current one is named nvram.f0c3e200-f053-ff00-f053DriversPackage-1fe40 with no extension - yes it has "DriversPackage" in the name. Weird right, I've never seen that before.

 

... whatever... more to come.. including files, how I got Rehabman's latest ACPIBattery driver working, Chameleon cpu.c patch to correct FSB calculation, additional keys addded to FakeSMC and so on etc etc. If anyone else is interested in this old piece of sh** lol

 

/end brain dump

Link to comment
Share on other sites

Fixed display corruption by creating display profiles for both displays using EDID extracted from IOREG in safe mode.

 

Rotation on external display also works now.

 

The T61 normally goes to sleep when I close the lid. With the external display connected it stays awake when I close the lid and the external display automatically becomes the main display! Very cool, but of course useless without external keyboard + mouse.

 

CPU state switching works pretty well with MacBook5,1 model identifier and DropSSDT=y + Chameleon generated states.

I can't get any state switching to happen when I use a MacBook model identifier for a MacBook that actually has a X3100!

 

The downside to using MB5,1 is that AGPM now loads and complains about the GPU (the MB5,1 has Nvidia graphics, not X3100). I get some freezes on animations in the Finder and the flurry screensaver stops animating after a while. These are different glitches than before, pretty sure this is AGPM. Need to decide whether to edit or delete.

 

HWMonitor CPU readout is strange, it shows 6x multiplier for 546Mhz. Either the multiplier should be 3 or the CPU freq should be 1092. Some mult/freq combos are correct, others are not.

 

Undid Chameleon cpu.c patch, it caused sound issues. I can live with the bus freq. being 182Mhz (supposedly due to IDA) this makes max CPU speed 2093Mhz.

 

USB is completely dead after waking from sleep. Probably easy to fix in DSDT.

 

To Do:

 

Get fakesmc gpusensors to attach

Figure out what's wrong with FileNVRAM.dylib (it saves several plists a day with no extension and "DriversPackage" in the name and I lose settings across reboots...no 32-bit support?)

I still see a phantom "display" device outside of the X3100 in ioreg. After I switching to MB5,1 it even has AGPM attached to it, while the entry for my external display does not!

Figure out how to get ACPIBacklight.kext to work with the backlight code in the first SSDT table.

Link to comment
Share on other sites

I always change the smc rev keys accordingly when changing model identifiers. Now that you mention it I forgot to change smc-santarosa to smc-mcp. So I did, but it made no difference.

 

Glitches/freezes are gone after removing AppleGraphicsPowerManagement.kext but I'd rather use MacBook4,1 (exact same Santa Rosa platform, T8100 CPU, X3100 GPU) ..there must be a way.. :wallbash:

 

I discovered today that good old natit.kext works for property injection. :D everything I inject goes into main VID@2 device, but also into the phantom display@2,1 device lol

 

I'm starting to think that this phantom display is the main issue here, no idea how to eliminate it. It's weird how the X3100 shows as two separate devices in LSPCI. Both on the T61 and LSPCI from other machines, including the MacBooks that use it. Except in the MacBook IOREG there is no display@2,1 outside the GFX0 device of course.. meh

 

While I could inject everything from the MacBook3,1 DSDT when using the MacBook5,1 identifier, display corruption (identical to photos in 1st post) returned after switching model identifier back to MacBook3,1 or 4,1. I'm currently trying to figure out exactly what injected data causes the display corruption to happen.

 

Back to MB4,1 and removed the display overrides. Display corruption gone, re-adding data to Natit.kext plist line by line, rebooting each time. boooooooooring

Link to comment
Share on other sites

I have Dell Inspiron 1525 with Intel X3100 graphics. Screen is 1440x900. It works perfect!

I adopted Clover to inject all needed values for this graphics.

Also, I found that the graphics depends on SMC keys.

The driver AppleIntelGMAX3100FB asks for keys RPlt and EPCI.

My HWSensors adopted for this card to generate appropriate keys.

All in one. Clover+FakeSMC_3.4+HWInfo+X3100 = works!

Link to comment
Share on other sites

I have Clover on a flash drive, still trying to learn how to use it. Right now I'm using it for emergencies only (read: when I f**k up). I have some doubts and ran into some issues that I can't find an answer to in the FAQ. The whole auto-configuring thing is of course convenient but I'm not happy that I have close to no idea what is actually being auto-configured.

I had Clover installed to the hard drive (root of the OS partition, not EFI) but it seemed like Clover was unable to write to its own folder, no changes that I made in the boot GUI would stick. Maybe because I was missing the HFS+ driver? Also Clover Configurator, which is very helpful when you're a Clover noob, does not run on 10.7.5.

 

What model identifier are you using on the 1525?

 

The MacBook4,1 is literally identical to my T61, same CPU, chipset and the X3100 but ACPI_SMC_PlatformPlugin blocks speedstepping. I don't like to do it this way but it seems to work once I delete MacBook4_1.plist from inside. Using Chameleon generated SSDTs, dropping original T61 CPU power management SSDTs.

Trouble is it looks like this leaves the X3100 in a lower power state because some animations are still choppy, for example the desktop as it zooms in after startup.

 

Latest Chameleon 2.3 svn + FileNVRAM module fixes my nvram.plist issue. Also I suspect copying it to /Extra/Modules using cp -R this time may have something to do with it :D

 

I found a MacBook4,1 IOREG dump - as it turns out, the MacBook4,1 also has a "phantom display" outside of the GX0 device..! One step forward, two steps back..

 

To Do:

Fine tune CPU/GPU power management

Fix USB completely dying after sleep (probably by injecting the usual AAPL stuff through DSDT)

Fix the erratic LCD brightness levels using the backlight code from the first SSDT table and ACPIBacklight.kext

Replace the 7 years old battery lol

Link to comment
Share on other sites

I am not using this computer a year and not updating version.

I replaced/installed many kexts. Clover is old revision. But Clover worked here since rev206. Because Clover is developed for this computer firstly.

ACPI_SMC_PlatformPlugin.MacBook4_1.plist edited.

SSDT for speedstep generated by Clover.

All default values are adopted for this computer.

I am still using 10.6.8 but I think 10.7.5 is also possible, just in 32 bit mode.

Details in my report

DarwinDumper_2.7.0_Clover_X64_1539_SL_slice.zip

Link to comment
Share on other sites

Thank you, I'll dive into that as soon as I am done celebrating here :D

 

Lion only talks to 8-bit (and lower) EC registers. This is why a ton of DSDT patching has to be done in order to use Rehabman's ACPIbattery.kext. Luckily his repository has a patch for the Thinkpad X220 that only needs a tiny change (see my next post) to work on the T61 as well.

 

I found out how to use one of the calculation methods used by the X220 battery patch to fix ACPIMonitor.kext fan RPM reading on the T61. The HFN1 (fan RPM) EC register must be split into two separate 8-bit registers.

 

Based on code from here: http://forum.thinkpads.com/viewtopic.php?p=607990

 

Old:

Field (ECOR, ByteAcc, NoLock, Preserve)
{
    Offset (0x84),
    HFN1,   16
}

New:

                    Field (ECOR, ByteAcc, NoLock, Preserve)
                    {
                                Offset (0x84),
                        HFNL,   8,
                        HFNH,   8
                    }

Old:

                  Method (FAN0, 0, NotSerialized) // ACPIMonitor FAN 0 Speed
                  {
                      Store (\_SB.PCI0.LPC.EC.HFN1, Local0) // Store FAN 0 Control to Local0
                      Return (Local0)
                  }

New:

                    Method (FAN0, 0, NotSerialized)
                    {
                        Store (B1B2 (^^EC.HFNL, ^^EC.HFNH), Local0)
                    }

B1B2 calculation method from Rehabman's battery patches that adds up the two 8-bit values (added by the battery patch at DSDT root level)

    Method (B1B2, 2, NotSerialized)
    {
        Return (Or (Arg0, ShiftLeft (Arg1, 0x08)))
    }

This is my favorite T61 discovery so far. :D Thanks to bcc9, Rehabman, THe KiNG, Sebinouse and Silencer for lighting the way.

 

/EDIT

 

Rehabman's X220 Battery patch will actually fix this too if you already have the fan control patch in your DSDT before applying the battery patch. lol I can see what this looks like, I'm not trying to take credit for this at all, I had applied the battery patch before discovering the fan control patch. Turns out I'm inventing things that were already discovered and documented by others long ago.

Link to comment
Share on other sites

While I'm at it..here's a real contribution lol. A very small one.

 

The X220 ACPIBattery patch splits the 16-bit HWAK into WAK0 and WAK1 but the patch is not fully applied due to HWAK being in _L18 instead of _L1D on the T61.

 

I verified everything else the best I could. The offset on the two 128-bit registers match, there are no _IRC or _PLD to replace and all the EC registers that get split by the patch are present in the T61 DSDT, except for SBBM.

 

The T61 fan speed register (HFSP) is already 8-bits.

 

16-bit registers that aren't patched: SBAE, SBRS, SBBS - SBMD, SBCC - SBOM, SBSI, SBDT.

 

I went through a T60 DSDT (one of the laptops listed as compatible with the x220 battery patch) and it has the same registers + no SBBM as the T61.

 

So I guess this means the below is all that's needed for the T61 to be added to the list.

 

From unmodified T61 DSDT:

    Scope (\_GPE)
    {
        Method (_L18, 0, NotSerialized)
        {
            Store (\_SB.PCI0.LPC.EC.HWAK, Local0)
(...)

After applying the X220 battery patch this section needs to be:

    Scope (_GPE)
    {
        Method (_L18, 0, NotSerialized)
        {
            Store (B1B2 (\_SB.PCI0.LPC.EC.WAK0, \_SB.PCI0.LPC.EC.WAK1), Local0)
Link to comment
Share on other sites

  • 2 weeks later...

I applied ThirdSmile's X3100 Framebuffer brightness patch to the vanilla 10.7.5 X3100 framebuffer driver.

 

I'd known about this patch for a while but I had only seen older pre-patched binaries for download and I was determined not to use drivers or anything else from Snow Leopard.

I didn't know until today that there was a patch available for Lion. It was very easy to apply the patch with 0xED.

 

Both slider and hotkeys work. Brightness drops a level when unplugging AC and goes back up when plugging in. I'd like to see if I can get a wider range but for now I'm perfectly happy with what I've got.

 

This is with PNLF and LCD1234 added to DSDT, there's no 3rd party brightness driver installed.

Link to comment
Share on other sites

While I'm at it..here's a real contribution lol. A very small one.

 

The X220 ACPIBattery patch splits the 16-bit HWAK into WAK0 and WAK1 but the patch is not fully applied due to HWAK being in _L18 instead of _L1D on the T61.

 

I verified everything else the best I could. The offset on the two 128-bit registers match, there are no _IRC or _PLD to replace and all the EC registers that get split by the patch are present in the T61 DSDT, except for SBBM.

 

The T61 fan speed register (HFSP) is already 8-bits.

 

16-bit registers that aren't patched: SBAE, SBRS, SBBS - SBMD, SBCC - SBOM, SBSI, SBDT.

 

I went through a T60 DSDT (one of the laptops listed as compatible with the x220 battery patch) and it has the same registers + no SBBM as the T61.

 

So I guess this means the below is all that's needed for the T61 to be added to the list.

 

From unmodified T61 DSDT:

    Scope (\_GPE)
    {
        Method (_L18, 0, NotSerialized)
        {
            Store (\_SB.PCI0.LPC.EC.HWAK, Local0)
(...)
After applying the X220 battery patch this section needs to be:

    Scope (_GPE)
    {
        Method (_L18, 0, NotSerialized)
        {
            Store (B1B2 (\_SB.PCI0.LPC.EC.WAK0, \_SB.PCI0.LPC.EC.WAK1), Local0)

 

A quick look... this would be the additional patch:

# for T61
into method label _L18 parent_label _GPE code_regex \(\\_SB\.PCI0\.LPC\.EC\.HWAK, replaceall_matched begin (B1B2(\\_SB.PCI0.LPC.EC.WAK0,\\_SB.PCI0.LPC.EC.WAK1), end;
into method label _L18 parent_label \_GPE code_regex \(\\_SB\.PCI0\.LPC\.EC\.HWAK, replaceall_matched begin (B1B2(\\_SB.PCI0.LPC.EC.WAK0,\\_SB.PCI0.LPC.EC.WAK1), end;
  • Like 1
Link to comment
Share on other sites

Thanks for stopping by and sorry about spamming your blog, I didn't know how else to contact you. I assumed your inbox here would be full..

 

(\_GPE) or (_GPE) ? I didn't even notice that. I don't know why that has changed in my patched DSDT. Maybe IASL does that? I know I didn't do it.

 

I added your code above and applied the patch to a fresh DSDT with MacIASL, it looks good to go, no compiler errors and everything is in the right place.

 

Here's a clean DSDT (dumped with Clover) if you'd like to verify yourself.

T61_unmodified_dsdt.dsl.zip

 

Another thing while you are here, I've been meaning to ask you if there's a way to make ACPIBacklight.kext work with this:

T61_Backlight_SSDT.dsl.zip

 

The T61 has brightness control methods hidden away in the attached SSDT table. It seems like everything is there, but I don't understand what's missing for it to work.

I tried moving it into DSDT under the PNLF device like I've seen others do but I couldn't figure it out how to do that properly.

 

I did something right; once I moved PNLF into the same scope as VID0, ACPIBacklight started complaining about about invalid data in the BQC method, I guess this means that ACPIBacklight can see the SSDT table at least.

 

I'm surprised that I haven't found any examples of anyone using that SSDT anywhere. All I see are patched X3100 framebuffer kexts.

 

Some related information I've collected that I'm not smart enough to know what to do with.

Thinkpad ACPI Linux kernel module - specifically this part of the source code.

LP141WX3-TLR1.pdf.zip

acpi_igd_opregion_spec.pdf.zip

Link to comment
Share on other sites

Thanks for stopping by and sorry about spamming your blog, I didn't know how else to contact you. I assumed your inbox here would be full..

 

(\_GPE) or (_GPE) ? I didn't even notice that. I don't know why that has changed in my patched DSDT. Maybe IASL does that? I know I didn't do it.

 

I added your code above and applied the patch to a fresh DSDT with MacIASL, it looks good to go, no compiler errors and everything is in the right place.

Thanks for the confirmation. I'll commit the changes into the repo.

 

Another thing while you are here, I've been meaning to ask you if there's a way to make ACPIBacklight.kext work with this:

attachicon.gifT61_Backlight_SSDT.dsl.zip

 

The T61 has brightness control methods hidden away in the attached SSDT table. It seems like everything is there, but I don't understand what's missing for it to work.

Generally, we ignore the OEM brightness methods and simply replace them with "Brightness Fix (Haswell)" or "Brightness Fix (HD3000/HD4000)". There is no need to move things around. Simply add PNLF to the SSDT with the GFX0 device. That's for hardware as old as 1st gen Intel HD (Arrandale). Not sure about really old hardware (such as X3100).

Link to comment
Share on other sites

 Share

×
×
  • Create New...