Jump to content

[Guide] Dell Inspiron 6400/9400/1520/1720/E1405/E1505/E1705 Intel Core Duo


devilhood
 Share

2,614 posts in this topic

Recommended Posts

Dual Cores will NOT (other then the sleep trick, which causes synchronization)

function properly until either a kernel patch comes out for syncing the TSC, or a kext is created to do the same thing,

or as we've seen somewhat in snow, apple stops assuming the TSC is in sync.

 

 

http://www.ideastorm.com/article/show/7620...T_timer_support.

 

but although someone will do a kernel without syncing the TSC, dell didn't have a bios(for these laptops, 6400/9400/1520, etc) with HPET timer support.

Link to comment
Share on other sites

Actually, the 9400 does have an hpet. If you dissasemble your DSDT you will find the HPET defined in there. But it does on OS check, so it's then not activated via the _STA call.

 

And even if the HPET is activated, mach/xnu converts the hpet data via tsc calc'd vals already (which are skewed).. from i386_init.c

you get:

 

tsc_init(); //found in tsc.c

hpet_init(); //found in hpet.c

 

I've been staring @ the code for a while..

Link to comment
Share on other sites

u´re right cosmo, i'll hope that works :( .

 

edit: i find this

 

tsc_init

One of the first parts of the bootstrap process is the tsc_init function. The TSC is of course the Time-Stamp Counter found on all Intel chips since the original Pentium. There's really no need to hack xnu to support processors without a TSC since you'd likely never want to run xnu on such a processor. I mean, really, who wants to run on a 486? I sure don't. I don't even have a 486 anywhere and I am known for being a packrat of older machines.

 

What the TSC does is count upwards once with each processor clock tick. It provides a nice way to see how much time has elapsed. If you know the CPU frequency and the difference between two reads of the TSC you know exactly how much time has elapsed. This is important to xnu because xnu is a so-called tickless kernel. That is, rather than maintaining a fixed time-slice, xnu is able to maintain wall-time by basing it off of the number of processor cycles that have elapsed, that is, the difference between two reads of the TSC.

 

Of course, in order to translate from wall-time (i.e. seconds) to processor ticks you need to know how many of those ticks occur in a second. Which is of course quite simply the processor's MHz rating.

 

Apple, however, seems to "Think Different" when it comes to determining processor MHz as compared to most other operating systems. It isn't necessarily a bad thing though. Apple's method is based on the assumption that the CPU clock runs at an integer multiple of the bus clock. In the code, this multiplier is refered to as the tscGranularity. This is, of course, the "CPU Multiplier" that most anyone with any familiarity of computer hardware is already quite familiar with. If you know the bus speed and know the CPU multiplier, then you thus know the CPU MHz.

 

Apple's code starts off with the assumption that the bootloader (which is typically Apple's own boot.efi) has filled in the FSBFrequency property of the "IODeviceTree:/efi/platform" node. That's another discussion entirely but the quick summary is that the modified boot-132 on my bootloader page currently simply fills this in at 200 MHz which is not entirely accurate since no clock really runs that smoothly, but close enough assuming you really do have a 200 MHz bus. I do since I've got a MacBook Pro and the other machine I've run xnu on is a P4 3.0 GHz with a 915G chipset. Both have a declared 200 MHz FSB. Of course, with the real boot.efi, the FSBFrequency is not quite exactly 200 MHz but actually a tiny bit less in my case.

 

The next thing that tsc_init does is retrieve the CPU clock multiplier. This is achieved by using the rdmsr instruction with the 0x198 (IA32_PERF_STAT) MSR number. The interesting thing here is that while Intel documents that MSR as existing since the Pentium 4, they only document bits 15:0 as being valid. It is not unti the Core 2 processor that Intel documents bits 44:40 as containing the maximum bus ratio. Apple must know something that Intel knows because they specifically check for either Core or Core 2 processors then proceed to use those bits from the MSR. Interestingly enough, adding CPU family 0xf to the list of valid platforms also works for me on my P4. Somewhere (not in this particular Intel manual) I have seen that indeed later model P4 (such as the one I have) do indeed implement this MSR just like Core and Core 2 CPUs.

 

Perhaps even more interesting is that the particular MSR is not necessarily valid unless XE (a.k.a. Intel Dynamic Acceleration) is enabled. I assume that means MSR 38h but I could be wrong. At any rate, Apple's code blindly assumes that the MSR works (i.e. doesn't issue a #GP(0)) and returns valid data. If the MSR returns 0 then all hell breaks loose because the tscGranularity value is then immediately used as the denominator of an integer division. Again, this is not exactly the best written code. It pretty much assumes Core-based processors. Period.

 

The problem is that when I'm running under VMware I of course have a Core-based processor. But VMware returns 0 for that MSR and doesn't issue #GP(0). So reading the MSR with a recovery trap is not an option. One simply has to make sure that tscGranularity is not 0. If it is zero, then some other method needs to be used.

 

The aforementioned DaemonES 10.4.9 release improves on Apple's implementation of this function by implementing support for a number of other chips. Pretty much every recent Intel and AMD chip appears to be supported. However, it does need a little bit of work and to be honest I did not care for the way he measured CPU and BUS Frequency together using the PM timer. It seemed to do only one measurement and doing this under VMware (where ironically this is actually necessary) would seem to require slightly more robust code. Having had a look at the old xnu code that uses the i8254 and the current Linux code which does the same although in a much nicer manner I decided that the current Linux method was by far the best. Ultimately though, it doesn't have to be all that accurate since it's only determining the nearest integer multiple due to the bus speed having already been provided by the boot loader.

 

 

The HPET

The HPET is a feature found in modern Intel chipsets. It is also known as the multimedia timer. If you are starting xnu on a modern machine you probably have one so there is no need to hack the xnu source. Unfortunately, if you are trying to run under VMware you will note that VMware doesn't virtualize the HPET. That's a bummer because running under VMware is a hell of a lot easier than keeping an entire spare machine around. Besides that, it does not appear that it is legal to run Darwin on anything other than a real Mac due to the need to use some critical kernel extensions from the OS X release. So unless you have a spare Mac lying around to devote to Darwin, you're going to want to use VMware.

 

The hpet_init function is a very simple bit of code that reads the LPC's RCBA register directly from the PCI bus 0, device 31, function 0 config space. It seems that all ICH chipsets (even back to ICH 4 a.k.a. 845) have the LCBA on 0:31.0 with the RCBA register at the same config offset. But VMware virtualizes an old PIIX4 (a.k.a. 440BX) which of course has an ISA controller, not an LPC. There is no VMware HPET.

 

The problem with the xnu code as-is is that it assumes a PCI device exists at 0:31.0 and it assumes that that device is the LPC. To be honest, I am not entirely sure why it does this. This got added around the 8.5 (i.e. 10.4.5) timeframe although you can only know this by disassembling the binary since there are no corresponding source releases. It looks like it was some weird hack to get rid of the need for the old i8254 PIT code which was admittedly hairy.

 

What I don't get though is that it seems the HPET is only really required by the AppleIntelCPUPowerManagement.kext. There it makes sense because that kext controls the aforementioned Intel Dynamic Acceleration (i.e. the latest incarnation of SpeedStep) which modifies the CPU clock multiplier and thus changes all of those careful calculations done in tsc_init. Of course, if the processor completely naps, then the TSC doesn't increment at all and the HPET is then the source of accurate wall time.

 

So that explains the need for the HPET but what I don't get is why Apple wrote it the way they did. Within xnu, the hpet is set up seemingly solely for the purpose of passing its info to the power management extension and it seems to me that it would have possibly been better to just have that kernel extension work the HPET directly. Or perhaps to have everything to do with the HPET localized to the AppleHPET kernel extension and let the CPU power management consume that as a provider nub.

 

On the other hand, perhaps there was some particular design decision to put the HPET/CPU interaction within the kernel, but that doesn't even really make sense either.

 

At any rate, the fix is simple. Don't go looking for the RCBA if the PCI vendor of the 00:31.0 device is 0 or 0xffff (i.e. all bits on or all bits off). Of course, that leaves some nVidia chipset users without a working HPET and it also means that merely loading AppleIntelCPUPowerManagement.kext will crash the kernel but IMO that's due to shoddy design of this whole system and this is the best I'm willing to do for now because anything more requires a pretty big rewrite.

 

I'm also somewhat confused about the DaemonES source patch which actually reimplements rdHPET to use the PM timer. Considering that AppleIntelCPUPowerManagement.kext seems to be the only client it doesn't seem to be required unless you need CPU power management. Of course, in VMware this doesn't apply so we can just not use the kext.

 

http://tgwbd.org/darwin/xnu.html

Link to comment
Share on other sites

Ok.....please....what exactly do you have to do to patch the kernel? anyone have a step by step?

 

1. Download compiled vanilla kernel of the version you have. (posted by cosmo1t)

 

2. Google Osx86tools and download it

 

3. Change your kernel by using Osx86tools

 

4. Cross your fingers and Reboot.

 

5. Get impressed by both working cores!!!

Link to comment
Share on other sites

follow cosmo1t's post and under Kassi's post he provides already patched kernels from 9.1 up to 9.4 - here.

 

 

Ok...did that...works perfectly...I would still love to know how to patch it on my own for when they update the vanilla kernel...so i wouldn't have to wait for one on here.

 

Anybody have a step by step?

 

And does anyone have a way to get ethernet working in 10.5.4...my broadcom 44 is still giving me loopbacks!!!!!

Link to comment
Share on other sites

Ok...did that...works perfectly...I would still love to know how to patch it on my own for when they update the vanilla kernel...so i wouldn't have to wait for one on here.

 

Anybody have a step by step?

 

And does anyone have a way to get ethernet working in 10.5.4...my broadcom 44 is still giving me loopbacks!!!!!

 

hmm true, I'd like to patch modbin's 9.4 and have no idea. the patch file posted by Kassi can be opened in a text editor. I am not a programmer, but it starts with the code "diff" and I assume there is a program that will take this compare the lines with the original and replace them. still looking how to do it.

Link to comment
Share on other sites

Does anyone have a fix for the broadcom problem? "During normal Internet browsing and LAN operations via Ethernet, if you find that your network connection seems to be randomly cutting out, this is because of an incompatibility between the old AppleBCM440XEthernet.kext and the new IONetworkingFamily.kext"

 

As much as I am usually wireless, there are times I need to be wired.

Link to comment
Share on other sites

hmm true, I'd like to patch modbin's 9.4 and have no idea. the patch file posted by Kassi can be opened in a text editor. I am not a programmer, but it starts with the code "diff" and I assume there is a program that will take this compare the lines with the original and replace them. still looking how to do it.

 

 

code .diff its a patch for any kernel, but i guess that the kernel must be the exact version that .diff patcher. i'll hope that netkas of anyone else, add to them kernels ,TSC SYNC.

Tsc sync + speedstep (A)

Link to comment
Share on other sites

Wow, finaly someone did it, without modded bios! :)

Now i hope that TBCarey will find a way to fix his AppleHDA to get sound trought speakers :P and get a nearly perfect hackintosh Laptop!

 

I was thinking the same yesterday. speaker mute with headphones and it's perfect. except that I don't have full sleep yet. I gave up on two cores already, but maybe I get sleep as well if I wait a little longer.

 

Does anyone have a fix for the broadcom problem? "During normal Internet browsing and LAN operations via Ethernet, if you find that your network connection seems to be randomly cutting out, this is because of an incompatibility between the old AppleBCM440XEthernet.kext and the new IONetworkingFamily.kext"

 

As much as I am usually wireless, there are times I need to be wired.

 

I had no idea that ethernet isn't working. will test this tonight. I have the same hardware. can't you just use the old IONetworkingFamily.kext?

Link to comment
Share on other sites

Hi all,

 

I just patch my kernel and its work fine !!!! Both core started :)

 

But I lost USB hotplug, can you help me ??

 

I already try to reinstall USB patch in Kalyway DVD but it's don't works,

 

idea ??

 

Thx all !

Link to comment
Share on other sites

To cores working perfectly! Also just to throw an update out there, I also got my speedstep functioning via Coolbook. The $10 license fee is worth the cold laptop let me tell you.

 

Now if we someone can get headphone/microphone working properly, I can get my voice-chat back in World of Warcraft and never, ever go back to windows again. :D

Link to comment
Share on other sites

I just try to restore my old kernel and I edit my com....plist with CPUS=1 :s and my USB works fine !!!!

 

I don't understand !!

 

I explain more my problem, it's strange !!

 

- So with new kernel I can run OSX without CPUS=1 yeah !! But my USB don't work or works half !!!

 

- If I plug USBstick, etc... before run MacOsX, when I run MacOsX, my USBstick work fine !!

 

- But if I plug my USBstick after run OsX86 (when i'am on my desktop, my USBstick doesn't work !!!!

 

It's strange for me !!

 

Do you have an idea ??

 

Thx for your Help !!

 

I specify that I use 9.4 kernel for my internal HDD and 9.2 for my USBHDD and I have the same and strange problem !

Link to comment
Share on other sites

I was thinking the same yesterday. speaker mute with headphones and it's perfect. except that I don't have full sleep yet. I gave up on two cores already, but maybe I get sleep as well if I wait a little longer.

I had no idea that ethernet isn't working. will test this tonight. I have the same hardware. can't you just use the old IONetworkingFamily.kext?

 

 

Since installing with Kalyway 10.5.2, whenever I try to send packets I get a loopback ip. Occasionally I get an actually IP until I try to send and receive packets.

 

It was working previously. And from reading that statement on the front page, its apparently not just me.

 

When I tried using the older ionetworking (which I did a few days ago) I lost my wireless. Didn't even see that I had an airport (which comes up on its own - its a dell 1500)

Link to comment
Share on other sites

I just try to restore my old kernel and I edit my com....plist with CPUS=1 :s and my USB works fine !!!!

I don't understand !!

I explain more my problem, it's strange !!

- So with new kernel I can run OSX without CPUS=1 yeah !! But my USB don't work or works half !!!

- If I plug USBstick, etc... before run MacOsX, when I run MacOsX, my USBstick work fine !!

- But if I plug my USBstick after run OsX86 (when i'am on my desktop, my USBstick doesn't work !!!!

It's strange for me !!

Do you have an idea ??

Thx for your Help !!

 

no idea, sorry. Just checked a couple of my USB thumb drives and external drives. they all work. it must be a combination of different problems you have. kernel and sth else. do you have any other kernel flags in com.apple.boot.plist that may interfere? would be a wild guess to make. I suggest you back up your current installation. install a fresh 10.5.3, update to 10.5.4 and try again. if everything fails you can still go back to your current setting (I can recommend Acronis True Image for backing up OSX partition).

sorry, not much help here.

 

Since installing with Kalyway 10.5.2, whenever I try to send packets I get a loopback ip. Occasionally I get an actually IP until I try to send and receive packets.

 

It was working previously. And from reading that statement on the front page, its apparently not just me.

 

When I tried using the older ionetworking (which I did a few days ago) I lost my wireless. Didn't even see that I had an airport (which comes up on its own - its a dell 1500)

 

hmm, I see what you are saying. I don't even see my ethernet and no matter what I tried so far it wouldn't recognize it. I will back up my current installation and play with some kexts. hopefully there is a solution.

thanks

Link to comment
Share on other sites

no idea, sorry. Just checked a couple of my USB thumb drives and external drives. they all work. it must be a combination of different problems you have. kernel and sth else. do you have any other kernel flags in com.apple.boot.plist that may interfere? would be a wild guess to make. I suggest you back up your current installation. install a fresh 10.5.3, update to 10.5.4 and try again. if everything fails you can still go back to your current setting (I can recommend Acronis True Image for backing up OSX partition).

sorry, not much help here.

hmm, I see what you are saying. I don't even see my ethernet and no matter what I tried so far it wouldn't recognize it. I will back up my current installation and play with some kexts. hopefully there is a solution.

thanks

 

Thanks for the assist...its a real pain in the...well....

 

When I want to transfer files quickly between my nas and my computer I usually use a crossover cable. Obviously that won't work if I get a loopback.

 

Also I have a cisco phone that I use internet sharing on. I'd love to be able to do my office work (I work from home a lot) and stay in Mac. Unfortunately because I need to use the phone I have to share the Wireless internet through the ethernet cable...can't do that either.

Link to comment
Share on other sites

 Share

×
×
  • Create New...