undocumented SLIC structure in XSDT revealed
by Koen Blomme
>From a Microsoft Confidential .doc file, 'Whitepaper - OEM Activation 2.0 for Windows Vista Operating Systems', this undocumented matter:
Software Licensing ACPI_SLIC Table
Field
Byte Length
Byte Offset
Description
Signature
4
0
SLIC. Signature for the Software Licensing Description Table.
Length
4
4
Length, in bytes, of the entire SLIC. The length implies the number of Entry fields at the end of the table.
Revision
1
8
1
Checksum
1
9
Entire table must sum to zero.
OEMID
6
10
OEM name
OEM Table ID
8
16
Mobo/BIOS logical identifier
OEM Revision
4
24
OEM revision of SLIC table for supplied OEM Table ID.
Creator ID
4
28
Vendor ID of utility that created the table.
Creator Revision
4
32
Revision of utility that created the table.
Software Licensing Public Key structure
156
36
Public key binary data file (OA20PubKey.bin) created by OATool.exe.
Software Licensing Windows marker structure
182
192
Windows marker binary data file (OA20Marker.bin) created by OATool.exe.
Can be easily found Googling.
Greetings,
Koen
10 years, 2 months
ACPICA version 20110211 released
by Moore, Robert
11 February 2011. Summary of changes for version 20110211:
This release is available at www.acpica.org/downloads
1) ACPI CA Core Subsystem:
Added a mechanism to defer _REG methods for some early-installed handlers. Most user handlers should be installed before call to AcpiEnableSubsystem. However, Event handlers and region handlers should be installed after AcpiInitializeObjects. Override handlers for the "default" regions should be installed early, however. This change executes all _REG methods for the default regions (Memory/IO/PCI/DataTable) simultaneously to prevent any chicken/egg issues between them. ACPICA BZ 848.
Implemented an optimization for GPE detection. This optimization will simply ignore GPE registers that contain no enabled GPEs -- there is no need to read the register since this information is available internally. This becomes more important on machines with a large GPE space. ACPICA bugzilla 884. Lin Ming. Suggestion from Joe Liu.
Removed all use of the highly unreliable FADT revision field. The revision number in the FADT has been found to be completely unreliable and cannot be trusted. Only the actual table length can be used to infer the version. This change updates the ACPICA core and the disassembler so that both no longer even look at the FADT version and instead depend solely upon the FADT length.
Fix an unresolved name issue for the no-debug and no-error-message source generation cases. The _AcpiModuleName was left undefined in these cases, but it is actually needed as a parameter to some interfaces. Define _AcpiModuleName as a null string in these cases. ACPICA Bugzilla 888.
Split several large files (makefiles and project files updated)
utglobal.c -> utdecode.c
dbcomds.c -> dbmethod.c dbnames.c
dsopcode.c -> dsargs.c dscontrol.c
dsload.c -> dsload2.c
aslanalyze.c -> aslbtypes.c aslwalks.c
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Previous Release (VC 9.0):
Non-Debug Version: 89.7K Code, 23.7K Data, 113.4K Total
Debug Version: 163.9K Code, 67.5K Data, 231.4K Total
Current Release (VC 9.0):
Non-Debug Version: 89.7K Code, 23.7K Data, 113.4K Total
Debug Version: 163.9K Code, 67.5K Data, 231.4K Total
2) iASL Compiler/Disassembler and Tools:
iASL: Implemented the predefined macros __LINE__, __FILE__, and __DATE__. These are useful C-style macros with the standard definitions. ACPICA bugzilla 898.
iASL/DTC: Added support for integer expressions and labels. Support for full expressions for all integer fields in all ACPI tables. Support for labels in "generic" portions of tables such as UEFI. See the iASL reference manual.
Debugger: Added a command to display the status of global handlers. The "handlers" command will display op region, fixed event, and miscellaneous global handlers. installation status -- and for op regions, whether default or user-installed handler will be used.
iASL: Warn if reserved method incorrectly returns a value. Many predefined names are defined such that they do not return a value. If implemented as a method, issue a warning if such a name explicitly returns a value. ACPICA Bugzilla 855.
iASL: Added detection of GPE method name conflicts. Detects a conflict where there are two GPE methods of the form _Lxy and _Exy in the same scope. (For example, _L1D and _E1D in the same scope.) ACPICA bugzilla 848.
iASL/DTC: Fixed a couple input scanner issues with comments and line numbers. Comment remover could get confused and miss a comment ending. Fixed a problem with line counter maintenance.
iASL/DTC: Reduced the severity of some errors from fatal to error. There is no need to abort on simple errors within a field definition.
Debugger: Simplified the output of the help command. All help output now in a single screen, instead of help subcommands. ACPICA Bugzilla 897.
10 years, 3 months
Reserved method has too many arguments (_OSC requires 4)
by Thomas Renninger
Hi,
I have a laptop freezing early, acpi=off and noapic helps.
I wonder whether this could have to do with the broken _OSC method.
I cannot access the machine myself, eventually I can get more info
if needed, but the machine is freezing really early (after ACPI
initialization, somewhere around bringing up CPUs (possibly when
starting PCI init already?).
This is not the first time I see this message.
It would be great to get (from include/linux/kernel.h):
#define FW_BUG "[Firmware Bug]: "
#define FW_WARN "[Firmware Warn]: "
#define FW_INFO "[Firmware Info]: "
marked messages into ACPICA and blame the guys who are responsible
for that.
My other concern/question is: what exactly happens in such a case?
Will _OSC get invoked at all?
If yes, what will be the last argument, zero, -1?
Hmm, I doubt it has to do with the freeze, but it would still be
great if someone knowing these parts could comment what people
with such a BIOS could expect to happen.
Thanks,
Thomas
Method (_OSC, 5, NotSerialized)
{
Store (Arg3, Local0)
Multiply (Local0, 0x04, Local1)
Name (BUF1, Buffer (Local1) {})
Store (Arg4, BUF1)
Store (Zero, Local1)
Store (Zero, Local2)
While (Local0)
{
Multiply (Local1, 0x04, Local2)
CreateDWordField (BUF1, Local2, CAPB)
If (Arg2)
{
If (LEqual (Local1, Zero))
{
And (CAPB, 0xFFFFFFFC)
}
}
Increment (Local1)
Decrement (Local0)
}
Return (BUF1)
}
10 years, 3 months