| /device/linaro/bootloader/edk2/EmbeddedPkg/Drivers/FdtPlatformDxe/ |
| D | README.txt | 5 This program and the accompanying materials
6 are licensed and made available under the terms and conditions of the BSD License
7 which accompanies this distribution. The full text of the license may be found at
15 The purpose of the FdtPlatformDxe UEFI driver is to install the Flat Device
16 Tree (FDT) of the platform the UEFI frimware is running on into the UEFI
17 Configuration Table. The FDT is identified within the UEFI Configuration
18 Table by the "gFdtTableGuid" GUID defined in "EmbeddedPkg.dec".
20 Once installed, an UEFI application or OS boot loader can get from the UEFI
21 Configuration Table the FDT of the platform from the "gFdtTableGuid" GUID.
23 The installation is done after each boot at the end of the DXE phase,
[all …]
|
| /device/linaro/bootloader/arm-trusted-firmware/docs/ |
| D | trusted-board-boot.rst | 11 the platform by authenticating all firmware images up to and including the
15 This document describes the design of ARM Trusted Firmware TBB, which is an
16 implementation of the Trusted Board Boot Requirements (TBBR) specification,
17 ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
18 design document, which implements a specific aspect of the TBBR.
24 the ARM development platforms, these components are:
26 - A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
29 - The BL1 image, on the assumption that it resides in ROM so cannot be
32 The remaining components in the CoT are either certificates or boot loader
33 images. The certificates follow the `X.509 v3`_ standard. This standard
[all …]
|
| D | auth-framework.rst | 10 The aim of this document is to describe the authentication framework implemented
11 in the Trusted Firmware. This framework fulfills the following requirements:
13 #. It should be possible for a platform port to specify the Chain of Trust in
14 terms of certificate hierarchy and the mechanisms used to verify a
23 - The mechanism used to verify the transported information i.e. the
26 The framework has been designed following a modular approach illustrated in the
67 This document describes the inner details of the authentication framework and
68 the abstraction mechanisms available to specify a Chain of Trust.
73 This section describes some aspects of the framework design and the rationale
81 illustrates how this maps to a CoT for the BL31 image described in the
[all …]
|
| D | platform-migration-guide.rst | 16 three requirements that the PSCI 1.0 specification introduced :
18 - Removing the framework assumption about the structure of the MPIDR, and
19 its relation to the power topology enables support for deeper and more
22 - Reworking the power state coordination implementation in the framework
23 to support the more detailed PSCI 1.0 requirements and reduce platform
26 - Enable the use of the extended power\_state parameter and the larger StateID
29 The PSCI 1.0 implementation introduces new frameworks to fulfill the above
30 requirements. These framework changes mean that the platform porting API must
31 also be modified. This document is a guide to assist migration of the existing
32 platform ports to the new platform API.
[all …]
|
| D | interrupt-framework-design.rst | 11 allows EL3 software to configure the interrupt routing behavior. Its main
12 objective is to implement the following two requirements.
17 the interrupt to either software in EL3 or Secure-EL1 depending upon the
18 software configuration and the GIC implementation. This requirement ensures
19 that secure interrupts are under the control of the secure software with
20 respect to their delivery and handling without the possibility of
24 non-secure software (Non-secure interrupts) to the last executed exception
25 level in the normal world when the execution is in secure world at
26 exception levels lower than EL3. This could be done with or without the
28 approach should be governed by the secure software. This requirement
[all …]
|
| D | psci-pd-tree.rst | 15 #. A platform must export the ``plat_get_aff_count()`` and
16 ``plat_get_aff_state()`` APIs to enable the generic PSCI code to
17 populate a tree that describes the hierarchy of power domains in the
18 system. This approach is inflexible because a change to the topology
19 requires a change in the code.
21 It would be much simpler for the platform to describe its power domain tree
24 #. The generic PSCI code generates MPIDRs in order to populate the power domain
25 tree. It also uses an MPIDR to find a node in the tree. The assumption that
26 a platform will use exactly the same MPIDRs as generated by the generic PSCI
27 code is not scalable. The use of an MPIDR also restricts the number of
[all …]
|
| D | porting-guide.rst | 15 Please note that this document has been updated for the new platform API
16 as required by the PSCI v1.0 implementation. Please refer to the
17 `Migration Guide`_ for the previous platform API.
19 Porting the ARM Trusted Firmware to a new platform involves making some
20 mandatory and optional modifications for both the cold and warm boot paths.
24 - Setting up the execution context in a certain way, or
29 of variables and functions to fulfill the optional requirements. These
30 implementations are all weakly defined; they are provided to ease the porting
31 effort. Each platform port can override them with its own implementation if the
35 FVP and Juno) may also use `include/plat/arm/common/plat\_arm.h`_ and the
[all …]
|
| D | platform-interrupt-controller-API.rst | 9 This document lists the optional platform interrupt controller API that
10 abstracts the runtime configuration and control of interrupt controller from the
11 generic code. The mandatory APIs are described in the `porting guide`__.
23 This API should return the priority of the interrupt the PE is currently
27 In the case of ARM standard platforms using GIC, the *Running Priority Register*
28 is read to determine the priority of the interrupt.
38 The API should return whether the interrupt ID (first parameter) is categorized
41 the system.
51 The API should return whether the interrupt ID (first parameter) is categorized
64 The API should return whether the interrupt ID (first parameter) is categorized
[all …]
|
| D | rt-svc-writers-guide.rst | 15 This document describes how to add a runtime service to the EL3 Runtime
18 Software executing in the normal world and in the trusted world at exception
19 levels lower than EL3 will request runtime services using the Secure Monitor
20 Call (SMC) instruction. These requests will follow the convention described in
21 the SMC Calling Convention PDD (`SMCCC`_). The `SMCCC`_ assigns function
25 SMC Functions are grouped together based on the implementor of the service, for
26 example a subset of the Function IDs are designated as "OEM Calls" (see `SMCCC`_
27 for full details). The EL3 runtime services framework in BL31 enables the
29 into the BL31 image. This simplifies the integration of common software from
32 dispatched to their respective service implementation - the `Firmware Design`_
[all …]
|
| D | xlat-tables-lib-v2-design.rst | 11 This document describes the design of the translation tables library (version 2)
12 used by the ARM Trusted Firmware. This library provides APIs to create page
13 tables based on a description of the memory layout, as well as setting up system
14 registers related to the Memory Management Unit (MMU) and performing the
20 on a description of the memory layout. The memory layout is typically
21 provided by the platform port as a list of memory regions;
24 translation regime than the exception level the library code is executing at;
26 #. Support for dynamic mapping and unmapping of regions, even while the MMU is
30 #. Support for non-identity virtual to physical mappings to compress the virtual
39 This document focuses on version 2 of the library, whose sources are available
[all …]
|
| D | reset-design.rst | 10 This document describes the high-level design of the framework to handle CPU
11 resets in ARM Trusted Firmware. It also describes how the platform integrator
12 can tailor this code to the system configuration to some extent, resulting in a
15 This document should be used in conjunction with the `Firmware Design`_, which
16 provides greater implementation details around the reset code, specifically
17 for the cold boot path.
27 This diagram shows the default, unoptimised reset flow. Depending on the system
29 guide the platform integrator by indicating which build options exclude which
30 steps, depending on the capability of the platform.
32 Note: If BL31 is used as the Trusted Firmware entry point instead of BL1, the
[all …]
|
| D | user-guide.rst | 11 tested set of other software components using defined configurations on the Juno
14 is outside the scope of this document.
16 This document assumes that the reader has previous experience running a fully
17 bootable Linux software stack on Juno or FVP using the prebuilt binaries and
18 filesystems provided by `Linaro`_. Further information may be found in the
19 `Linaro instructions`_. It also assumes that the user understands the role of
20 the different software components required to boot a Linux system:
22 - Specific firmware images required by the platform (e.g. SCP firmware on Juno)
28 This document also assumes that the user is familiar with the `FVP models`_ and
29 the different command line options available to launch the model.
[all …]
|
| D | firmware-design.rst | 10 The ARM Trusted Firmware implements a subset of the Trusted Board Boot
12 platforms. The TBB sequence starts when the platform is powered on and runs up
13 to the stage where it hands-off control to firmware running in the normal
14 world in DRAM. This is the cold boot path.
16 The ARM Trusted Firmware also implements the Power State Coordination Interface
17 PDD [2]_ as a runtime service. PSCI is the interface from normal world software
20 runtime services via the ARM SMC (Secure Monitor Call) instruction. The SMC
21 instruction must be used as mandated by the SMC Calling Convention [3]_.
24 interrupts generated in either security state. The details of the interrupt
29 the translation tables. The details of this library can be found in
[all …]
|
| /device/linaro/bootloader/edk2/AppPkg/Applications/Python/Python-2.7.2/Lib/ |
| D | pdb.doc | 4 To use the debugger in its simplest form:
9 The debugger's prompt is '(Pdb) '. This will stop in the first
13 you can use pdb's post-mortem facility to inspect the contents of the
21 The commands recognized by the debugger are listed in the next
27 A blank line repeats the previous command literally, except for
28 'list', where it lists the next 11 lines.
30 Commands that the debugger doesn't recognize are assumed to be Python
31 statements and are executed in the context of the program being
33 point ('!'). This is a powerful way to inspect the program being
35 occurs in such a statement, the exception name is printed but the
[all …]
|
| /device/generic/goldfish-opengl/system/renderControl_enc/ |
| D | README | 2 on the android guest into a stream and get decoded and executed on the host.
3 It is used in order to query the host renderer as well as send the host renderer
6 The following describes each of the entries defined by this renderControl API.
10 This function queries the host renderer version number.
13 This function queries the host renderer for the EGL version
17 This function queries the host for EGL string (.i.e EGL_EXTENSIONS).
18 if buffer is NULL or the bufferSize is not big enough the return value
19 is the negative number of bytes required to store the string value
20 otherwise the string value is copied to buffer and its size is
24 queries the host for the number of supported EGL configs.
[all …]
|
| /device/google/bonito/json-c/ |
| D | Doxyfile | 3 # This file describes the settings to be used by the documentation system
18 # by quotes) that should identify the project.
23 # This could be handy for archiving the generated documentation or
28 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
29 # base path where the generated documentation will be put.
30 # If a relative path is entered, it will be relative to the location
31 # where doxygen was started. If left blank the current directory will be used.
35 # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
36 # 4096 sub-directories (in 2 levels) under the output directory of each output
37 # format and will distribute the generated files over these directories.
[all …]
|
| /device/google/crosshatch/json-c/ |
| D | Doxyfile | 3 # This file describes the settings to be used by the documentation system
18 # by quotes) that should identify the project.
23 # This could be handy for archiving the generated documentation or
28 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
29 # base path where the generated documentation will be put.
30 # If a relative path is entered, it will be relative to the location
31 # where doxygen was started. If left blank the current directory will be used.
35 # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
36 # 4096 sub-directories (in 2 levels) under the output directory of each output
37 # format and will distribute the generated files over these directories.
[all …]
|
| /device/linaro/bootloader/edk2/OvmfPkg/VirtioNetDxe/ |
| D | TechNotes.txt | 3 # Technical notes for the virtio-net driver.
7 # This program and the accompanying materials are licensed and made available
8 # under the terms and conditions of the BSD License which accompanies this
9 # distribution. The full text of the license may be found at
21 normative. They are made in good faith. Corrections are most welcome on the
24 The following documents have been perused while writing the driver and this
35 The VirtioNetDxe UEFI_DRIVER implements the Simple Network Protocol for
37 of it by the DXE Core / the ConnectController() boot service, enabling for
47 transitions are labeled with the primary function (and its important callees
48 faithfully indented) that implement the transition.
[all …]
|
| /device/generic/opengl-transport/host/commands/emugen/ |
| D | README | 5 API calls and encodes them into the wire and decoder code that decodes
6 the wire stream and calls server matching API.
9 for the specified API, where each entry routes the call via a dispatch
12 The following paragraphs includes the following:
18 Note: In this document, the caller is referred to as Encoder or Client
19 and the callee is referred to as the Decoder or Server. These terms
20 are used interchangeably by the context.
33 A general Decoder->Encoder reply is expected to be received in the
34 context of the ‘call’ that triggered it, thus it includes the reply
42 consider the following function call:
[all …]
|
| /device/linaro/bootloader/edk2/IntelFsp2Pkg/Tools/UserManuals/ |
| D | GenCfgOptUserManual.md | 3 the compiler, header files for the UPD regions, and generates a Boot Settings
17 1. It produces a **.txt** file that is used by the compiler that summarizes
18 the UPD section in the DSC file.
19 2. It generates header files for the UPD regions.
20 3. It generates a **Boot Settings File (BSF)** that can be used by the
22 interface for manipulating settings in the UPD regions.
26 the **'build'** command; the **GENBSF** use case may be done at any time.
28 The following sections explain the three use cases.
31 The **UPDTXT** option creates a text file with all the UPD entries, offsets,
32 size in bytes, and values. **GenCfgOpt** reads this information from the
[all …]
|
| /device/linaro/bootloader/edk2/BaseTools/ |
| D | ReadMe.txt | 1 This directory contains the next generation of EDK II build tools and template files.
2 Templates are located in the Conf directory, while the tools executables for
3 Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other
6 1. Build step to generate the binary tools.
10 To build the BaseTools, you should run the standard vsvars32.bat script
14 In addition to this, you should set the following environment variables:
16 * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree
17 * BASE_TOOLS_PATH - The directory where the BaseTools source is located.
18 (It is the same directory where this README.txt is located.)
19 * PYTHON_FREEZER_PATH - Path to where the python freezer tool is installed
[all …]
|
| /device/linaro/bootloader/edk2/ArmPlatformPkg/Documentation/ |
| D | ArmPlatformPkg.txt | 3 1. Create the new platform directory under ArmPlatformPkg
5 …m ArmVExpress-CTA9x4.dsc and ArmVExpress-CTA9x4.fdf; and adapted following the requirement of your…
7 3. Set up the PCDs required by ArmPlatformPkg in your FDF or DSC files
9 4. Implement 'ArmPlatformLib' for your platform following the interface defined by ArmPlatformPkg\I…
23 gArmPlatformTokenSpaceGuid.PcdCPUCoreSecPrimaryStackSize : Size of the stack for the Primary …
24 gArmPlatformTokenSpaceGuid.PcdCPUCoreSecSecondaryStackSize : Size of the stack for the Secondar…
26 gArmPlatformTokenSpaceGuid.PcdCPUCoreSecMonStackSize : Size of the stack for each cores
28 gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize : Size of the stack for the Primary …
29 gArmPlatformTokenSpaceGuid.PcdCPUCoreSecondaryStackSize : Size of the stack for the Secondar…
32 gArmTokenSpaceGuid.PcdGicDistributorBase : Base address of the Distributor of your General I…
[all …]
|
| /device/linaro/bootloader/edk2/StdLib/LibC/Softfloat/ |
| D | softfloat.txt | 13 the IEC/IEEE Standard for Binary Floating-Point Arithmetic. As many as four
15 precision, and quadruple precision. All operations required by the standard
18 This document gives information about the types defined and the routines
19 implemented by SoftFloat. It does not attempt to define or explain the
20 IEC/IEEE Floating-Point Standard. Details about the standard are available
30 particular, the distributed header files will not be acceptable to any
33 Support for the extended double-precision and quadruple-precision formats
34 depends on a C compiler that implements 64-bit integer arithmetic. If the
35 largest integer format supported by the C compiler is 32 bits, SoftFloat is
36 limited to only single and double precisions. When that is the case, all
[all …]
|
| /device/sample/sdk_addon/ |
| D | manifest.ini | 4 # Name and vendor of the add-on.
6 # 2 add-ons with the same identifier cannot be installed in the same SDK
7 # and only the add-on with the highest rev number will be installed.
9 # any special characters. Also, the character ':' is forbidden.
15 # version of the Android platform on which this add-on is built.
18 # revision of the add-on. This must be a strict integer.
22 # This must be the name of the libraries, as required by the
23 # <uses-library> node in the AndroidManifest.xml file.
29 # <library.name>: the name of the library defined in the property "libraries" above.
30 # <name>.jar: the jar file containing the library API. This is to be located in
[all …]
|
| /device/linaro/bootloader/arm-trusted-firmware/docs/plat/ |
| D | socionext-uniphier.rst | 4 Socionext UniPhier ARMv8-A SoCs use ARM Trusted Firmware as the secure world
9 non-volatile storage to the on-chip SRAM. Unfortunately, BL1 does not fit in
10 the 64KB limit if `Trusted Board Boot`_ (TBB) is enabled. To solve this problem,
12 in the on-chip SRAM, initializes the DRAM, expands BL1 there, and hands the
15 The UniPhier platform works with/without TBB. See below for the build process
16 of each case. The image authentication for the UniPhier platform fully
17 complies with the Trusted Board Boot Requirements (TBBR) specification.
19 The UniPhier BL does not implement the authentication functionality, that is,
20 it can not verify the BL1 image by itself. Instead, the UniPhier BL assures
21 the BL1 validity in a different way; BL1 is GZIP-compressed and appended to
[all …]
|