site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, Thanks, -Dave _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com Although I realize Apple has stated that they have little interest in Darwin running on non-Apple hardware, the attached patch carefully modifies the in-kernel HPET initialization to first check to make sure a device exists at 00:1f.0 before reading the RCBA from it. This and another patch I am still working on allows xnu to be booted under VMware Fusion. I've also highlighted what I believe to be a bug in the code. Intel's documentation clearly states that bits 31:14 are valid. Furthermore, they state that the address is aligned on a 16-kb boundary. It's in section 10.1.27 of the ICH6 documentation on page 361. I cannot imagine that newer ICH have decreased the alignment requirements to 4- KB instead of 16-KB. Technically the code should probably also check the enable bit (bit 0) but in practice I can't imagine that any sane system would have the RCBA disabled. Since VMware doesn't emulate an LPC in the first place, I have no idea whether or not such a patch would be desirable and thus didn't include it. I hope this patch is well received. I am striving to make things work for me on my Mac with widely available virtualization programs without doing radical changes to xnu that may make the code unacceptable for Apple's primary purpose of making it run on bare Apple hardware. xnu-1228_hpet.patch