Jump to content

[GUIDE] Making a DSDT.aml for Dell XPS M1330, XPS M1530, and XPS M1730

immo

By immo,
in Laptops

 Share
2,030 posts in this topic

Recommended Posts

kahuna0k
kahuna0k
Posted
Posted

Hello,

 

I've been able to finally upgrade my M4400 to 10.6.8 following the new fixes but I'm having problems with right USB ports, sometimes they are not working. I have confirmed that have the IRQNoFlags fix applied. I have attached my DSDT. Also sleep is not working neither C-States, everything else is working. Any idea for fixing the USB ports? (I have give up on c-states and sleep :D )

 

Regards,

DSDT_M4400_QX9300.zip

Link to comment
Share on other sites
immo
immo
Posted
  • Author
Posted
Hello,

 

I've been able to finally upgrade my M4400 to 10.6.8 following the new fixes but I'm having problems with right USB ports, sometimes they are not working. I have confirmed that have the IRQNoFlags fix applied. I have attached my DSDT. Also sleep is not working neither C-States, everything else is working. Any idea for fixing the USB ports? (I have give up on c-states and sleep :D )

 

Regards,

 

A similar problem was encountered with the first release of Snow Leopard, but was not an issue on Leopard on M1330 and M1530. The issue was resolved by removing IRQ statements. These are in the guide, but since you have a different computer you may have to look somewhere different within the DSDT. I would also question whether or not the USB power fix would work on different machines as it is in the guide.

 

Immo

Link to comment
Share on other sites
talisman
talisman
Posted
Posted
As promised (although late), I've updated the first post with the kexts I currently use. I also added new "What Should Work" and "What Will Not Work" sections, and a new "Required and Recommended Software" section, along with hints to solve common problems.

 

Immo

 

Just a note: Ethernet works in SL on M1530.

 

For some cosmetic changes:

 

To get the correct macid one has to modify the binary in AppleYukon2.kext to the correct one, otherwise it will show as 00:11:22:33:44:55

If one wants to have the card correctly recognized as 88E8040 then the plist in the same kext has to be modified to include that. Otherwise it will show up as 88E804Z.

 

Neither of the above makes any difference to the performance.

Link to comment
Share on other sites
LatinMcG
LatinMcG
Posted
Posted

WHY SHUTDOWN WORKS FOR M1530 (aka WHy have i been barking up the wrong tree .. MECI blahh)

www.intel.com/content/dam/doc/datasheet/intel-io-controller-hub-8-datasheet.pdf

 

M1330 has been using SLP_SMI_EN whole time and it was thought to be SLP_EN

or has it been using SMI_EN ?

30h–33h SMI_EN SMI# Control and Enable — 00000000h R/W, WO,

R/W (special)

 

SLP_EN in ich8 southbridge is pmbase +PM1a_CNT(0x1004) bit 13 (not 0x1030h bit 4 as previously thought)

 

for M1530 this is wht works.. why ?

 

9.8.3.14 SMI_EN—SMI Control and Enable Register

I/O Address: PMBASE + 30h Attribute: R/W, R/W (special), WO ( 30h = 0x1030 )

Default Value: 00000000h Size: 32 bit

Lockable: No Usage: ACPI or Legacy

Power Well: Core

Note: This register is symmetrical to the SMI status register.

 

Bit 4 is

SLP_SMI_EN — R/W.

0 = Disables the generation of SMI# on SLP_EN. Note that this bit must be 0 before

the software attempts to transition the system into a sleep state by writing a 1 to

the SLP_EN bit.(in

1 = A write of 1 to the SLP_EN bit (bit 13 in PM1_CNT register) will generate an SMI#,

and the system will not transition to the sleep state based on that write to the

SLP_EN bit.

 

==============================

 

for M1330 it should be

 

5.13.7.2 Initiating Sleep State

Sleep states (S1–S5) are initiated by:

 

• Masking interrupts, turning off all bus master enable bits, setting the desired type

in the SLP_TYP field, and then setting the SLP_EN bit. The hardware then attempts

to gracefully put the system into the corresponding Sleep state. blah blah blah

 

Sleep Type (SLP_TYP) — R/W. This 3-bit field defines the type of Sleep the system

should enter when the SLP_EN bit is set to 1. These bits are only reset by RTCRST#.

 

Sleep Type (SLP_TYP) Power Management 1 Control (PM1_CNT) PMBase + 04h 12:10 0 (not 30h as previously thought)

 

then

13 Sleep Enable (SLP_EN) (PMBase + 04h bit 13 in PM1_CNT register) — WO. Setting this bit causes the system to sequence into

the Sleep state defined by the SLP_TYP field.

 

9.8.3.3 PM1_CNT—Power Management 1 Control

bit 12:10 = 111b Soft Off 0x07 = 111 Assert SLP_S3#, SLP_S4#, and SLP_S5#: Typically maps to

S5 state.

 

ohh wait.. whats is this stopping it ? (what works for M1530) SCI_EN is not set ? or is it set dunno yet

SLP_SMI_EN — R/W. = 0x1030 4, 1, ... SLPE in the dsdt _PTS

 

0 = Disables the generation of SMI# on SLP_EN. Note that this bit must be 0 before

the software attempts to transition the system into a sleep state by writing a 1 to

the SLP_EN bit.

1 = A write of 1 to the SLP_EN bit (bit 13 in PM1_CNT register) will generate an SMI#,

and the system will not transition to the sleep state based on that write to the

SLP_EN bit.

 

ok or is it ? more stuff

 

PME_B0_STS — R/WC. This bit will be set to 1 by the ICH8 when any internal

device with PCI Power Management capabilities on bus 0 asserts the equivalent of

the PME# signal. Additionally, if the PME_B0_EN bit is set, and the system is in an

S0 state, then the setting of the PME_B0_STS bit will generate an SCI (or SMI# if

SCI_EN is not set). If the PME_B0_STS bit is set, and the system is in an S1–S4

state (or S5 state due to SLP_TYP and SLP_EN), then the setting of the

PME_B0_STS bit will generate a wake event, and an SCI (or SMI# if SCI_EN is not

set) will be generated. If the system is in an S5 state due to power button

override, then the PME_B0_STS bit will not cause a wake event or SCI.

The default for this bit is 0. Writing a 1 to this bit position clears this bit.

 

(i remember the kextunload to get shutdown. someone mentioned their applehda caused issue)

Note: On ICH8, HD audio wake events are changed to be reported in this bit.

ME “maskable” wake events are also reported in this bit.

 

from linux it can be done.. port this to dsdt should work

http://smackerelofopinion.blogspot.com/201...l-82801-io.html

 

ohh where is masterchief or kizwan when we need them. (quick turn on the hack Light signal.. maybe hack man comes to rescue)

 

in coreboot speak

static void southbridge_smi_sleep(unsigned int node, smm_state_save_area_t *state_save)
292	{
293	        u8 reg8;
294	        u32 reg32;
295	        u8 slp_typ;
296	        /* FIXME: the power state on boot should be read from
297	         * CMOS or even better from GNVS. Right now it's hard
298	         * coded at compile time.
299	         */
300	        u8 s5pwr = CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL;
301	
302	        /* First, disable further SMIs */
303	        reg8 = inb(pmbase + SMI_EN);
304	        reg8 &= ~SLP_SMI_EN;
305	        outb(reg8, pmbase + SMI_EN);
306	
307	        /* Figure out SLP_TYP */
308	        reg32 = inl(pmbase + PM1_CNT);
309	        printk(BIOS_SPEW, "SMI#: SLP = 0x%08x\n", reg32);
310	        slp_typ = (reg32 >> 10) & 7;
311	
312	        /* Next, do the deed.
313	         */
314	
315	        switch (slp_typ) {
316	        case 0: printk(BIOS_DEBUG, "SMI#: Entering S0 (On)\n"); break;
317	        case 1: printk(BIOS_DEBUG, "SMI#: Entering S1 (Assert STPCLK#)\n"); break;
318	        case 5:
319	                printk(BIOS_DEBUG, "SMI#: Entering S3 (Suspend-To-RAM)\n");
320	                /* Invalidate the cache before going to S3 */
321	                wbinvd();
322	                break;
323	        case 6: printk(BIOS_DEBUG, "SMI#: Entering S4 (Suspend-To-Disk)\n"); break;
324	        case 7:
325	                printk(BIOS_DEBUG, "SMI#: Entering S5 (Soft Power off)\n");
326	
327	                outl(0, pmbase + GPE0_EN);
328	
329	                /* Should we keep the power state after a power loss?
330	                 * In case the setting is "ON" or "OFF" we don't have
331	                 * to do anything. But if it's "KEEP" we have to switch
332	                 * to "OFF" before entering S5.
333	                 */
334	                if (s5pwr == MAINBOARD_POWER_KEEP) {
335	                        reg8 = pci_read_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3);
336	                        reg8 |= 1;
337	                        pci_write_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3, reg8);
338	                }
339	
340	                /* also iterates over all bridges on bus 0 */
341	                busmaster_disable_on_bus(0);
342	                break;
343	        default: printk(BIOS_DEBUG, "SMI#: ERROR: SLP_TYP reserved\n"); break;
344	        }
345	
346	        /* Write back to the SLP register to cause the originally intended
347	         * event again. We need to set BIT13 (SLP_EN) though to make the
348	         * sleep happen.
349	         */
350	        outl(reg32 | SLP_EN, pmbase + PM1_CNT);
351	
352	        /* In most sleep states, the code flow of this function ends at
353	         * the line above. However, if we entered sleep state S1 and wake
354	         * up again, we will continue to execute code in this function.
355	         */
356	        reg32 = inl(pmbase + PM1_CNT);
357	        if (reg32 & SCI_EN) {
358	                /* The OS is not an ACPI OS, so we set the state to S0 */
359	                reg32 &= ~(SLP_EN | SLP_TYP);
360	                outl(reg32, pmbase + PM1_CNT);
361	        }
362	}

 

i need help with this this to SystemIO PMBASE 1000 + 04h aka 0x1004 PM1A

 

im not good at typing BitOneese!

 

 

C-STATES issue

start reading at

 

9.8.1.4 GEN_PMCON_LOCK—General Power Management Configuration Lock

Register

Offset Address: A6h Attribute: R/W

Default Value: 00h Size: 8-bit

Lockable: No Usage: ACPI

Power Well: Core

This register is used to enable new C-state related modes.

 

changing the pace.. i found this dsdt with a strange code example in _PTS

www.sci.fi/~syrjala/acpi/dsdt.aml

    Method(\_PTS,1,NotSerialized)

   // _PTS - Prepare To Sleep
   //
   // Executed by the OS at the beginning of the sleep
   // process for S1, S2, S3, S4, and orderly S5
   // shutdown. Before OSPM notifies native device
   // drivers and prepares the system software for a
   // system sleeping state, it executes _PTS Thus,
   // _PTS can be executed a relatively long time
   // before actually entering the desired sleeping
   // state. In addition, OSPM can abort the sleeping
   // operation without notification to OSPM, in which
   // case another _PTS would occur some time before
   // the next attempt by OSPM to enter a sleeping
   // state. The _PTS method cannot modify the current
   // configuration or power state of any device in the
   // system.
   //
   //  IN: Arg0 SleepState. 1=S1,2=S2,3=S3,4=S4,5=S5
   // OUT: None
   //
   {
       Or(Arg0,0xF0,Local0)
       Store(Local0,DBG1 /* \DBG1 */)
       If(LEqual(Arg0,0x04))
       {
           Sleep(0x64)
       }
       If(LNot(LEqual(Arg0,0x05)))
       {
           Store(Zero,GP00 /* \GP00 */)
       }
       If(LNot(LEqual(Arg0,0x05)))
       {
           Or(Arg0,0x50,Local1)
           Store(Local1,SCP /* \SCP */)
       }
       If(LEqual(Arg0,0x01))
       {
           And(GAR1 /* \GAR1 */,0xFD,GAR1 /* \GAR1 */)
           And(GAR2 /* \GAR2 */,0x02,Local0)
           Or(Local0,GAR1 /* \GAR1 */,GAR1 /* \GAR1 */)
           Store(G_ST /* \G_ST */,Local1)
           While(LNot(LEqual(Local1,0x00)))
           {
               Store(Local1,G_ST /* \G_ST */)
               Store(G_ST /* \G_ST */,Local1)
           }
           Or(IRQR /* \IRQR */,0x80,IRQR /* \IRQR */)
       }
       If(LEqual(Arg0,0x05))
       {
           Store(Zero,GE00 /* \GE00 */)
       }
       Sleep(0x07D0)
   }

 

Store(Zero,GE00 /* \GE00 */)

 

    OperationRegion(\GPST,SystemIo,0x4020,0x04) //4020 to us inspirons is 1020
   Field(\GPST,ByteAcc,NoLock,Preserve)
   {
       GS00,1,
       GS01,1,
       GS02,1,
       GS03,1,
       GS04,1,
       GS05,1,
       GS06,1,
       GS07,1,
       GS08,1,
       GS09,1,
       GS0A,1,
       GS0B,1,
       GS0C,1,
       Offset(0x02),
       GE00,1,
       GE01,1,
       GE02,1,
       GE03,1,
       GE04,1,
       GE05,1,
       GE06,1,
       GE07,1,
       GE08,1,
       GE09,1,
       GE0A,1,
       GE0B,1,
       GE0C,1,
       Offset(0x04)
   }

 

So far i got restart working instead of shutdown. so its missing a check or set Zero somewhere

http://www.insanelymac.com/forum/index.php?showtopic=266803

Link to comment
Share on other sites
myrorym
myrorym
Posted
Posted

@LatinMcG

 

All looks very promising for shutdown with m1330. I recently sold mine to a friend who I will provide with continued support. Perhaps I can test any DSDT edits for you. Is a m1330 with 8400gs.

 

Also, I am looking for tips on using the HDMI output. Re-installed 10.6 and combo updated to 10.6.2. Nothing but freezes when plugin while OSX loaded. Never breaks grey screen if plugged in on boot.

Using latest m1330 dsdt in topic, should I use older one and update anything to achieve HDMI. Does HDMI require other DSDT edits not included in the topic dsdts?

Link to comment
Share on other sites
pavilionsnowleopard
pavilionsnowleopard
Posted
Posted

Has anyone else experienced decreased battery life with Lion?

 

I have been lurking for awhile and I have learned a lot from the his thread.

 

I had a perfect M1330 with 10.6.6 using DSDT_M1330_NVIDIA_ANYCPU_20110525.zip and I would get 2.5-3 hours.

 

With Lion, I had to use DSDT_M1330_NVIDIA_ANYCPU_20110720.zip and I am now getting 1.5-2 hours...if I'm lucky.

 

The only things I changed were fakesmc (KP issue loading Lion) and wireless driver (BCM94312MCG) for Lion.

 

 

Does anyone have any suggestions? Thanks in advance.

 

XPS M1330

T5250 processor

4Gb RAM

BCM94312 wifi

Link to comment
Share on other sites
LatinMcG
LatinMcG
Posted
Posted

i think im gona retire.. tired of no input from (knowledgeable) peoples. osx seems dead .. xcept for noobies.

linux windows it is.

 

i mean dam i got so much info dug up and not a single person posts anything (example http://www.insanelymac.com/forum/index.php?showtopic=266803)

and irc is for idlers.

 

osx hackin is borring if no fing input.

Link to comment
Share on other sites
myrorym
myrorym
Posted
Posted
i think im gona retire.. tired of no input from (knowledgeable) peoples. osx seems dead .. xcept for noobies.

linux windows it is.

 

osx hackin is borring if no fing input.

 

Sorry to hear. I was excited about the potential for a shutdown fix, but alas I did sell my m1330. I am still interested in your findings and perhaps could help through testing various DSDT fixes (sold to friend, so I can still borrow to help make it better)

 

I find a lot of people aren't as active in this thread, maybe due to new hardware(desktop and lappies) people are buying. It's hard to get a lot of attention here, not sure if m1330s and such are being sold new.

 

I do appreciate your efforts and this thread in particular, it introduced me to knowledge that was necessary to undertake my Hack Pro project. I wish I had more experience to tackle remaining issues of m1330, but I can only test and report, I don't have energy to learn the machinations of what you are learning. Not sure where the other pros are, but I agree that it is getting boring without knowledgable dialog.

 

I still check this thread to see about remaining issues for m1330, but my osx86 time has been redirected to different hardware, which for the time being is stable for my using. I haven't really given in te Lion yet, so there isn't a lot I'm trying to figure out right now. Not sure if the seasons have a huge effect on participation, but summertime in US seems like less issues are being solved.

 

But again, I thank you and all the DSDT wizards(not script apps) and wickens that have enlightened us n00bs and given their unrewarded sweat to the community. It has given me the ability to perform my work in a way that was thought not possible.

 

Thank you, and cheers. Enjoy retirement, especially once the SS checks start rollin in. I've got a few decades to go... and then who knows?

Link to comment
Share on other sites
VMonHeros
VMonHeros
Posted
Posted
i think im gona retire.. tired of no input from (knowledgeable) peoples. osx seems dead .. xcept for noobies.

linux windows it is.

 

i mean dam i got so much info dug up and not a single person posts anything (example http://www.insanelymac.com/forum/index.php?showtopic=266803)

and irc is for idlers.

 

osx hackin is borring if no fing input.

 

Hi, I'm sorry to hear that! I would love to help you on that, but I'm not skilled enough, even if I did my best in my DSDT B).

 

But if you want I did some test, why not !!! I will have a deeper look on your finding.

Link to comment
Share on other sites
immo
immo
Posted
  • Author
Posted
i think im gona retire.. tired of no input from (knowledgeable) peoples. osx seems dead .. xcept for noobies.

linux windows it is.

Sorry you feel that way LatinMcG, but I understand where you're coming from. I'd so much like to invest time reading into posts as the one you've mentioned and understanding the underlying concepts enough that I could contribute, but I honestly do not have the time to invest. I can probably count on one hand the people I've encountered that have your level of DSDT understanding that have posted in this thread (I am most definitely not one of them, and no offense to anyone else), and they have gotten bored and moved on as well.

 

In any case, I think I speak for us all when I say that your contributions to hacking these computers are very much appreciated, so thanks for sharing some of your genius with us.

 

Immo

Link to comment
Share on other sites
dlach
dlach
Posted
Posted
i think im gona retire.. tired of no input from (knowledgeable) peoples. osx seems dead .. xcept for noobies.

linux windows it is.

 

i mean dam i got so much info dug up and not a single person posts anything (example http://www.insanelymac.com/forum/index.php?showtopic=266803)

and irc is for idlers.

 

osx hackin is borring if no fing input.

 

i think im gona retire.. tired of no input from (knowledgeable) peoples. osx seems dead .. xcept for noobies.

linux windows it is.

 

i mean dam i got so much info dug up and not a single person posts anything (example http://www.insanelymac.com/forum/index.php?showtopic=266803)

and irc is for idlers.

 

osx hackin is borring if no fing input.

 

LMcG,

 

Funny, the day you posted your new info, I wrote a reply saying that I would look into these pointers you provided, I must have gotten interrupted and never posted. I'm very interested and just need to squeeze some time out. My wife's m1330 died a while ago with the overheating motherboard short but I recent bought a replacement and again just need some time to do the swap. My 1530 is running OK but I'd like to get c-states working and I am very interested in what is causing my batteries to burn out (become unable to take a full charge).

 

I think I can help since I'm the one who interpolated the m1530 shutdown fix and I've delved into the acpi spec enough to be dangerous.

 

Essentially though, I think the others are right, these machines are out-dated and have lost momentum. A lot of people who pioneered work on OSX86 are tired of battling against closed specs (e.g. MCP7 series from Nvidia) and poor/cryptic DSDT implementations from vendors and are just buying real Macs. I know I've considered it. I originally got into hacks are a way to get OSX in the door in my house. I put together 5 hacks, m1330, m1530, two gigabyte uATX systems and an AOpen mini-itx system. When the m1330 died, I got my wife a macbook air. I've since rebuilt some mac-minis to seed into my family and ditched Windows (yeah!). At this point the m1530 and the AOpen which besides occasionally having an annoying CMOS reset on power outages, works perfectly, are the only active hacks. So the m1530 is the only motivator for me to invest time (other than a drive to fix things and figure things out).

 

Long-winded but anyway, I agree with Immo, your contributions are appreciated.

Link to comment
Share on other sites
LatinMcG
LatinMcG
Posted
Posted
LMcG,

 

cool i had a feeling u could try some stuff.

for the m1330 try the lessVolt=10 in chameleon to keep it cooler.

 

i think i got the restart working due to the watchdog action taken. instead of shutdown it reboots.

if theer was a way to debug the message of the TCO wed know what is causing restart instead of shutdown.. or maybe set the no reboot bit for it.

 

im not retiring. just less active as i have other priorities.

Link to comment
Share on other sites
raimdal
raimdal
Posted
Posted

I don't know why but now that I am on Lion 10.7.1, when I boot I can access to the system only if I boot for tree time...then boot perfectly...when doesn't boot it load till the end but at the login screen become black and doesn't do nothing and I have to push the botton to close the xps...there's a solution? I use macbook pro 6,1 for speed step and force wake, generate p and c state option in boot file...nothing of strange when it boot but I don't understand why I need to restart the system almost every time...the dsdt is the last with generic cpu...everything works except the intel wireless...but this it's known...like kexts I use AppleACPIBatterymanager, AppleACPIPlatform, AppleACPIPS"Nub, Apple EMC, FakeSMC with temperature plugin for cpu, voodoo hda, voodoomonitor,voodooSDHC, Directly in System/Library/extensions/ ...I'v tried string for cmos reset but also clearing the cache nothing change... Thank you.

Link to comment
Share on other sites
LatinMcG
LatinMcG
Posted
Posted
I don't know why but now that I am on Lion 10.7.1, when I boot I can access to the system only if I boot for tree time...then boot perfectly...when doesn't boot it load till the end but at the login screen become black and doesn't do nothing and I have to push the botton to close the xps...there's a solution? I use macbook pro 6,1 for speed step and force wake, generate p and c state option in boot file...nothing of strange when it boot but I don't understand why I need to restart the system almost every time...the dsdt is the last with generic cpu...everything works except the intel wireless...but this it's known...like kexts I use AppleACPIBatterymanager, AppleACPIPlatform, AppleACPIPS"Nub, Apple EMC, FakeSMC with temperature plugin for cpu, voodoo hda, voodoomonitor,voodooSDHC, Directly in System/Library/extensions/ ...I'v tried string for cmos reset but also clearing the cache nothing change... Thank you.

 

voodoomonitor, AppleACPIBatterymanager remove those 2 use voodoobattery on lion.

Link to comment
Share on other sites
CrimsonKnight13
CrimsonKnight13
Posted
Posted

Thanks for the guide, immo! I really appreciate the new DSDT for the M1530. I was able to get everything to work with additional kexts except the card reader. The VoodooSDHC.kext doesn't work with it. I'm attempting to figure out the AnyCardReader.kext but it doesn't work with editing.

 

I have a Ricoh internal multi-card reader that isn't recognized by 10.6.8 SL. Is there any way to alter the DSDT to see it? Thanks.

Link to comment
Share on other sites
immo
immo
Posted
  • Author
Posted
Thanks for the guide, immo! I really appreciate the new DSDT for the M1530. I was able to get everything to work with additional kexts except the card reader. The VoodooSDHC.kext doesn't work with it. I'm attempting to figure out the AnyCardReader.kext but it doesn't work with editing.

 

I have a Ricoh internal multi-card reader that isn't recognized by 10.6.8 SL. Is there any way to alter the DSDT to see it? Thanks.

 

Mine somewhat works with VoodooSDHC 32+64 bit build but I sometimes get a complete computer lockup on eject. I'm not aware of any DSDT patches that could help.

Link to comment
Share on other sites
CrimsonKnight13
CrimsonKnight13
Posted
Posted
Mine somewhat works with VoodooSDHC 32+64 bit build but I sometimes get a complete computer lockup on eject. I'm not aware of any DSDT patches that could help.

 

Would using the newest version of the iASLme tool help make the DSDT more tailored to my system build or am I chasing after a vapor trail?

Link to comment
Share on other sites
LatinMcG
LatinMcG
Posted
Posted
Thanks for the guide, immo! I really appreciate the new DSDT for the M1530. I was able to get everything to work with additional kexts except the card reader. The VoodooSDHC.kext doesn't work with it. I'm attempting to figure out the AnyCardReader.kext but it doesn't work with editing.

 

I have a Ricoh internal multi-card reader that isn't recognized by 10.6.8 SL. Is there any way to alter the DSDT to see it? Thanks.

 

http://www.insanelymac.com/forum/index.php...t&p=1729456

 

last codebox at bottom says

complete pcie section for m1530

that adds the extra stuff that i think helps it work.

i got it working for darwinx

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...