MAcBook Pro DMI info
Jan 31 08:40:41 elm ACPI: DMI System Vendor: Apple Inc. Jan 31 08:40:41 elm ACPI: DMI Product Name: MacBookPro3,1 Jan 31 08:40:41 elm ACPI: DMI Product Version: 1.0 Jan 31 08:40:41 elm ACPI: DMI Board Name: Mac-F4238BC8 Jan 31 08:40:41 elm ACPI: DMI BIOS Vendor: Apple Inc. Jan 31 08:40:41 elm ACPI: DMI BIOS Date: 09/26/07
Signature · 6 lines
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerQuoted 1 line · der flooh
Jan 31 08:40:41 elm ACPI: DMI System Vendor: Apple Inc.
Thanks for the dmidecode.
Looks like we should just match on the string "Apple", since they seem to have cut over from "Apple Computer, Inc." to "Apple Inc."
btw. if you can send me the output from acpidump, I'd like to look it over, since I've not see the MacBookPro3,1 version yet.
thanks,
-Len
Quoted 6 lines
Jan 31 08:40:41 elm ACPI: DMI Product Name: MacBookPro3,1 Jan 31 08:40:41 elm ACPI: DMI Product Version: 1.0 Jan 31 08:40:41 elm ACPI: DMI Board Name: Mac-F4238BC8 Jan 31 08:40:41 elm ACPI: DMI BIOS Vendor: Apple Inc. Jan 31 08:40:41 elm ACPI: DMI BIOS Date: 09/26/07
Len Brown
reviewerRe: MAcBook Pro DMI info - MacBookPro3,1
In reply to a message not in the archiveQuoted 3 lines
Quoted 3 lines · der flooh
Quoted 1 line
Jan 31 08:40:41 elm ACPI: DMI System Vendor: Apple Inc.
...
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Jan 31 08:40:41 elm ACPI: DMI Product Name: MacBookPro3,1 Jan 31 08:40:41 elm ACPI: DMI Product Version: 1.0 Jan 31 08:40:41 elm ACPI: DMI Board Name: Mac-F4238BC8 Jan 31 08:40:41 elm ACPI: DMI BIOS Vendor: Apple Inc. Jan 31 08:40:41 elm ACPI: DMI BIOS Date: 09/26/07
Thanks for the acpidump.
Apple has added new code BIOS to test OSYS.
But it looks like a NOP for Linux.
I also looks like the Apple BIOS programmers don't realize that Windows 2006 returns true for OSI(Windows 2001). But since they test OSYS only against 0x7D1 and the Darwin value, that bug isn't noticed yet.
cheers,
-Len
Method (PINI, 0, NotSerialized)
{
If (CondRefOf (_OSI, Local0))
{
If (_OSI ("Darwin"))
{
Store (0x2710, OSYS)
}
Else
{
If (_OSI ("Linux"))
{
Store (0x03E8, OSYS)
}
Else
{
If (_OSI ("Windows 2001"))
{
Store (0x07D1, OSYS)
}
Else
{
If (_OSI ("Windows 2001 SP1"))
{
Store (0x07D1, OSYS)
}
Else
{
If (_OSI ("Windows 2001 SP2"))
{
Store (0x07D2, OSYS)
}
Else
{
If (_OSI ("Windows 2006"))
{
Store (0x07D6, OSYS)
}
}
}
}
}
}
}
Else
{
Store (0x07D0, OSYS)
}
}Re: OSYS use
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (_CID, 0x010CD041)
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y1B)
})
Method (_STA, 0, NotSerialized)
{
If (LGreaterEqual (OSYS, 0x07D1))
{
If (HPAE)
{
Return (0x0F)
}
}
Else
{
If (HPAE)
{
# Linux will come here,
# but it doesn't matter, because we don't look at the GUI bits in _STA anyway... Return (0x0B)
}
}
Return (0x00)
}
...
# the test for Darwin: Method (OSDW, 0, NotSerialized)
{
If (LEqual (OSYS, 0x2710))
{
Return (0x01)
}
Else
{
Return (0x00)
}
}