| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously, access size values were taken as-is, instead of mapped to
ACPI defines.
This made for incorrect parsing of DWORD and QWORD access sizes.
Signed-off-by: Djordje Nedic <djordje.nedic@nextsilicon.com>
|
|
The Devicetree Specification [1] defines the "ranges" property.
"""
The ranges property provides a means of defining a mapping or
translation between the address space of the bus (the child
address space) and the address space of the bus node’s parent
(the parent address space).
"""
Add a FdtGetTranslatedReg() function, reading the "reg" property
of a node and translating the base address through the "ranges"
properties present in the node hierarchy.
Make use of FdtGetTranslatedReg() wherever relevant.
This allows to handle the presence of "ranges" property in
a node hierarchy by default.
[1] Spec. v0.4, s2.3.8 ranges
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
Add a FdtGetReg() helper to fetch the "reg" property of a node.
Use the newly introduce helper wherever relevant.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
The Devicetree Specification [1] defines the concept of interrupt
mapping, interrupt domain, interrupt nexus and interrupt controller.
An interrupt property might need to be translated through an
interrupt nexus to obtain the interrupt type, id, flags.
Add a FdtResolveInterrupt() function, resolving an interrupt property
through interrupt nexuses until reaching the interrupt-controller
node.
Make use of FdtResolveInterrupt() wherever relevant.
This allows to handle the presence of interrupt nexus
by default.
[1] Spec. v0.4, s2.4 Interrupts and Interrupt Mapping
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
Add a Size parameter to:
- FdtGetInterruptId()
- FdtGetInterruptFlags()
This allows to check the size of the interrupt data to parse
inside the later functions.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
FdtGetInterruptCellsInfo() expects to receive an interrupt
controller node. However, a common use-case is to get the
"#interrupt-cells" of a non interrupt-controller node in order
to decode an "interrupts" property.
Add a "SearchInHierarchy" parameter to
FdtGetInterruptCellsInfo() to conditionnaly relax the
function and either get the "#interrupt-cells" property:
- from the input node
- from the hierachy of the input node.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
The Devicetree Specification [1] defines the concept of interrupt
mapping, interrupt domain, interrupt nexus and interrupt controller.
The "interrupt-controller" property defines a node as an interrupt
controller. The "interrupt-map" property defines a node as an
interrupt nexus. Both node types are defined as the root of an
interrupt domain.
A GIC (Generic Interrupt Controller) is an interrupt controller. The
GIC version should be fetched to the matching device tree node. A
node defining an interrupt domain might not necessarily be an
interrupt controller and contain this information.
Introduce 2 functions:
- FdtGetIntControllerNode()
- FdtGetIntDomainNode()`
to distinguish the 2 concepts.
As the presence of interrupt nexus/domains is currently not supported,
replace FdtGetIntcParentNode() calls with FdtGetIntControllerNode().
The distinction will be useful in following patches.
Also, update the detection of an interrupt domain to the presence
of one of these properties:
- interrupt-controller
- interrupt-map
instead of relying on the presence of the #interrupt-cells property,
which is not a guarantee.
[1] Spec. v0.4, s2.4 Interrupts and Interrupt Mapping
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
The interrupt parent of a node is:
- the node pointed by the "interrupt-parent" property
if the property is present
- the direct parent otherwise.
FdtGetIntcParentNode() doesn't aim to find the next
parent node in the interrupt hierarchy. It aims to find
the interrupt-controller node upon which the input node
depends. This interrupt-controller node might be multiple
nodes up in the device tree hierarchy.
Thus, rename FdtGetIntcParentNode() to FdtGetIntcNode()
to make the function name less ambiguous and prepare for
the addition of a function which gets the next parent node
in an interrupt hierarchy.
No functional change.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
Replace traditional `#ifndef`/`#define`/`#endif` include guards with
`#pragma` once.
`#pragma once` is a widely supported preprocessor directive that
prevents header files from being included multiple times. It is
supported by all toolchains used to build edk2: GCC, Clang/LLVM, and
MSVC.
Compared to macro-based include guards, `#pragma once`:
- Eliminates the risk of macro name collisions or copy/paste errors
where two headers inadvertently use the same guard macro.
- Eliminate inconsistency in the way include guard macros are named
(e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.).
- Reduces boilerplate (three lines replaced by one).
- Avoids polluting the macro namespace with guard symbols.
- Can improve build times as the preprocessor can skip re-opening the
file entirely, rather than re-reading it to find the matching
`#endif` ("multiple-include optimization").
- Note that some compilers may already optimize traditional include
guards, by recognzining the idiomatic pattern.
This change is made acknowledging that overall portability of the
code will technically be reduced, as `#pragma once` is not part of the
C/C++ standards.
However, this is considered acceptable given:
1. edk2 already defines a subset of supported compilers in
BaseTools/Conf/tools_def.template, all of which have supported
`#pragma once` for over two decades.
2. There have been concerns raised to the project about inconsistent
include guard naming and potential macro collisions.
Approximate compiler support dates:
- MSVC: Supported since Visual C++ 4.2 (1996)
- GCC: Supported since 3.4 (2004)
(http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html)
- Clang (LLVM based): Since initial release in 2007
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
In RISC-V, the GSI space is spread across multiple PLICs/APLICs. Hence,
any device's IRQ number in the FDT should be appropriately converted to
a GSI number based on its parent interrupt controller. Do this for UART
parsing in RISC-V.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Migrate these packages to use the up-to-date BaseFdtLib instead
of the EmbeddedPkg relic that is going away.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
|
|
FdtHwInfoParserLib does not explicitly call out its dependencies on
BaseLib/BaseMemoryLib, which is currently hidden when EmbeddedPkg FdtLib
pulls them in instead. But that is going away, so make the necessary
explicit references and add missing include statements.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
To allow other architectures to potentially re-use the serial port
parser and make the code arch neutral, remove the Arm prefixes.
Suggested-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
Move Serial port info objects like the generic serial port info,
Serial console port info and Serial debug port info from Arm
Namespace to the Arch Common namespace.
i.e.
EArmObjSerialPortInfo -> EArchCommonObjSerialPortInfo
EArmObjConsolePortInfo -> EArchCommonObjConsolePortInfo
EArmObjSerialDebugPortInfo -> EArchCommonObjSerialDebugPortInfo
CM_ARM_SERIAL_PORT_INFO -> CM_ARCH_COMMON_SERIAL_PORT_INFO
Correspondingly also update the following modules to reflect the
changes introduced by the move:
- DBG2 Generator
- SPCR Generator
- SSDT Serial Port Fixup Lib
- SSDT Serial Port Generator
- FdtHwInfoParserLib/ArmSerialPortParser
- ConfigurationManagerObjectParser
- Dynamic Plat Repo TokenFixer map.
Cc: Pierre Gondois <Pierre.Gondois@arm.com>
Cc: Yeo Reum Yun <YeoReum.Yun@arm.com>
Cc: AbdulLateef Attar <AbdulLateef.Attar@amd.com>
Cc: Jeshua Smith <jeshuas@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
When scanning for the Serial Port in the device
tree, the length and value parameters to ScanMem8()
are not in the right order. This results in the
serial port not being detected if the chosen node
in the device tree has additional elements.
Therefore, pass the parameters to ScanMem8() in the
correct order to fix this issue.
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
In an effort to clean the documentation of the above
package, remove duplicated words.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
The Microsoft Debug Port Table 2 (DBG2), the Serial Port Console
Redirector (SPCR) table are mandatory tables required for booting
a standards-based operating system. The DBG2 table is used by the
OS debugger while the SPCR table is used to configure the serial
terminal. Additionally, the serial ports available on a platform
for generic use also need to be described in DSDT/SSDT for an OS
to be able to use the serial ports.
The Arm Base System Architecture 1.0 specification a lists of
supported serial port hardware for Arm Platforms. This list
includes the following serial port UARTs:
- SBSA/Generic UART
- a fully 16550 compatible UART.
Along, with these the PL011 UART is the most commonly used serial
port hardware on Arm platforms.
The serial port hardware information is described in the platform
Device Tree, the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/serial/serial.yaml
- linux/Documentation/devicetree/bindings/serial/8250.txt
- linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
- linux/Documentation/devicetree/bindings/serial/pl011.yaml
The FdtHwInfoParser implements a Serial Port Parser that parses
the platform Device Tree to create CM_ARM_SERIAL_PORT_INFO objects
with the following IDs:
- EArmObjSerialConsolePortInfo (for use by SPCR)
- EArmObjSerialDebugPortInfo (for use by DBG2)
- EArmObjSerialPortInfo (for use as generic Serial Ports)
The Serial Port for use by SPCR is selected by parsing the Device
Tree for the '/chosen' node with the 'stdout-path' property. The
next Serial Port is selected for use as the Debug Serial Port and
the remaining serial ports are used as generic serial ports.
The CM_ARM_SERIAL_PORT_INFO objects are encapsulated in Configuration
Manager descriptor objects with the respective IDs and are added to
the platform information repository.
The platform Configuration Manager can then utilise this information
when generating the DBG2, SPCR and the SSDT serial port tables.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
