Update function AcpiUtStrtoul64:
Remove dead code.
Restructure to eliminate support for all numeric bases, only
base 16 and base 10 are needed.
Split off the base 10 and base 16 support into separate functions.
Added new exception for overflow during conversion.
Improved error detection and handling.
The MLC (Module Level Code) is an ACPICA terminology describing the AML
code out of any control method, its support is an indication of the
interpreter behavior during the table loading.
The original implementation of MLC in ACPICA had several issues:
1. Out of any control method, besides of the object creating opcodes, only
the code blocks wrapped by "If/Else/While" opcodes were supported.
2. The supported MLC code blocks were executed after loading the table
rather than being executed right in place.
============================================================
The demo of this order issue is as follows:
Name (OBJ1, 1)
If (CND1 == 1)
{
Name (OBJ2, 2)
}
Name (OBJ3, 3)
The original MLC support created OBJ2 after OBJ3's creation.
============================================================
Other than these limitations, MLC support in ACPICA looks correct. And
supporting this should be easy/natural for ACPICA, but enabling of this was
blocked by some ACPICA internal and OSPM specific initialization order
issues we've fixed recently. The wrong support started from the following
false bug fixing commit:
Commit: 80d7951177
Subject: Add support for module-level executable AML code.
We can confirm Windows interpreter behavior via reverse engineering means.
It can be proven that not only If/Else/While wrapped code blocks, all
opcodes can be executed at the module level, including operation region
accesses. And it can be proven that the MLC should be executed right in
place, not in such a deferred way executed after loading the table.
And the above facts indeed reflect the spec words around ACPI definition
block tables (DSDT/SSDT/...), the entire table and the Scope object is
defined by the AML specification in BNF style as:
AMLCode := DefBlockHeader TermList
DefScope := ScopeOp PkgLength NameString TermList
The bodies of the scope opening terms (AMLCode/Scope) are all TermList,
thus the table loading should be no difference than the control method
evaluations as the body of the Method is also defined by the AML
specification as TermList:
DefMethod := MethodOp PkgLength NameString MethodFlags TermList
The only difference is: after evaluating control method, created named
objects may be freed due to no reference, while named objects created by
the table loading should only be freed after unloading the table.
So this patch follows the spec and the de-facto standard behavior, enables
the new grammar (TermList) for the table loading.
By doing so, beyond the fixes to the above issues, we can see additional
differences comparing to the old grammar based table loading:
1. Originally, beyond the scope opening terms (AMLCode/Scope),
If/Else/While wrapped code blocks under the scope creating terms
(Device/PowerResource/Processor/ThermalZone) are also supported as
deferred MLC, which violates the spec defined grammar where ObjectList
is enforced. With MLC support improved as non-deferred, the interpreter
parses such scope creating terms as TermList rather ObjectList like the
scope opening terms.
After probing the Windows behavior and proving that it also parses these
terms as TermList, we submitted an ECR (Engineering Change Request) to
the ASWG (ACPI Specification Working Group) to clarify this. The ECR is
titled as "ASL Grammar Clarification for Executable AML Opcodes" and has
been accepted by the ASWG. The new grammar will appear in ACPI
specification 6.2.
2. Originally, Buffer/Package/OperationRegion/CreateXXXField/BankField
arguments are evaluated in a deferred way after loading the table. With
MLC support improved, they are also parsed right in place during the
table loading.
This is also Windows compliant and the only difference is the removal
of the debugging messages implemented before AcpiDsExecuteArguments(),
see Link 1 for the details. A previous commit should have ensured that
AcpiCheckAddressRange() won't regress.
Note that enabling this feature may cause regressions due to long term
Linux ACPI support on top of the wrong grammar. So this patch also prepares
a global option to be used to roll back to the old grammar during the
period between a regression is reported and the regression is
root-cause-fixed. Lv Zheng.
Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Operation regions created by MLC were not tracked by
AcpiCheckAddressRange(), this patch fixes this issue. ACPICA BZ 1279. Fixed
by Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The new MLC approach invokes MLC per-table basis. But the dynamic loading
support of this is incorrect because of the lock order:
AcpiNsEvaluate
AcpiExEnterIntperter
AcpiNsLoadTable (triggered by Load opcode)
AcpiNsExecModuleCodeList
AcpiExEnterIntperter
The regression is introduced by the following commit:
Commit: 071eff738c
Subject: Add per-table execution of module-level code, early region handlers
This patch fixes this regression by unlocking the interpreter lock before
invoking MLC. However the unlocking is done to the AcpiNsLoadTable(), in
which, the interpreter lock should be locked by AcpiNsParseTable() but
wasn't. Reported by Mika Westerberg. Fixed by Lv Zheng.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Linux uses asmlinkage and sparse macros to mark function symbols. This
leads to the divergences between the Linux and the ACPICA.
This patch ports such declarators back to ACPICA. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch adds necessary build files for EDK2 environment to build ACPICA
tools.
The command steps of building edk2 binaries are (if you are using gcc4.7):
# cd edk2
# . ./edksetup.sh
# ln -s <path to acpica> AcpiPkg
# build -p AcpiPkg/AcpiPkg.dsc -t GCC47 -a X64 -a IA32
Note the above test was done in Linux, and the Windows hasn't been tested
when this patch is generated. For building edk2 binaries in the MSVC
environment, you need to modify acpidump.inf/acpiexec.inf, adding necessary
options when they cannot pass the build in the following configure items:
MSFT:*_*_IA32_CC_FLAGS/MSFT:*_*_X64_CC_FLAGS. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch renames the EFI stuffs to ACPI_EFI stuffs so that there won't be
namespace conflicts when this code is ported to the different EFI
development environment.
No functional changes. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This mechanism requires sscanf to be implemented for almost no
significant benefit for EFI environment, so disables it. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch implements table OSLs for acpiexec in EFI environment:
1. Adds AcpiOsTableOverride() to use acpiexec loaded xSDT tables.
2. Adds a stub AcpiOsPhysicalTableOverride().
Note that currently we only support emulator mode acpiexec in EFI
environment, thus all table overrides, RSDP location are implemented in the
same way as its windows/unix versions. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch adds AcpiOsStall() and AcpiOsSleep() support.
Currently we do not support asynchronous polling of key stroke and timer,
so AcpiOsSleep() is simply an invocation of AcpiOsStall(). Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch adds AcpiOsGetTimer() support for EFI environment.
Note that currently we don't support timezone. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch only adds stub supports for hardware access OSLs to make EFI
ported application running.
This patch adds the following OSLs for efi:
1. AcpiOsInstallInterruptHandler()/RemoveInterruptHandler().
2. AcpiOsReadPort()/AcpiOsWritePort().
3. AcpiOsReadMemory()/AcpiOsWriteMemory().
3. AcpiOsReadPciConfigration()/AcpiOsWritePciConfiguration().
Currently we will not support real hardware accesses in the EFI
environment, so they can stay stubs. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch only adds stub supports for multi-threading OSLs to make
EFI ported application running.
In order to fully support acpiexec in a non multi-threading environment,
ACPICA core itself need to be upgraded to contain full asynchrnous support.
Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch implements putchar()/getchar() invoked in AcpiOsGetLine() to
improve the portability.
No functional changes for Unix/Windows environments. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch implements the native string APIs of strpbrk()/strtok().
Unit tests have been done to these two functions in unix environment and no
bugs have been found. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch added two new Clibrary functions: fgetc()/fputc() for EFI
environment, they are implemented using fread()/fwrite().
Note in this patch, stdin is simply defined as NULL for EFI
environment. Its EFI support should be implemented by further patches.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
There is an issue for usage macros, if an command line option changed
AcpiGbl_DebugFile, then the follow up usage may errornously dumped to the
debug file.
This is just a bug in theory, because currently AcpiGbl_DebugFile can only
be modified by acpibin and acpiexec. Currently this will not trigger such
issue because:
1. For acpibin, AcpiGbl_DebugFile will be modified by "-t" option and the
program exit after processing this option without dumping help message
or other error options.
2. For acpiexec, AcpiGbl_DebugFile will only be modified by the open
command, which happens after parsing the command line options, so no
help message will be dumped into the debug file.
But maintaining this logic is difficult, so this patch modifies
AcpiOsPrintf() into printf() for usage macros so that the help messages are
ensured to be dumped to the stdout. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch follows new ACPICA design, eliminates old portable OSLs, and
implements fopen/fread/fwrite/fclose/fseek/ftell for GNU EFI
environment. This patch also eliminates AcpiLogError(), convering them
into fprintf(stderr)/perror(). Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch adds sprintf()/snprintf()/vsnprintf()/printf()/vfprintf()
support for OSPMs that have ACPI_USE_SYSTEM_CLIBRARY defined but do not
have ACPI_USE_STANDARD_HEADERS defined.
This patch also converts the entire EFI porting layer to use the standard
system Clibrary and implements GNU EFI specific standard Clibrary stdio
operations.
-fno-builtin is required for GCC to avoid optimization performed printf().
This optimization cannot be automatically disabled by specifying -nostdlib.
Please refer to the Link 1 for the details.
-iwithprefix include is required to include <stdarg.h> which contains
compiler specific implementation of vargs. It is unclear why there is the
vargs macros defined for OSPMs that do not have ACPI_USE_SYSTEM_CLIBRARY
defined. After applying this patch, this special vargs implementation
should also get deleted.
Standard C header files shouldn't be included here and there throughout the
entire ACPICA code base. This patch corrects some of them. Lv Zheng.
Link 1: http://www.ciselant.de/projects/gcc_printf/gcc_printf.html
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
We now safe to enable USE_NATIVE_ALLOCATE_ZEROED for all applications as
there are implementations in oswinxf.c, osunixxf.c and osefixf.c. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The AcpiGbl_DebugTimeout which is used by acpiexec -et option now is only
implemented in oswinxf.c and used for WIN32 builds. This makes it very
difficult to remember to add this variable to other os specificy layer
files in order to link. This patch makes it a global option so that it can
always be linked. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
EFI environment doesn't support any table customization mechanism, and
acpidump defaults to use "-c on", it then is a problem that in UEFI
environment, user can obtain nothing by just type "acpidump.efi". This
patch removes Gbl_DumpCustomizedTables awaness to fix this issue. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Robert Moore