next »

[bthomp]

-- UPDATE 3 --
The AppleIntelCPUPowerManagement kernel extension is definitely wanting the HPET.  If only there was a way to get an ACPI dump from a MacBook Pro that contained the HPET APIC entry.  Then I would more likely be able to expose the HPET to the AppleACPIPlatform.kext successfully.  As it is, I'm not sure the best way to determine what OEM and device id information Apple looks for when determining if the HPET is compatible.

-- UPDATE 2 --
12/13/2007

I'm still getting the "Package 0 didn't find an HPET" error so I'm not exposing the HPET via the ACPI table properly (not in a way that the ACPI kext will pick it up).  I'm not sure why the Leopard installed OS shows this error while the installer DVD does not show the error... so whether or not this will ultimately resolve the sleep/wake issue is still up in the air.

-- UPDATE --
12/13/2007

I think I've got the HPET mapped and running on my Dell Latitude D820 (not 100% sure yet that it is being picked up by the ACPI kernel extension).  Unless I've initialized the APIC data incorrectly for the ACPI kext to pick it up this doesn't appear to fix the sleep/wake issue.  I'm going to do some work to verify that the OS is picking up the HPET properly just to be sure.  (I will probably just install my custom boot loader and see if the "Package 0 didn't find an HPET" error.

-- ORIGINAL --

Ok, I've been reading up on the Dell BIOS / Multi-Core pretty much all day looking at threads from the Linux Kernel and FreeBSD Kernel development circles.  Here are the following determinations and assumptions I have made:

Background:
http://lkml.org/lkml/2005/6/8/267
Dell BIOS does not export the HPET address through the ACPI tables.  The reasoning is that Windows does not use HPET and so Dell doesn't want to add the HPET address into the table for fear of breaking something.  So, why fix what isn't broken (except it is broken and has caused many headaches for non-Windows operating systems).

http://www.intel.com/design/chipsets/datashts/252516.htm
From what I could tell in that thread before and looking over a random datasheet for an intel chipset, the memory range 0xfed00000 - 0xfed003ff would be the most likely place to find a valid HPET on these systems.

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-02/msg00256.html
The Dell Latitude D820 only shows a sleep state of C1 (C2-C4 for some reason don't work).  The issue they point out here is that if one of the cores is slept then the other core will sleep too.  Since both cores reside on the same die they share the same voltage/current.  So it is not possible to run only 1 core at a lower power.  With the Dell D820 and Apple's kernel the second core is being slept and it is causing both cores to sleep (resulting in the choppy and undefined behavior).  Now, I suspect that Apple's kernel (in particular the power management extensions) account for the dual core sleep behavior using the HPET to generate interrupts to rewake the cores.

Conclusion:
My conclusion here is if we fix the HPET entry in the ACPI table that we pass through EFI to the Apple vanilla kernel, we *might* solve the dual core issue for Dell systems.  If it is possible to modify the ACPI HPET address during the stage 2 of the boot process and *if* the HPET is actually active (it is possible that the HPET is disabled and would need to be activated if possible) then Darwin may actually be able to get an HPET and solve the infamous "Package 0 didn't get an HPET." error while making dual cores actually work.

[bthomp]

For reference purposes:
http://www.intel.com/hardwaredesign/hpetspec_1.pdf
Documents the HPET ACPI 2.0 table definition.  We don't need to add full support for HPET, just enough support that the kernel can get the HPET registers it needs to handle power management properly.

[bthomp]

LinuxBIOS HPET ACPI implementation:
http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/arch/i386/boot/acpi.c?revision=2936&view=markup
http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/arch/i386/include/arch/acpi.h?revision=2936&view=markup
This should give me a head start in implementation as I will simply use their implementation for setting up the ACPI entry.  Now I just need to figure out how to inject it into the ACPI table that is entered into EFI.

ACPI Specifications:
http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf
Not *required* but definitely worth having around for reference.

[0xdeadbeef]

LinuxBIOS HPET ACPI implementation:
http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/arch/i386/boot/acpi.c?revision=2936&view=markup
This should give me a head start in implementation as I will simply use their implementation for setting up the ACPI entry.  Now I just need to figure out how to inject it into the ACPI table that is entered into EFI.

Check out this for pointers in injecting the efi data in the bootloader:
http://www.tgwbd.org/darwin/boot.html

[bthomp]

LinuxBIOS HPET ACPI implementation:
http://www.openbios.org/viewvc/trunk/LinuxBIOSv2/src/arch/i386/boot/acpi.c?revision=2936&view=markup
This should give me a head start in implementation as I will simply use their implementation for setting up the ACPI entry.  Now I just need to figure out how to inject it into the ACPI table that is entered into EFI.

Check out this for pointers in injecting the efi data in the bootloader:
http://www.tgwbd.org/darwin/boot.html

Thanks, been there

ACPI is a standard table that defines all of the components and their power usage.  It also contains a standard interrupt table that defines the HPET... which is what I'm interested in modifying.  ACPI is simply passed through from the BIOS to EFI at this point, I need to actually modify the contents of the ACPI table in order to inject the HPET interrupt description.

[bthomp]

You wouldn't happen to know how to possibly get in touch with David Elliott would you?  I'd like to poke his brain on this topic if possible. 

[bthomp]

UPDATE: I think I have the ACPI HPET injection working for my motherboard/chipset... technically though I'm not sure it's safe to have APIC data outside of the specified memory space so I could be in for some trouble.  Will need to thoroughly test stability at some point.

Despite injecting the HPET into the ACPI, I was still seeing frequent sleep/wake freezes with multiple cores active.  I need to do some tests to determine if the HPET is actually active and working and also check the registers controlling the HPET chip to make sure it is active and mapping to the expected memory address space.

I am also going to investigate a bit more into what the BIOS may be doing that is forcing both cores to C1 state (auto-sleep running) which I think is why they are sleeping and consequently not waking up until a later interrupt forces them to be active again.

Reference material for Dell Latitude D820:
http://www.intel.com/design/chipsets/datashts/307013.htm
http://www.intel.com/design/mobile/datashts/309219.htm


Note: I don't have access to Netkas' source changes for the boot loader, so it's lacking all of the nice GUID partition table and multi-boot to FAT32 partition features.  So no time frame yet on releasing any of this even if it does work...

[bthomp]

Good news and bad news...

The good news first:
I've enabled the HPET on my Dell Latitude D820 in the EFI boot loader and the patched ACPI data is being passed along through the EFI tables just fine.  I can tell that the HPET is active at bootloader time by probing the main counter and all seems to be good there.

The bad news:
sleep/wake still is being an issue even with the HPET being alive and well which means that my early assumption that Apple was using the HPET for driving interrupts to manage sleep/wake state of the CPU cores was not correct.  But at least with this patch I can work around the "Package 0 couldn't find HPET" issue.

Future work:
The next thing to do is to look into the CPU sleep state issue in more depth and see if there is anything that can be done in a kernel extension or boot loader to work around the Dell BIOS issue.

[bthomp]

I might be 1 step closer to getting this to work...
http://forums.blagblagblag.org/viewtopic.php?t=4380

That has the information I needed for registering the HPET to look like it is from an Apple motherboard (hopefully the ACPI Platform extension will pick it up properly now).  As a bonus the Device Id matches the Dell motherboard exactly so the HPET in my laptop should be compatible.

[nicolausvongrep]

Hi bthomp,
I'm following your progress with interest; I think it could be a solution even for my hp, same problem, more or less;I can get also dump from a mac pro of a friend, just tell me what you need in this case.
n

[bthomp]

I found a dump on the net... it turns out that I wasn't actually setting the modified ACPI table and so even though I got the HPET initialized and running it wasn't being exposed to the OS at all.  I am working on fixing it up atm and will hopefully have the HPET detected soon.  Cross your fingers...

[bthomp]

Yet another update... in debugging my injection code, I discovered that the HPET is already in the ACPI table (I'm a little surprised by this).

However, I do know that the HPET is in-fact not active by default on Dell Core 2 Duo laptops.  This can be fixed in the boot-loader easy enough and should also be something that can be fixed in a kernel extension (the more that can be done in a kernel extension rather than the boot-loader the better).

What I do not know at this point is if I need to set up the IRQs for routing interrupts from the HPET (documentation suggests that this be done by either the BIOS or OS).  It's possible that Darwin expects the BIOS to have already set up IRQ routes for some of the available timers and AppleIntelCPUPowerManagement is looking for an HPET timer that is not in use and is already assigned to an IRQ.  If that is the case, solving this issue might be easier or more difficult than I originally thought.

[bthomp]

Well, I now have code in place that starts the HPET, checks timers for IRQ capabilities, assigns IRQs to capable timers, verifies that the main counter is working, and verifies the HPET entry in the ACPI table.  At this point I'm not sure why the kernel refuses to find it.

The only thing I'm not doing is forcing the ACPI table to be exported using the v2.0c specification (I could be wrong but I think Dell's BIOS may only be exporting a v1 table).  Anyways, I think I need to start digging on the other end of the spectrum and try to determine how AppleIntelCPUPowerManagement is going about looking for the HPET and see if I can't use that information to determine why it can't find it.

The problem of the AppleIntelCPUPowerManagement kernel extension not getting an HPET timer is still unresolved and still very likely to be the cause of poor system performance when running with multiple cores.  Anyways, I'll probably take a break for a few days and perhaps some new idea will come to me.

[frantisheq]

nice  keep up the good work. not sure if this will work on XPS410 but if you'll need some testing just ask.

[bthomp]

Well, doing more reading and still getting a handle on the ACPI and HPET specifications.  It turns out that the AppleHPET kernel extension looks for an ACPI device "PNP0103" which is the Microsoft standard device uid for HPET devices.  My laptop isn't discovering this device (not listed by ioreg) and my suspicion as to why is that it is not registered in the ACPI namespace by the BIOS (ahhaaaa).

So, I now have another avenue to follow in resolving this.  Unfortunately this appears to be a little more difficult than simply mucking around with the hpet registers...