The SSDT Serial port fixup library provides
interfaces to generate a SSDT Serial port table
based on the serial port information.
Update the DBG2 Generator to use the SSDT serial
port fixup library to build a serial port definition
block for the DBG2 serial port and install the
SSDT table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
According to Arm Server Base Boot Requirements,
Platform Design Document version 1.2 revision D,
September 2, 2019, section '4.2.1.8 SPCR'; the
SPCR console device must be included in the DSDT.
The SSDT Serial port fixup library provides
interfaces to generate a SSDT Serial port table
based on the serial port information.
Update the SPCR Generator to use the SSDT serial
port fixup library to build a serial port definition
block corresponding to the SPCR serial port and
install the SSDT table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Most platforms have several serial ports. These serial ports
are described to an operating system using definition block
tables.
The SSDT Serial Port Table Generator uses the Configuration
Manager protocol to obtain information for the Serial Ports
on the platform. The serial ports are described using the
CM_ARM_SERIAL_PORT_INFO structure. The EArmObjSerialPortInfo
ID is used to represent a standard serial port.
The SSDT Serial port fixup library provides interfaces to
generate a SSDT Serial port table based on the serial port
information. The SSDT Serial Port Table Generator uses the
SSDT serial port fixup library to build serial port
definition blocks and installs the SSDT tables.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
According to Arm Server Base Boot Requirements,
Platform Design Document version 1.2 revision D,
September 2, 2019, section '4.2.1.8 SPCR'; The
SPCR console device must be included in the DSDT.
Additionally, it is often desirable to describe the
serial ports available on a platform so that they
are available for use by a rich OS.
To facilitate the description of serial ports on a
platform a common SSDT Serial Port Fixup library is
introduced. It provides interfaces to build a SSDT
serial port definition block table based on the
serial port information.
The SSDT Serial Port Fixup library is used by the
SPCR, DBG2 and SSDT Serial Port generator to describe
the serial port information in a definition block.
+------------+ +------------+ +------------+
| SPCR Gen | | DBG2 Gen | | SERIAL Gen |
+------------+ +------------+ +------------+
+----------------------------------+
| SSDT Serial Port Fixup library |
+----------------------------------+
The SSDT Serial Port Fixup library:
- Parses the SSDT Serial Port template using the
AmlLib library to generate an AML tree.
- Updates the _UID, _HID and _CID values.
- Fixes up the Serial port base address, length
and the interrupt number in the _CRS descriptor.
- Fixes up the serial-port name.
- Serialises the AML Tree to a buffer containing
the definition block data.
The definition block data is then installed by the
corresponding table generator.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AsciiFromHex is a function converts a hex number to an
ASCII character. This function is used across multiple
generators, so add it to the TableHelperLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
ACPI Definition blocks are implemented using AML which has
a complex grammar making run-time generation of definition
blocks difficult. Dynamic AML is a feature of Dynamic Tables
framework that provides a solution for dynamic generation of
ACPI Definition block tables.
Since, AML bytecode represents complex AML grammar, an AmlLib
library is introduced to assist parsing and traversing of the
AML bytecode at run-time.
The AmlLib library parses a definition block and represents it
as an AML tree. The AML objects, methods and data are represented
as tree nodes. Since the AML data is represented as tree nodes,
it is possible to traverse the tree, locate a node and modify the
node data. The tree can then be serialized to a buffer (that
represents the definition block). This definition block containing
the fixed-up AML code can then be installed as an ACPI Definition
Block table.
Dynamic AML introduces the following techniques:
* AML Fixup
* AML Codegen
* AML Fixup + Codegen
AML Fixup is a technique that involves compiling an ASL template
file to generate AML bytecode. This template AML bytecode can be
parsed at run-time and a fixup code can update the required fields
in the AML template.
AML Codegen employs generating small segments of AML code.
AmlLib provides a rich set of APIs to operate on AML data for AML
Fixup and Codegen.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AmlLib library implements an AML parser, AML tree interface,
serialiser, code generator and other interfaces to generate
Definition Block tables.
The AmlLib APIs are a collection of interfaces that enable
parsing, iterating, modifying, adding, and serialising AML
data to generate a Definition Block table.
The AmlLib APIs are declared in Include\AmlLib\AmlLib.h
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Core interface APIs are internal APIs of the
AmlLib library. These APIs can be used to:
- Create/Delete/Clone an AML tree/node
- Get/update Fixed and Variable arguments
- Serialize an AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Codegen is a Dynamic AML technique that facilitates
generation of small segments of AML code. The AML code
generated using AML Codegen is represented as nodes in
the AML Tree.
AML Resource Data Codegen implements interfaces required
for generating Resource Data elements that can be attached
to an AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Codegen is a Dynamic AML technique that facilitates
generation of small segments of AML code. The AML code
generated using AML Codegen is represented as nodes in
the AML Tree.
Some examples where AML Codegen can be used are:
- AML Codegen APIs can be used to generate a simple
AML tree.
- An AML template can be parsed to create an AML
tree. This AML Tree can be searched to locate a
node that needs updating. The AML Codegen APIs
can be used to attach new AML nodes.
- A combination of AML Fixup and AML Codegen can
be used to generate an AML tree.
The AML tree can then be serialised as a Definition
Block table.
Following AML Codegen APIs are implemented:
- AmlCodeGenDefinitionBlock()
- AmlCodeGenScope()
- AmlCodeGenNameString()
- AmlCodeGenNameInteger()
- AmlCodeGenDevice()
These AML Codegen APIs in combination with AML Resource
Data Codegen APIs can be used to generate a simple AML
tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML language allows defining field lists in a Definition
Block. Although Dynamic AML does not provide interfaces to
modify Field Lists; an AML template code may contain Field
lists and the AML parser must be capable of parsing and
representing the Field lists in the AML tree.
The AML parser creates an Object node that represents the
'Field Node'. The AML Field list parser creates an object
node for each field element parsed in the AML byte stream,
and adds them to the variable list of arguments of the
'Field Node'.
Nodes that can have a field list are referred as 'Field
nodes'. They have the AML_HAS_FIELD_LIST attribute set in
the AML encoding.
According to the ACPI 6.3 specification, s20.2.5.2 "Named
Objects Encoding", field elements can be:
- NamedField := NameSeg PkgLength;
- ReservedField := 0x00 PkgLength;
- AccessField := 0x01 AccessType AccessAttrib;
- ConnectField := <0x02 NameString> | <0x02 BufferData>;
- ExtendedAccessField := 0x03 AccessType ExtendedAccessAttrib
AccessLength.
A small set of opcodes describes the field elements. They are
referred as field opcodes. An AML_BYTE_ENCODING table has been
created for field OpCodes.
Field elements:
- don't have a SubOpCode;
- have at most 3 fixed arguments (as opposed to 6 for standard
AML objects);
- don't have a variable list of arguments;
- only the NamedField field element is part of the AML namespace.
ConnectField's BufferData is a buffer node containing a single
resource data element.
NamedField field elements do not have an AML OpCode. NameSeg
starts with a Char type and can thus be differentiated from the
Opcodes for other fields.
A pseudo OpCode has been created to simplify the parser.
Following is a representation of a field node in an AML tree:
(FieldNode)
\
|- [0][1][3] # Fixed Arguments
|- {(FldEl0)->(FldEl1)->...)} # Variable Arguments
Where FldEl[n] is one of NamedField, ReservedField, AccessField,
ConnectField, ExtendedAccessField.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML language allows a Definition Block to implement
methods that an Operating System can invoke at runtime.
Although Dynamic AML does not provide interfaces to
modify AML methods; an AML template code may contain
methods and/or method invocations.
Method definitions have an opcode defined in the AML
encoding and can be easily parsed. However, the language
does not define an opcode for method invocation. Method
invocations are represented as a NameString followed by
the arguments to the method. This poses a significant
challenge for the AML parser as it has to determine if
a NameString appearing in the AML byte stream is a method
invocation and if it is a method invocation, then how
many arguments follow.
This also means the Method definition must occur prior to
the method invocation in the AML byte stream. This is a
hard requirement for the AML parser.
The AML method parser maintains a NameSpaceRefList that
keeps a track of every namespace node and its raw AML
absolute path. The AmlIsMethodInvocation() searches the
NameSpaceRefList to determine if a NameString matches
a Method definition.
A pseudo opcode has been defined in the AML encoding to
represent the Method invocation in the AML tree.
The AML encoding for method invocations in the ACPI
specification 6.3 is:
MethodInvocation := NameString TermArgList
The AmlLib library redefines this as:
MethodInvocation := MethodInvocationOp NameString
ArgumentCount TermArgList
ArgumentCount := ByteData
Where MethodInvocationOp is the pseudo opcode and
ArgumentCount is the number of arguments passed to
the method.
NOTE:
The AmlLib library's definition for a method
invocation only applies to the representation
of method invocation node in the AML tree.
When computing the size of a tree or serialising
it, the additional data is not taken into account
i.e. the MethodInvocationOp and the ArgumentCount
are stripped before serialising.
Method invocation nodes have the AML_METHOD_INVOVATION
attribute set in the AmlLib library's representation of
the AML encoding.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Resource data are defined in the ACPI 6.3 specification,
s6.4 "Resource Data Types for ACPI". They can be created
using the ASL ResourceTemplate () statement, cf s19.3.3
"ASL Resource Templates".
Resource data can be of the small or large type and are
defined by their encoding. The resource data is stored
in the Bytelist of a BufferOp node. The Bytelist of a
BufferOp node is represented by an AML Data node in
the AML tree.
The resource data parser, examines the Bytelist (Data
node buffer) to detect the presence of resource data.
If the Bytelist data matches the encoding for resource
data types, the resource data parser fragments the
Bytelist containing the resource data buffer into
resource data elements represented as individual Data
nodes and stores them in the variable arguments list
of the BufferOp object nodes.
Example: ASL code and the corresponding AML tree
representation for the resource data.
ASL Code
--------
Name (_CRS, ResourceTemplate() {
QWordMemory (...)
Interrupt (...)
}
AML Tree
--------
(NameOp)
\
|-[_CRS]-[BufferOp] # Fixed Arguments
|-{NULL} \ # Variable Argument
\ list
|-[BuffSize] # Fixed Arguments
|-{(Rd1)->(Rd2)->(EndTag)} # Variable Argument
list
Where:
Rd1 - QWordMemory resource data element.
Rd2 - Interrupt resource data element.
EndTag - Resource data end tag.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Resource data are defined in the ACPI 6.3 specification,
s6.4 "Resource Data Types for ACPI". They can be created
using the ASL ResourceTemplate () statement, cf s19.3.3
"ASL Resource Templates".
Resource data can be of the small or large type and are
defined by their encoding. The resource data is stored
in the Bytelist of a BufferOp node. To simplify
operations on resource data, the resource data parser
examines the Bytelist to detect the presence of resource
data. If the data matches the encoding of resource
data type(s), the parser fragments the resource data
buffer into resource data elements (data nodes) and
stores them in the variable arguments list of the
BufferOp node.
The resource data helper provides functions and macros
to assist operations on resource data elements.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Both ASL and AML are declarative language. The ASL code
is compiled to AML bytecode. The AML bytecode is processed
by the ACPI AML interpreter that runs as part of an OS.
AML has a complex encoding making dynamic generation of
Definition Block tables difficult.
Dynamic AML generation involves techniques like AML Fixup
and AML Codegen, both requiring parsing of AML bytecode.
The AML parser is a module that parses an AML byte stream
and represents it as an AML tree. Representing the AML
bytecode as an AML tree is key to reducing the complexity
and enabling Dynamic AML generation.
In an AML Tree each AML statement (that also corresponds
to an ASL statement) is represented as an 'Object Node'.
Each Object Node has an OpCode and up to 6 Fixed Arguments
followed by a list of Variable Arguments.
(ObjectNode)
\
|- [0][1][2][3][4][5] # Fixed Arguments
|- {(VarArg1)->(VarArg2)->...N} # Variable Arguments
A Fixed Argument or Variable Argument can be either an
Object Node or a Data Node.
A 'Data Node' consists of a data buffer.
A 'Root Node' is a special type of Object Node that does
not have an Opcode or Fixed Arguments. It only has a list
of Variable Arguments. The Root Node is at the top of the
AML tree and contains the Definition Block Header.
The AML parser uses the 'AML Encoding' to parse an AML byte
stream and represents it as an AML Tree. Representing in the
form of an AML tree simplifies modification, addition and
removal of the tree nodes. The modified tree can then be
serialised to a buffer representing a Definition Block table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML is a declarative language that is processed by the
ACPI AML interpreter. The ACPI AML interpreter will
compile the set of declarations into the ACPI Namespace
at definition block load time.
The hardware information described in AML is effectively
mapped in the ACPI Namespace. The AML ACPI namespace
interface implement the functionality to search the ACPI
Namespace. Example: The AmlFindNode() can be used to locate
a device node in the ACPI namespace using an ASL path as
the search input.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML debug print functions enable logging
of the operations on the AML tree and the data
output. The debug logging functionality is
enabled for debug builds when the DEBUG_INFO
or DEBUG_VERBOSE mask is enabled in the PCD
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML Fixup and AML Codegen facilitate dynamic generation
of Definition Block tables. The AML byte stream that is
generated is represented in an AML tree. Once the AML
table generation is completed, the AML tree needs to be
serialised for installing as an ACPI table.
The AML serialise interface implements the functionality
to iterate the nodes in the AML tree, collating the AML
bytecode, computing the checksum and writing the AML byte
stream to a buffer that represents the Definition Block
table.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Co-authored-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Dynamic AML involves parsing/packing of AML opcode and
data into AML byte streams. The AML stream interface
provides safe buffer management as well as supports
forward and reverse streams. It provides functions to
create, read, write, clone and compare AML streams.
Co-authored-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Dynamic AML requires encoding/decoding and conversion of
AML and ASL strings. A collection of helper functions
have been provided for internal use in the AmlLib Library.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML utility interfaces are a collection of helper functions
that assist in computing the checksum, size and to propagate the
node information as a result of addition or update of AML nodes.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
It is often desirable to clone an AML branch/tree
or an AML node. An example of could be to clone
an AML template before fixup so that the original
AML template remains unmodified. Another example
would be replicating a device branch in the AML
tree and fixing up the device information.
To facilitate such scenarios the AmlLib library
provides functions that can be used to clone an
AML branch/tree or an AML node.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree iterator provides interfaces to traverse the nodes
in the AML tree. The iterator can traverse the AML tree nodes in
the following order:
- Linear progression: Iterate following the AML byte stream
order (depth first).
- Branch progression: Iterate following the AML byte stream
order (depth first), but stop iterating
at the end of the branch.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree traversal provides interfaces to traverse the
nodes in the AML tree.
It provides interfaces to traverse the AML tree in the
following order:
- Traverse sibling nodes.
(Node) /-i # Child of fixed argument b
\ /
|- [a][b][c][d] # Fixed Arguments
|- {(e)->(f)->(g)} # Variable Arguments
\
\-h # Child of variable argument e
Traversal Order:
- AmlGetNextSibling() : a, b, c, d, e, f, g, NULL
- AmlGetPreviousSibling(): g, f, e, d, c, b, a, NULL
- Iterate depth-first path (follow AML byte stream).
(Node) /-i # Child of fixed argument b
\ /
|- [a][b][c][d] # Fixed Arguments
|- {(e)->(f)->(g)} # Variable Arguments
\
\-h # Child of variable argument e
Traversal Order:
- AmlGetNextNode(): a, b, i, c, d, e, h, f, g, NULL
- AmlGetPreviousNode() g, f, h, e, d, c, i, b, a, NULL
Note: The branch i and h will be traversed if it has
any children.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree enumerator interface allows enumeration of the
nodes in the AML tree. The enumerator interface can be useful
to search, serialise, print etc. the nodes in the AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The AML tree is composite and has the following node types:
- Root node.
- Object node.
- Data node.
These nodes are part of the Fixed Arguments or the Variable
arguments list in the AML tree.
The AML tree interface provides functions to manage the fixed
and the variable argument nodes in the AML tree.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
AML has a complex grammar, and this makes runtime modifications
on an AML byte stream difficult. A solution is to parse the AML
bytecode and represent it in a tree data structure, henceforth
called the AML tree.
The AML tree is composite in the sense it has the following node
types:
- A 'Root node' that represents the root of the AML tree.
- An 'Object node' that contains the OP Code (AML Encoding).
- A 'Data node' that contains a data buffer.
The Root node contains the Definition block header (ACPI header)
and a Variable Argument list.
The Object node is composed of an array of Fixed Arguments and
a Variable Argument list.
Fixed arguments can be either Object Nodes or Data nodes. Their
placement (index) in the Fixed Argument array is defined by the
AML encoding of the enclosing Object Node.
Variable arguments can be Object nodes or Data nodes.
Following is a depiction of a typical AML tree:
(/) # Root Node
\
|-{(N1)->...} # Variable Argument list, N1 is
\ # an Object Node
\ /-i # Child of fixed argument b
\ /
|- [a][b][c][d] # Fixed Arguments
|- {(e)->(f)->(g)} # Variable Arguments
\
\-h # Child of variable argument e
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
ASL is a source language for defining ACPI objects including
writing ACPI control methods. An ASL file is compiled using
an ASL compiler tool to generate ACPI Machine Language (AML).
This AML bytecode is processed by the ACPI AML interpreter
that runs as part of an Operating System (OS).
Both ASL and AML are declarative languages. Although they
are closely related they are different languages.
ASL statements declare objects. Each object has three parts,
two of which can be NULL:
Object := ObjectType FixedList VariableList
The AML grammar defines corresponding encodings that makes
up the AML byte stream.
This patch introduces the AML grammar definitions used by
AmlLib for encoding/decoding AML byte streams.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Dynamic AML is a solution to generate Definition Block tables
at runtime. Dynamic AML provides the following techniques for
generating AML tables.
- AML Fixup
- AML Codegen
- AML Fixup + Codegen
AML fixup involves patching small sections of a template AML
code at runtime, while AML Codegen provides APIs to generate
small sections of AML code at runtime. A combination of
Fixup and Codegen can also be used.
AML has a complex grammar. To simplify the generation of
AML tables, Dynamic AML introduces AmlLib that provides a
rich set of APIs for parsing, traversing, fixup, codegen
and serialisation of AML byte code.
This patch introduces the definitions used by AmlLib.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The TianoCore EDKII project has introduced a Core CI infrastructure
using TianoCore EDKII Tools PIP modules:
* https://pypi.org/project/edk2-pytool-library/
* https://pypi.org/project/edk2-pytool-extensions/
More information on configuring the environment and running the
builds can be found in edk2\.pytool\Readme.md
This patch fixes the issues reported by the CI system mainly around
fixing typo errors and package dec and dsc files. A subsequent patch
enables the CI builds for the DynamicTablesPkg.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
On enabling the /analyse option the VS2017 compiler
reports: warning C6001: Using uninitialized memory.
This warning is reported for the Status variable in
AddGenericInitiatorAffinity() as it is not initialised
to a default value. This condition is only valid if
GenInitAffCount is equal to 0. Since GenInitAffCount
is already checked in BuildSratTable() this condition
can never happen.
The value of the Status variable is returned in
failure cases from appropriate locations in
AddGenericInitiatorAffinity(). The only case
where Status value is being used un-initialised
is the return statement at the end of
AddGenericInitiatorAffinity().
Therefore, to fix this issue EFI_SUCCESS can be
safely returned instead of returning the Status
variable at the end of the function.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
VS2017 reports 'warning C4028: formal parameter 2 different
from declaration' for the library constructor and destructor
interfaces for the SRAT Generator modules.
Remove the CONST qualifier for the ImageHandle and the
SystemTable pointer in the library constructor and destructor
to make it compatible with the formal declaration.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
On enabling the /analyse option the VS2017 compiler
reports: warning C6001: Using uninitialized memory.
This warning is reported as some variables that were
being logged were uninitialised. To fix this, moved
the logging code after the variables being logged are
initialised.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
On enabling the /analyse option the VS2017 compiler
reports: warning C6001: Using uninitialized memory.
This warning is reported as some variables that were
being logged were uninitialised. To fix this, moved
the logging code after the variables being logged are
initialised.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The VS2017 compiler reports 'warning C4267: 'return': conversion
from 'size_t' to 'UINT32', possible loss of data' for a number of
functions that compute the IORT node length. Similarly, it reports
warnings for IORT node length field assignments as the length
field is 16-bit wide.
This patch adds type casts at appropriate places and also implements
validations to ensure that the max width of the respective fields
is not exceeded.
This patch also fixes a typo in one of the local variable names.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Removing GT Block frame count check from AddGTBlockTimerFrames()
as this is already validated in BuildGtdtTable().
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The ARM DCC serial port subtype is an option that is
supported by the DBG2 generator. However, the serial
port initialisation should only be done for PL011/SBSA
compatible UARTs.
Add check to conditionally initialise the serial port.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The VS2017 compiler reports 'warning C4366: The result of
the unary '&' operator may be unaligned' if an address of
an unaligned structure member is passed as an argument to
a function.
Fix this warning by using local variables in place of
unaligned structure members.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The VS2017 compiler reports 'warning C4267: '=': conversion from
'size_t' to 'UINT16', possible loss of data'.
The sizeof() operator is used to calculate the size of the
GT Block structure. The length field in the GT Block structure
is 16-bit wide. Since the return type of sizeof() operator
is size_t the VS2017 compiler reports the above warning.
To fix the warning, an explicit type cast is added. An additional
check is also performed to ensure that the calculated GT Block
length does not exceed MAX_UINT16.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The length field for the Processor Hierarchy node structure is
8-bit wide while the number of private resource field is 32-bit
wide. Therefore, the GetProcHierarchyNodeSize() returns the size
as a 32-bit value.
The VS2017 compiler reports 'warning C4244: '=': conversion from
'UINT32' to 'UINT8', possible loss of data' while assigning the
length field of the Processor Hierarchy node structure.
To fix this, a type cast is added. In addition, there is a check
to ensure that the Processor Hierarchy node size does not exceed
MAX_UINT8.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The VS2017 compiler reports 'warning C4244: '=': conversion
from 'UINT16' to 'UINT8', possible loss of data' for the
SPCR InterfaceType field assignment.
The SPCR InterfaceType field uses the same encoding as that
of the DBG2 table Port Subtype field. However SPCR.InterfaceType
is 8-bit while the Port Subtype field in DBG2 table is 16-bit.
Since the Configuration Manager represents the Serial port
information using the struct CM_ARM_SERIAL_PORT_INFO, the
PortSubtype member in this struct is 16-bit.
To fix the warning an explicit type case is added. A validation
is also added to ensure that the Serial Port Subtype value
provided by the Configuration Manager is within the 8-bit
range (less than 256).
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The edk2 BaseTools report a warning if a local header file
is not listed under the [Sources] section in the INF file.
Add header files to the [Sources] section in the respective
INF files to fix the warnings.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
VS2017 reports 'warning C4028: formal parameter 2 different
from declaration' for the library constructor and destructor
interfaces for the Generator modules. VS2017 compiler also
reports similar warnings for the DXE entry points.
Remove the CONST qualifier for the SystemTable pointer (the
second parameter to the constructor/destructor/DXE Entry
point) to make it compatible with the formal declaration.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The SRAT generator uses the configuration manager protocol
to obtain the affinity information for the GICC, GIC ITS,
Memory, Generic Initiator, etc. and generates the SRAT table.
The table generator supports ACPI 6.3, SRAT table revision 3.
The ACPI and PCI device handles of the Generic Initiator
Affinity structures are represented using tokens. The
generator invokes the configuration manager protocol
interfaces and requests for objects referenced by tokens
to get the device handle information.
The Configuration Manager object definition for the GICC has
been updated to include the Proximity Domain, Clock Domain
and associated flag information. Similarly the Configuration
Manager object for the GIC ITS has been updated to include
the Proximity Domain information. These changes should not
impact any existing implementations as the new fields have
been added towards the end of the Configuration Manager
Objects.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The ACPI 6.3 specification adds support for describing
ARMv8.1 EL2 virtual timers. Update GTDT Generator
to extend this support.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The PPTT generator uses the configuration manager protocol to
obtain information about platform's processor topology and caches.
This data is then used to generate the PPTT table.
The table generator supports ACPI 6.3, PPTT table revision 2.
The dynamic PPTT generator also carries out extensive input
validation which includes cycle detection and MADT-PPTT
cross-validation. A number of architectural compliance checks
are also performed.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The Dynamic Tables Framework now supports generating Multiple APIC
Description Table (MADT) revision 5 for ARM platforms while maintaining
backward-compatibility with ACPI 6.2.
The relevant change is the enablement of the Statistical Profiling
Extension (SPE).
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Check for duplicate frame numbers when populating the GT Block Timer
Frames inside the GTDT table generator.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Check for duplicate ACPI Processor UIDs when populating the GIC CPU
(GICC) Interface structures inside the MADT table generator.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois
Sami Mujawar
Krzysztof Koch