Jump to content

How to boost the OS X boot process...


1,027 posts in this topic

Recommended Posts

Please note that I don't have a system with ACPI 1.0 and thus I have to rely on your testing. Thanks for that btw.

Hi dutchhockeypro

 

I've tried the latest amendments twice, once with #define ACPI_10_SUPPORT set to 1 and once with it set to 0. During boot I don't see any different debug output compared to before and unfortunately both attempts result in the same KP.

I've got a photo if you want it, but I think the important part is:

AppleACPIPlatformExpert::start failed
panic(cpu 0 caller 0x55bfa5): "Unable to find driver for this platform: \"ACPI\".\n\"@/SourceCache/xnu/xnu-1504.9.17/iokit/IOPlatformExpert.cpp:1389
Debugger called: <panic>

 

I'll try to narrow down the piece of code responsible.

 

EDIT:

The code in /acpi/patcher.h doesn't get past:

	if (xsdt && xsdt->Length < 196 && VALID_ADDRESS(rsdp))
{

Link to comment
Share on other sites

Haven't looked at the source file, yet, but I can tell you that the "boot-kernelcache-adler32" property is set by boot.efi and thus it won't be there until we set it. No problem here, because I have that in place already (in my local tree).

 

mine have it too, since a while :D ,

 

if someone want to test (u need a least revolution rev634 ), go to fake_efi.c,

found:

if (chosenNode == 0)
{
	stop("Couldn't create /chosen node"); // Mimics boot.efi
}

 

and add this just under :

unsigned long adler32 = 0xXXXXXXXX; //please edit me (e.g 0x8602b51d)
DT__AddProperty(chosenNode, "boot-kernelcache-adler32", sizeof(unsigned long), &adler32);

 

Note: I did a grep -re "boot-kernelcache" but nothing shows up in either XNU and/or kextcache so I don't see the point of using it, again, since it won;t there anyway. Sorry.

 

"boot-kernelcache-adler32" is not used (of course), but if you replace kextcache_main.c by the one i have uploaded and recompile kext_tools, it will be used :D

i just hope apple will use this value one days in the same ways, b/c as you've said , boot.efi can set this value (unfortunately the original kext_tools seems to not use it for now)

Link to comment
Share on other sites

Please note that I don't have a system with ACPI 1.0 and thus I have to rely on your testing. Thanks for that btw.

 

Same as blackosx, tried 1 & 0 and my debug output remains as previous post. No boot unfortunately yet.

Link to comment
Share on other sites

Sorry. I made a mistake. Must change a few things. Make sure you have this:

#if ACPI_10_SUPPORT
#define	ADDRESS_WIDTH 4
#define	RSDP_LENGTH 20
#define	ACPI_TABLE_ALIAS "ACPI_10"
#define RXSDT_ADDRESS (uint32_t)rsdp->RsdtAddress
[color="#FF0000"]#define VALID_ADDRESS(rsdp, rsdt) ((uint32_t)rsdt != 0xffffffff)[/color]

typedef uint32_t ENTRIES;
#else
#define	ADDRESS_WIDTH 8
#define	RSDP_LENGTH 36
#define	ACPI_TABLE_ALIAS "ACPI_20"
#define RXSDT_ADDRESS (uint32_t)rsdp->XsdtAddress
[color="#FF0000"]#define VALID_ADDRESS(rsdp, xsdt) (((uint64_t)rsdp->XsdtAddress) < 0xffffffff)[/color]

typedef uint64_t ENTRIES;
#endif

in essentials.h and change use this:

VALID_ADDRESS(rsdp, xsdt)

instead of VALID_ADDRESS(rsdp) in patcher.h

 

The HP I use for testing has ACPI 3.0 and thus makes use of the second part (below the else) and at least that works.

 

No changes in debug for me using with these changes.

Link to comment
Share on other sites

Unfortunately it's the same debug and KP for me too.

And again the code doesn't get passed:

	if (xsdt && xsdt->Length < 196 && VALID_ADDRESS(rsdp, xsdt))
{

	printf("Arrived!");   // blackosx added

	bool needInjectedTable = false;

Off to bed now. I'll catch up in the morning.

Link to comment
Share on other sites

My... what have you done? as we have big progress! - Well done :)

 

Here's my report:

Debug Output:

post-331032-1294212068_thumb.jpg

 

RSDT (HEX):

52 53 44 54 50 00 00 00 01 b1 47 42 54 20 20 20 47 42 54 55 41 43 50 49 31 2e 30 42 47 42 54 55 01 01 01 01 c0 30 ee df c0 7f ee df 40 80 ee df 80 80 ee df c0 7e ee df 03 dc f1 ff 60 ed ee df f0 ee ee df 80 f0 ee df 10 f2 ee df a0 f3 ee df

 

RSDT (English):

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20101209-64 [Dec 10 2010]
* Copyright © 2000 - 2010 Intel Corporation
* 
* Disassembly of /Users/blackosx/Desktop/From Booted Revolution System/ACPI/RSDT.aml, Wed Jan  5 07:09:48 2011
*
* ACPI Data Table [RSDT]
*
* Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
*/

[000h 0000  4]                    Signature : "RSDT"    /* Root System Description Table */
[004h 0004  4]                 Table Length : 00000050
[008h 0008  1]                     Revision : 01
[009h 0009  1]                     Checksum : B1
[00Ah 0010  6]                       Oem ID : "GBT   "
[010h 0016  8]                 Oem Table ID : "GBTUACPI"
[018h 0024  4]                 Oem Revision : 42302E31
[01Ch 0028  4]              Asl Compiler ID : "GBTU"
[020h 0032  4]        Asl Compiler Revision : 01010101

[024h 0036  4]       ACPI Table Address   0 : DFEE30C0
[028h 0040  4]       ACPI Table Address   1 : DFEE7FC0
[02Ch 0044  4]       ACPI Table Address   2 : DFEE8040
[030h 0048  4]       ACPI Table Address   3 : DFEE8080
[034h 0052  4]       ACPI Table Address   4 : DFEE7EC0
[038h 0056  4]       ACPI Table Address   5 : FFF1DC03
[03Ch 0060  4]       ACPI Table Address   6 : DFEEED60
[040h 0064  4]       ACPI Table Address   7 : DFEEEEF0
[044h 0068  4]       ACPI Table Address   8 : DFEEF080
[048h 0072  4]       ACPI Table Address   9 : DFEEF210
[04Ch 0076  4]       ACPI Table Address  10 : DFEEF3A0

Raw Table Data

 0000: 52 53 44 54 50 00 00 00 01 B1 47 42 54 20 20 20  RSDTP.....GBT   
 0010: 47 42 54 55 41 43 50 49 31 2E 30 42 47 42 54 55  GBTUACPI1.0BGBTU
 0020: 01 01 01 01 C0 30 EE DF C0 7F EE DF 40 80 EE DF  .....0......@...
 0030: 80 80 EE DF C0 7E EE DF 03 DC F1 FF 60 ED EE DF  .....~......`...
 0040: F0 EE EE DF 80 F0 EE DF 10 F2 EE DF A0 F3 EE DF  ................

 

The RSDT table was taken from my system booted with Revolution.

Note: My DSDT located in USB/Extra/ACPI/ was not loaded.

 

 

EDIT: UPDATE ^_^

Update: Make sure to have this:

#if ACPI_10_SUPPORT
	// Faking ACPI 1.0 to see what happens.
	rsdp_mod->Revision = 0;

	rsdp_mod->RsdtAddress = (uint32_t) xsdt_mod;

	// You may need to add these too.
	// rsdp_mod->Signature[0] = 'X';
	// rsdp_mod->XsdtAddress = (uint32_t) xsdt_mod;

	rsdp_mod->Length = 36;

	rsdp_mod->Checksum = 0;
	rsdp_mod->ExtendedChecksum = 0;

#if DEBUG

In acpi/patcher.h when it passes the first check (if clause).

Now that works!!

 

Debug Output:

post-331032-1294213635_thumb.jpg

 

RSDT (HEX)

52 53 44 54 4c 00 00 00 01 e4 47 42 54 20 20 20 47 42 54 55 41 43 50 49 31 2e 30 42 47 42 54 55 01 01 01 01 00 c0 ec 00 c0 7f ee df 40 80 ee df 80 80 ee df c0 7e ee df 60 ed ee df 00 70 ec 00 80 f0 ee df 10 f2 ee df a0 f3 ee df

 

RSDT (English)

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20101209-64 [Dec 10 2010]
* Copyright © 2000 - 2010 Intel Corporation
* 
* Disassembly of /Users/blackosx/Desktop/untitled folder/ACPI/RSDT.aml, Wed Jan  5 07:46:04 2011
*
* ACPI Data Table [RSDT]
*
* Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
*/

[000h 0000  4]                    Signature : "RSDT"    /* Root System Description Table */
[004h 0004  4]                 Table Length : 0000004C
[008h 0008  1]                     Revision : 01
[009h 0009  1]                     Checksum : E4
[00Ah 0010  6]                       Oem ID : "GBT   "
[010h 0016  8]                 Oem Table ID : "GBTUACPI"
[018h 0024  4]                 Oem Revision : 42302E31
[01Ch 0028  4]              Asl Compiler ID : "GBTU"
[020h 0032  4]        Asl Compiler Revision : 01010101

[024h 0036  4]       ACPI Table Address   0 : 00ECC000
[028h 0040  4]       ACPI Table Address   1 : DFEE7FC0
[02Ch 0044  4]       ACPI Table Address   2 : DFEE8040
[030h 0048  4]       ACPI Table Address   3 : DFEE8080
[034h 0052  4]       ACPI Table Address   4 : DFEE7EC0
[038h 0056  4]       ACPI Table Address   5 : DFEEED60
[03Ch 0060  4]       ACPI Table Address   6 : 00EC7000
[040h 0064  4]       ACPI Table Address   7 : DFEEF080
[044h 0068  4]       ACPI Table Address   8 : DFEEF210
[048h 0072  4]       ACPI Table Address   9 : DFEEF3A0

Raw Table Data

 0000: 52 53 44 54 4C 00 00 00 01 E4 47 42 54 20 20 20  RSDTL.....GBT   
 0010: 47 42 54 55 41 43 50 49 31 2E 30 42 47 42 54 55  GBTUACPI1.0BGBTU
 0020: 01 01 01 01 00 C0 EC 00 C0 7F EE DF 40 80 EE DF  ............@...
 0030: 80 80 EE DF C0 7E EE DF 60 ED EE DF 00 70 EC 00  .....~..`....p..
 0040: 80 F0 EE DF 10 F2 EE DF A0 F3 EE DF              ............

 

DSDT is loaded and my GPU addition works

Ultra BINGO!

Great job dutchhockeypro.

 

Now DB1.. does it work for you?

 

EDIT2:

My video is working as I have it added in my /USB/Extra/ACPI/DSDT.aml. Removing it from my DSDT and relying on my SSDT table doesn't work just yet. But no big deal - that's something for me to work on.

Link to comment
Share on other sites

I can't compile last modifications... :(

 

SOLVED. Now i'll try a reboot

 

my RSDT:

52 53 44 54 3c 00 00 00 01 40 4e 76 69 64 69 61 4e 56 44 41 41 43 50 49 31 2e 30 42 4e 56 44 41 00 00 00 00 00 c0 e6 00 40 b1 ee cf 80 b1 ee cf 80 b0 ee cf 00 d0 e6 00 00 e0 e6 00

-----

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090730
*
* Disassembly of ./RSDT.aml, Wed Jan  5 14:00:42 2011
*
* ACPI Data Table [RSDT]
*
* Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
*/

[000h 0000  4]					Signature : "RSDT"	/* Root System Description Table */
[004h 0004  4]				 Table Length : 0000003C
[008h 0008  1]					 Revision : 01
[009h 0009  1]					 Checksum : 40
[00Ah 0010  6]					   Oem ID : "Nvidia"
[010h 0016  8]				 Oem Table ID : "NVDAACPI"
[018h 0024  4]				 Oem Revision : 42302E31
[01Ch 0028  4]			  Asl Compiler ID : "NVDA"
[020h 0032  4]		Asl Compiler Revision : 00000000

[024h 0036  4]	   ACPI Table Address   0 : 00E6C000
[028h 0040  4]	   ACPI Table Address   1 : CFEEB140
[02Ch 0044  4]	   ACPI Table Address   2 : CFEEB180
[030h 0048  4]	   ACPI Table Address   3 : CFEEB080
[034h 0052  4]	   ACPI Table Address   4 : 00E6D000
[038h 0056  4]	   ACPI Table Address   5 : 00E6E000

Raw Table Data

 0000: 52 53 44 54 3C 00 00 00 01 40 4E 76 69 64 69 61  RSDT<....@Nvidia
 0010: 4E 56 44 41 41 43 50 49 31 2E 30 42 4E 56 44 41  NVDAACPI1.0BNVDA
 0020: 00 00 00 00 00 C0 E6 00 40 B1 EE CF 80 B1 EE CF  ........@.......
 0030: 80 B0 EE CF 00 D0 E6 00 00 E0 E6 00			  ............

 

 

Link to comment
Share on other sites

Hi Scrax - have the latest changes allowed you to boot your system?

No I get stuck at

will exit setupACPI () it 10 seconds...

I need to reset the system, another thing is that at boot i have CMOS checksum error and bios resetted.

I have tryed without dsdt.aml, now i'll retry with it...

 

dump:

post-464373-1294234773_thumb.jpg

Link to comment
Share on other sites

Have you added the UUID of your OSX Volume to the kernel flags in your com.apple.Boot.plist?

I had to add it to mine before it worked.

rd=uuid boot-uuid=00000000-0000-0000-0000-00000000000000

yes, i did, in /Library/Preferences/SystemConfiguration/com.apple.Boot.plist where do you have it?

now i try with it in /Extra

but I didn't manage to add the debug output like you did...

Link to comment
Share on other sites

Is that why I don't see the "Factory RSDT" table output? We need that to help you.

 

p.s. You don't seem to have:

	DEBUG_DUMP("(rootUUID[0] == '\0') %s\n", (rootUUID[0] == '\0') ? "true" : "false");

initEFITree(rootUUID);

Add the first line there, and substitute DEBUG_DUMP() with printf() when you don't have the former.

 

Factory RSDT? uhm...

I've missed it when merging the pics :D

post-464373-1294239629_thumb.jpg

 

 

I've added the uuid debug, let's see...

Link to comment
Share on other sites

Sorry about disappearing earlier Scrax - but I had a customer visit me.

But in the mean time I see DHP has helped you out a little.

 

I've added the uuid debug, let's see...

It will be interesting to see what value it has, but if the rootvolume in your debug is the same as your OS X Volume then it might not help.

 

I'm pleased to see this much progress, but we're not there yet.

No problem. Just show me what you have in mind.

 

To All: Don't be surprised when you see a load call for: /System/Library/CoreServices/boot.efi in one of my next updates – dropping two more files and 2 KB – thanks to a certain person we all know :)

Thanks certain person we all know. Looking forward to the changes :(

Link to comment
Share on other sites

Can you please attach your copy of patcher.h so that I know where to continue?

Sure. It's the one you posted in post #316 with the additions from your post #318.

Here it is.

patcher.h.zip

And what happens when you use all/any of the following changes:

I won't be able to test anything until I return home in about 2 hours.

 

 

EDIT 1:

And what happens when you use all/any of the following changes:

rsdp_mod->Revision = 1;

Boots fine.

post-331032-1294255022_thumb.jpg

 

 

EDIT 2:

And what happens when you use all/any of the following changes:

xsdt_mod->Signature[0] = 'X';

Boots fine.

post-331032-1294255608_thumb.jpg

 

 

EDIT 3:

And what happens when you use all/any of the following changes:

strncpy(rsdp_mod->OEMID, "Apple ", 6);

Boots fine.

post-331032-1294256187_thumb.jpg

 

 

EDIT 4:

And what happens when you use all/any of the following changes:

strncpy(rsdp_mod->OEMTableID, "Apple00", 8);;

Couldn't do as OEMTableID isn't part of rsdp but xsdt? Can you confirm?

 

More to follow....

Link to comment
Share on other sites

To All: Don't be surprised when you see a load call for: /System/Library/CoreServices/boot.efi in one of my next updates – dropping two more files and 2 KB – thanks to a certain person we all know :D

 

Thank you certain person we all know... I think there's a great vibe in this thread, everyone wanting to help each other and no making other people wrong. Long may it continue. Good luck with the ACPI 1.0 issue, Scrax I hope you're up and running soon.

Link to comment
Share on other sites

Getting confused like me? I mean it looks like you changed rsdp_mod[0] instead of xsdt_mod[0] :)

Oh yeah.. Silly me - I'll re-do that a bit later along with xsdt_mod->OEMTableId

 

p.s. I noticed a unfamiliar table name (TAMG) in your dumps. What is that for table? A possible new target to drop?

I never found out what that did, but we can try dropping it.

Here's the contents.

TAMG.txt

 

I've got to disappear for an hour. I'll check back in later.

Link to comment
Share on other sites

No go for me yet.

 

Debug:DubugOutput.txt

 

RSDT

<58 53 44 54 5c 00 00 00 01 15 4d 53 49 5f 4e 42 4d 45 47 41 42 4f 4f 4b 04 20 22 06 4d 53 46 54 13 00 01 00 00 30 37 02 00 00 00 00 90 0e 61 7f 00 00 00 00 90 5c 61 7f 00 00 00 00 10 2c 61 7f 00 00 00 00 10 55 60 7f 00 00 00 00 10 8a 5e 7f 00 00 00 00 10 1a 61 7f 00 00 00 00>

 

IOREG

db1.ioreg.zip Just in case it helps.

 

EDIT

 

Just noticed a typo in my debug file. rsdp_mod->Reserved should be : OCo, if I disable dsdt loading this changes to RVE. Have tried with ACPI set at 0 & 1.

 

EDIT 2

 

Having seen blackosx & scrax dumps I see I'm not finding HPET, my dsdt fixes HPET so is the dsdt loading an issue for me?

 

ls -al on my USB SDCard Booter

drwxrwxr-x  14 db1   staff	   544  5 Jan 21:33 .
drwxrwxrwt@  4 root  admin	   136  5 Jan 22:34 ..
-rw-r--r--@  1 db1   staff	 12292  5 Jan 21:32 .DS_Store
drwx------   4 db1   staff	   136  2 Jan 17:07 .Spotlight-V100
drwxrwxrwt@  4 db1   staff	   136  2 Jan 17:07 .TemporaryItems
d-wx-wx-wt   3 db1   staff	   102  5 Jan 22:34 .Trashes
drwx------   5 db1   staff	   170  5 Jan 22:33 .fseventsd
drwxr-xr-x   5 root  staff	   170  5 Jan 21:15 Extra
drwxr-xr-x   4 db1   staff	   136 24 Dec 21:10 Library
drwxr-xr-x   4 db1   staff	   136 24 Dec 10:33 System
-rw-r--r--   1 db1   staff	 54304  5 Jan 21:33 boot
-rw-r--r--@  1 db1   staff  18693813  6 Nov 06:22 mach_kernel

Link to comment
Share on other sites

Yup. Here's how:

TAMG table successfully dropped:

post-331032-1294266328_thumb.jpg

It no longer appears in ioreg and the system seems fine without it.

 

But I have to confess I have struggled and failed to add the two other tests:

xsdt_mod->Signature[0] = 'X'; and strncpy(xsdt_mod->OEMTableId->OEMTableID, "Apple00", 8);

I couldn't work out where to add the code and when I did add it I had compilation errors. :D

I can run these tests but unfortunately you are going to have to show me how to add it (Sorry).

 

it still stucks here with cmos reset after reboot

Hi scrax..

In this post your debug read LoadACPITable: DSDT.AML not found

where in your latest debug I can't see that message.

 

Could your DSDT problem be a permissions issue? I don't know for sure but I have them set for my USB. I haven't tried this from an internal HDD - maybe you can try it on USB?

 

And your addition for debug of the rootUUID doesn't look right. Can you check that again in boot.c

	DEBUG_DUMP("(rootUUID == NULL) %s\n", (rootUUID == NULL) ? "true" : "false");

initEFITree(rootUUID);

 

EDIT 2

 

Having seen blackosx & scrax dumps I see I'm not finding HPET, my dsdt fixes HPET so is the dsdt loading an issue for me?

Hi DB1

It has to be that. My DSDT only loaded once I had added the code from this post. But I guess you've added that?

 

Also, I have different ownership for my folders - here's mine:

drwxrwxr-x   15 blackosx  staff	   578  5 Jan 22:19 .
drwxrwxrwt@  13 root	  admin	   442  5 Jan 22:22 ..
-rw-r--r--@   1 blackosx  staff	 12292  5 Jan 22:19 .DS_Store
drwx------	3 blackosx  staff	   102 24 Dec 07:16 .Spotlight-V100
drwxrwxrwt@   3 blackosx  staff	   102 24 Dec 07:19 .TemporaryItems
d-wx-wx-wt	3 blackosx  staff	   102  5 Jan 22:06 .Trashes
drwx------  129 blackosx  staff	  4386  5 Jan 22:19 .fseventsd
drwxr-xr-x	5 root	  wheel	   170 31 Dec 22:30 Extra
drwxr-xr-x	4 root	  admin	   136 23 Dec 21:17 Library
drwxr-xr-x	4 root	  wheel	   136 23 Dec 21:17 System
drwxr-xr-x	4 blackosx  staff	   136  5 Jan 08:15 Testing Files
-rw-r--r--	1 blackosx  staff	 51456  5 Jan 22:18 boot
-rw-r--r--@   1 root	  wheel  18693813 24 Dec 07:18 mach_kernel

 

in Extra, my ACPI folder has these settings:

drwxr-xr-x   3 root	  wheel   102  5 Jan 08:14 ACPI

 

In ACPI, my DSDT.aml has these settings:

-rw-r--r--@ 1 blackosx  staff  4398 22 Dec 07:54 dsdt.aml

Link to comment
Share on other sites

Hi DB1

It has to be that. My DSDT only loaded once I had added the code from this post. But I guess you've added that?

-rw-r--r--@ 1 blackosx  staff  4398 22 Dec 07:54 dsdt.aml

 

Yeah blackosx have the code added, and doubt the permissions are an issue. The same setup but with dsdt in Extra, also an mkext and a Chameleon current trunk boot file (with some patching) works for the sdcard booter and is the same setup on my EFI partition. Might have a play with the permissions though just to satisfy my curiosity.

 

EDIT

Permissions changed to:

Bootloader db1$ ls -al
total 36656
drwxrwxr-x  14 db1   staff	   544  5 Jan 21:33 .
drwxrwxrwt@  4 root  admin	   136  6 Jan 00:00 ..
-rw-r--r--@  1 db1   staff	 12292  5 Jan 23:51 .DS_Store
drwx------   4 db1   staff	   136  2 Jan 17:07 .Spotlight-V100
drwxrwxrwt@  4 db1   staff	   136  2 Jan 17:07 .TemporaryItems
d-wx-wx-wt   3 db1   staff	   102  6 Jan 00:00 .Trashes
drwx------   7 db1   staff	   238  5 Jan 23:56 .fseventsd
drwxr-xr-x   5 root  wheel	   170  5 Jan 21:15 Extra
drwxr-xr-x   4 root  admin	   136 24 Dec 21:10 Library
drwxr-xr-x   4 root  wheel	   136 24 Dec 10:33 System
-rw-r--r--   1 db1   staff	 54304  5 Jan 21:33 boot
-rw-r--r--@  1 root  wheel  18693813  6 Nov 06:22 mach_kernel

 

No boot so thats another possibility eliminated. I guess either a call to the quirky ACPI or a dsdt loading issue. DHP will work it out i'm sure. Last glass of red and off to bed. Might get 1/2 hour to play before work tomorrow morning, otherwise catch up tomorrow evening. Thinking positive, were making ground. TTFN

Link to comment
Share on other sites

Hi scrax..

In this post your debug read LoadACPITable: DSDT.AML not found

where in your latest debug I can't see that message.

that message went awy when I tryed with the dsdt in the correct place, but still nothing, now i'm thinking that injction from revolution isn't working. i'll try tomorrow with all the table I use now in /Extra/ACPI.

 

I'll also try to fix the uuid dump(done) and permissions...

 

thank's all for teh help. :unsure:

Link to comment
Share on other sites

No boot so thats another possibility eliminated. I guess either a call to the quirky ACPI or a dsdt loading issue. DHP will work it out i'm sure. Last glass of red and off to bed. Might get 1/2 hour to play before work tomorrow morning, otherwise catch up tomorrow evening. Thinking positive, were making ground. TTFN

Well it was worth a try. But I see DHP has come back with some more professional answers so a fix for you is coming up shortly I believe. And the ACPI v3.0 support in your debug... i had forgotten about that.

As for the last glass of red, well that's exactly what I was doing last night too :P

 

I received a tip (per text message) in the middle of the night...

Very handy :P

 

for reference, bit15 for me is set to 0:

					Use Platform Timer (V4) : 0

Link to comment
Share on other sites

 Share

×
×
  • Create New...