Remove Markdown documentation

Removed Markdown documents as they have been converted to
reStructuredText.

Change-Id: I3148222eb31258f158f64de4ddcdda4b232ce483
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

acknowledgements.md

-Contributor Acknowledgements
-============================
-
-Companies
----------
-Linaro Limited
-
-NVIDIA Corporation
-
-Socionext Inc.
-
-Xilinx, Inc.
-
-Individuals
------------

contributing.md

-Contributing to ARM Trusted Firmware
-====================================
-
-Getting Started
----------------
-
-*   Make sure you have a [GitHub account].
-*   Create an [issue] for your work if one does not already exist. This gives
-    everyone visibility of whether others are working on something similar. ARM
-    licensees may contact ARM directly via their partner managers instead if
-    they prefer.
-    *   Note that the [issue] tracker for this project is in a separate
-        [issue tracking repository]. Please follow the guidelines in that
-        repository.
-    *   If you intend to include Third Party IP in your contribution, please
-        raise a separate [issue] for this and ensure that the changes that
-        include Third Party IP are made on a separate topic branch.
-*   [Fork][] [arm-trusted-firmware][] on GitHub.
-*   Clone the fork to your own machine.
-*   Create a local topic branch based on the [arm-trusted-firmware][] `master`
-    branch.
-
-
-Making Changes
---------------
-
-*   Make commits of logical units. See these general [Git guidelines] for
-    contributing to a project.
-*   Follow the [Linux coding style]; this style is enforced for the ARM Trusted
-    Firmware project (style errors only, not warnings).
-    *   Use the checkpatch.pl script provided with the Linux source tree. A
-        Makefile target is provided for convenience (see section 2 in the
-        [User Guide]).
-*   Keep the commits on topic. If you need to fix another bug or make another
-    enhancement, please create a separate [issue] and address it on a separate
-    topic branch.
-*   Avoid long commit series. If you do have a long series, consider whether
-    some commits should be squashed together or addressed in a separate topic.
-*   Make sure your commit messages are in the proper format. If a commit fixes
-    a GitHub [issue], include a reference (e.g.
-    "fixes arm-software/tf-issues#45"); this ensures the [issue] is
-    [automatically closed] when merged into the [arm-trusted-firmware] `master`
-    branch.
-*   Where appropriate, please update the documentation.
-    *   Consider whether the [User Guide], [Porting Guide], [Firmware Design] or
-        other in-source documentation needs updating.
-    *   Ensure that each changed file has the correct copyright and license
-        information. Files that entirely consist of contributions to this
-        project should have the copyright notice and BSD-3-Clause SPDX license
-        identifier as shown in [license.md](./license.md). Files that contain
-        changes to imported Third Party IP should contain a notice as follows,
-        with the original copyright and license text retained:
-        ```
-        Portions copyright (c) [XXXX-]YYYY, ARM Limited and Contributors. All rights reserved.
-        ```
-        where XXXX is the year of first contribution (if different to YYYY) and
-        YYYY is the year of most recent contribution.
-    *   If not done previously, you may add your name or your company name to
-        the [Acknowledgements] file.
-    *   If you are submitting new files that you intend to be the technical
-        sub-maintainer for (for example, a new platform port), then also update
-        the [Maintainers] file.
-    *   For topics with multiple commits, you should make all documentation
-        changes (and nothing else) in the last commit of the series. Otherwise,
-        include the documentation changes within the single commit.
-*   Please test your changes. As a minimum, ensure UEFI boots to the shell on
-    the Foundation FVP. See [Running the software on FVP] for more information.
-
-
-Submitting Changes
-------------------
-
-*   Ensure that each commit in the series has at least one `Signed-off-by:`
-    line, using your real name and email address. The names in the
-    `Signed-off-by:` and `Author:` lines must match. If anyone else contributes
-    to the commit, they must also add their own `Signed-off-by:` line.
-    By adding this line the contributor certifies the contribution is made under
-    the terms of the [Developer Certificate of Origin (DCO)][DCO].
-*   Push your local changes to your fork of the repository.
-*   Submit a [pull request] to the [arm-trusted-firmware] `integration` branch.
-    *   The changes in the [pull request] will then undergo further review and
-        testing by the [Maintainers]. Any review comments will be made as
-        comments on the [pull request]. This may require you to do some rework.
-*   When the changes are accepted, the [Maintainers] will integrate them.
-    *   Typically, the [Maintainers] will merge the [pull request] into the
-        `integration` branch within the GitHub UI, creating a merge commit.
-    *   Please avoid creating merge commits in the [pull request] itself.
-    *   If the [pull request] is not based on a recent commit, the [Maintainers]
-        may rebase it onto the `master` branch first, or ask you to do this.
-    *   If the [pull request] cannot be automatically merged, the [Maintainers]
-        will ask you to rebase it onto the `master` branch.
-    *   After final integration testing, the [Maintainers] will push your merge
-        commit to the `master` branch. If a problem is found during integration,
-        the merge commit will be removed from the `integration` branch and the
-        [Maintainers] will ask you to create a new pull request to resolve the
-        problem.
-    *   Please do not delete your topic branch until it is safely merged into
-        the `master` branch.
-
-
-- - - - - - - - - - - - - - - - - - - - - - - - - -
-
-_Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved._
-
-
-[User Guide]:                           ./docs/user-guide.md
-[Running the software on FVP]:          ./docs/user-guide.md#8--running-the-software-on-fvp
-[Porting Guide]:                        ./docs/porting-guide.md
-[Firmware Design]:                      ./docs/firmware-design.md
-[Acknowledgements]:                     ./acknowledgements.md "Contributor acknowledgements"
-[DCO]:                                  ./dco.txt
-[Maintainers]:                          ./maintainers.md
-
-[GitHub account]:               https://github.com/signup/free
-[Fork]:                         https://help.github.com/articles/fork-a-repo
-[issue tracking repository]:    https://github.com/ARM-software/tf-issues
-[issue]:                        https://github.com/ARM-software/tf-issues/issues
-[pull request]:                 https://help.github.com/articles/using-pull-requests
-[automatically closed]:         https://help.github.com/articles/closing-issues-via-commit-messages
-[Git guidelines]:               http://git-scm.com/book/ch5-2.html
-[Linux coding style]:           https://www.kernel.org/doc/Documentation/CodingStyle
-[arm-trusted-firmware]:         https://github.com/ARM-software/arm-trusted-firmware

docs/arm-sip-service.md

-
-ARM SiP Service
-===============
-
-This document enumerates and describes the ARM SiP (Silicon Provider) services.
-
-SiP services are non-standard, platform-specific services offered by the silicon
-implementer or platform provider. They are accessed via. `SMC` ("SMC calls")
-instruction executed from Exception Levels below EL3. SMC calls for SiP
-services:
-
-* Follow [SMC Calling Convention][SMCCC];
-* Use SMC function IDs that fall in the SiP range, which are `0xc2000000` -
-  `0xc200ffff` for 64-bit calls, and `0x82000000` - `0x8200ffff` for 32-bit
-  calls.
-
-The ARM SiP implementation offers the following services:
-
-* Performance Measurement Framework (PMF)
-* Execution State Switching service
-
-Source definitions for ARM SiP service are located in the `arm_sip_svc.h` header
-file.
-
-Performance Measurement Framework (PMF)
----------------------------------------
-
-The [Performance Measurement Framework](./firmware-design.md#13--performance-measurement-framework)
-allows callers to retrieve timestamps captured at various paths in ARM Trusted
-Firmware execution. It's described in detail in [Firmware Design document][Firmware Design].
-
-Execution State Switching service
----------------------------------
-
-Execution State Switching service provides a mechanism for a non-secure lower
-Exception Level (either EL2, or NS EL1 if EL2 isn't implemented) to request to
-switch its execution state (a.k.a. Register Width), either from AArch64 to
-AArch32, or from AArch32 to AArch64, for the calling CPU. This service is only
-available when ARM Trusted Firmware is built for AArch64 (i.e. when build option
-`ARCH` is set to `aarch64`).
-
-### `ARM_SIP_SVC_EXE_STATE_SWITCH`
-
-    Arguments:
-        uint32_t Function ID
-        uint32_t PC hi
-        uint32_t PC lo
-        uint32_t Cookie hi
-        uint32_t Cookie lo
-
-    Return:
-        uint32_t
-
-The function ID parameter must be `0x82000020`. It uniquely identifies the
-Execution State Switching service being requested.
-
-The parameters _PC hi_ and _PC lo_ defines upper and lower words, respectively,
-of the entry point (physical address) at which execution should start, after
-Execution State has been switched. When calling from AArch64, _PC hi_ must be 0.
-
-When execution starts at the supplied entry point after Execution State has been
-switched, the parameters _Cookie hi_ and _Cookie lo_ are passed in CPU registers
-0 and 1, respectively. When calling from AArch64, _Cookie hi_ must be 0.
-
-This call can only be made on the primary CPU, before any secondaries were
-brought up with `CPU_ON` PSCI call. Otherwise, the call will always fail.
-
-The effect of switching execution state is as if the Exception Level were
-entered for the first time, following power on. This means CPU registers that
-have a defined reset value by the Architecture will assume that value. Other
-registers should not be expected to hold their values before the call was made.
-CPU endianness, however, is preserved from the previous execution state. Note
-that this switches the execution state of the calling CPU only. This is not a
-substitute for PSCI `SYSTEM_RESET`.
-
-The service may return the following error codes:
-
-  - `STATE_SW_E_PARAM`: If any of the parameters were deemed invalid for
-    a specific request.
-  - `STATE_SW_E_DENIED`: If the call is not successful, or when ARM Trusted
-    Firmware is built for AArch32.
-
-If the call is successful, the caller wouldn't observe the SMC returning.
-Instead, execution starts at the supplied entry point, with the CPU registers 0
-and 1 populated with the supplied _Cookie hi_ and _Cookie lo_ values,
-respectively.
-
-- - - - - - - - - - - - - - - - - - - - - - - - - -
-
-_Copyright (c) 2017, ARM Limited and Contributors. All rights reserved._
-
-[Firmware Design]: ./firmware-design.md
-[SMCCC]: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html "SMC Calling Convention PDD (ARM DEN 0028A)"

docs/cpu-specific-build-macros.md

-ARM CPU Specific Build Macros
-=============================
-
-Contents
---------
-
-1.  [Introduction](#1--introduction)
-2.  [CPU Errata Workarounds](#2--cpu-errata-workarounds)
-3.  [CPU Specific optimizations](#3--cpu-specific-optimizations)
-
-
-1.  Introduction
-----------------
-
-This document describes the various build options present in the CPU specific
-operations framework to enable errata workarounds and to enable optimizations
-for a specific CPU on a platform.
-
-2.  CPU Errata Workarounds
---------------------------
-
-ARM Trusted Firmware exports a series of build flags which control the
-errata workarounds that are applied to each CPU by the reset handler. The
-errata details can be found in the CPU specific errata documents published
-by ARM:
-
-*   [Cortex-A53 MPCore Software Developers Errata Notice][A53 Errata Notice]
-*   [Cortex-A57 MPCore Software Developers Errata Notice][A57 Errata Notice]
-
-The errata workarounds are implemented for a particular revision or a set of
-processor revisions. This is checked by the reset handler at runtime. Each
-errata workaround is identified by its `ID` as specified in the processor's
-errata notice document. The format of the define used to enable/disable the
-errata workaround is `ERRATA_<Processor name>_<ID>`, where the `Processor name`
-is for example `A57` for the `Cortex_A57` CPU.
-
-Refer to the section _CPU errata status reporting_ in [Firmware Design
-guide][Firmware Design] for information on to write errata workaround functions.
-
-All workarounds are disabled by default. The platform is responsible for
-enabling these workarounds according to its requirement by defining the
-errata workaround build flags in the platform specific makefile. In case
-these workarounds are enabled for the wrong CPU revision then the errata
-workaround is not applied. In the DEBUG build, this is indicated by
-printing a warning to the crash console.
-
-In the current implementation, a platform which has more than 1 variant
-with different revisions of a processor has no runtime mechanism available
-for it to specify which errata workarounds should be enabled or not.
-
-The value of the build flags are 0 by default, that is, disabled. Any other
-value will enable it.
-
-For Cortex-A53, following errata build flags are defined :
-
-*   `ERRATA_A53_826319`: This applies errata 826319 workaround to Cortex-A53
-     CPU. This needs to be enabled only for revision <= r0p2 of the CPU.
-
-*   `ERRATA_A53_836870`: This applies errata 836870 workaround to Cortex-A53
-     CPU. This needs to be enabled only for revision <= r0p3 of the CPU. From
-     r0p4 and onwards, this errata is enabled by default in hardware.
-
-*   `ERRATA_A53_855873`: This applies errata 855873 workaround to Cortex-A53
-     CPUs. Though the erratum is present in every revision of the CPU,
-     this workaround is only applied to CPUs from r0p3 onwards, which feature
-     a chicken bit in CPUACTLR_EL1 to enable a hardware workaround.
-     Earlier revisions of the CPU have other errata which require the same
-     workaround in software, so they should be covered anyway.
-
-For Cortex-A57, following errata build flags are defined :
-
-*   `ERRATA_A57_806969`: This applies errata 806969 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision r0p0 of the CPU.
-
-*   `ERRATA_A57_813419`: This applies errata 813419 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision r0p0 of the CPU.
-
-*   `ERRATA_A57_813420`: This applies errata 813420 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision r0p0 of the CPU.
-
-*   `ERRATA_A57_826974`: This applies errata 826974 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
-
-*   `ERRATA_A57_826977`: This applies errata 826977 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
-
-*   `ERRATA_A57_828024`: This applies errata 828024 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
-
-*   `ERRATA_A57_829520`: This applies errata 829520 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision <= r1p2 of the CPU.
-
-*   `ERRATA_A57_833471`: This applies errata 833471 workaround to Cortex-A57
-     CPU. This needs to be enabled only for revision <= r1p2 of the CPU.
-
-3.  CPU Specific optimizations
-------------------------------
-
-This section describes some of the optimizations allowed by the CPU micro
-architecture that can be enabled by the platform as desired.
-
-*    `SKIP_A57_L1_FLUSH_PWR_DWN`: This flag enables an optimization in the
-     Cortex-A57 cluster power down sequence by not flushing the Level 1 data
-     cache. The L1 data cache and the L2 unified cache are inclusive. A flush
-     of the L2 by set/way flushes any dirty lines from the L1 as well. This
-     is a known safe deviation from the Cortex-A57 TRM defined power down
-     sequence. Each Cortex-A57 based platform must make its own decision on
-     whether to use the optimization.
-
-*    `A53_DISABLE_NON_TEMPORAL_HINT`: This flag disables the cache non-temporal
-     hint. The LDNP/STNP instructions as implemented on Cortex-A53 do not behave
-     in a way most programmers expect, and will most probably result in a
-     significant speed degradation to any code that employs them. The ARMv8-A
-     architecture (see ARM DDI 0487A.h, section D3.4.3) allows cores to ignore
-     the non-temporal hint and treat LDNP/STNP as LDP/STP instead. Enabling this
-     flag enforces this behaviour. This needs to be enabled only for revisions
-     <= r0p3 of the CPU and is enabled by default.
-
-*    `A57_DISABLE_NON_TEMPORAL_HINT`: This flag has the same behaviour as
-     `A53_DISABLE_NON_TEMPORAL_HINT` but for Cortex-A57. This needs to be
-     enabled only for revisions <= r1p2 of the CPU and is enabled by default,
-     as recommended in section "4.7 Non-Temporal Loads/Stores" of the
-     [Cortex-A57 Software Optimization Guide][A57 SW Optimization Guide].
-
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-_Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved._
-
-[A57 SW Optimization Guide]: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf
-[A53 Errata Notice]:         http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/index.html
-[A57 Errata Notice]:         http://infocenter.arm.com/help/topic/com.arm.doc.epm049219/cortex_a57_mpcore_software_developers_errata_notice.pdf
-[Firmware Design]:           firmware-design.md

docs/plat/hikey.md

-
-Description
-====================
-HiKey is one of 96boards. Hisilicon Kirin6220 processor is installed on HiKey.
-
-More information are listed in [link](https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/Quickstart/README.md).
-
-
-How to build
-====================
-
-1. Code Locations
------------------
-
-  * ARM Trusted Firmware:
-    [link](https://github.com/ARM-software/arm-trusted-firmware)
-
-  * edk2:
-    [link](https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5)
-
-  * OpenPlatformPkg:
-    [link](https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4)
-
-  * l-loader:
-    [link](https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2)
-
-  * uefi-tools:
-    [link](https://github.com/96boards-hikey/uefi-tools/tree/testing/hikey960_v1)
-
-  * atf-fastboot:
-    [link](https://github.com/96boards-hikey/atf-fastboot/tree/master)
-
-
-2. Build Procedure
-------------------
-
-  * Fetch all the above repositories into local host.
-    Make all the repositories in the same ${BUILD_PATH}.
-
-  * Create the symbol link to OpenPlatformPkg in edk2.
-    ```shell
-    $cd ${BUILD_PATH}/edk2
-    $ln -sf ../OpenPlatformPkg
-    ```
-
-  * Prepare AARCH64 && AARCH32 toolchain. Prepare python.
-
-  * If your hikey hardware is built by CircuitCo, update _uefi-tools/platform.config_ first. _(optional)_
-    __Uncomment the below sentence. Otherwise, UEFI can't output messages on serial
-    console on hikey.__
-    ```shell
-    BUILDFLAGS=-DSERIAL_BASE=0xF8015000
-    ```
-    If your hikey hardware is built by LeMarker, nothing to do.
-
-  * Build it as debug mode. Create your own build script file or you could refer to __build_uefi.sh__ in l-loader git repository.
-    ```shell
-    BUILD_OPTION=DEBUG
-    export AARCH64_TOOLCHAIN=GCC5
-    export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools
-    export EDK2_DIR=${BUILD_PATH}/edk2
-    EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}
-    # Build fastboot for ARM Trust Firmware. It's used for recovery mode.
-    cd ${BUILD_PATH}/atf-fastboot
-    CROSS_COMPILE=aarch64-linux-gnu- make PLAT=hikey DEBUG=1
-    # Convert DEBUG/RELEASE to debug/release
-    FASTBOOT_BUILD_OPTION=$(echo ${BUILD_OPTION} | tr '[A-Z]' '[a-z]')
-    cd ${EDK2_DIR}
-    # Build UEFI & ARM Trust Firmware
-    ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey
-    # Generate l-loader.bin
-    cd ${BUILD_PATH}/l-loader
-    ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin
-    ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin
-    ln -sf ${BUILD_PATH}/atf-fastboot/build/hikey/${FASTBOOT_BUILD_OPTION}/bl1.bin fastboot.bin
-    python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd
-    arm-linux-gnueabihf-gcc -c -o start.o start.S
-    arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800 start.o -o loader
-    arm-linux-gnueabihf-objcopy -O binary loader temp
-    python gen_loader_hikey.py -o l-loader.bin --img_loader=temp --img_bl1=bl1.bin --img_ns_bl1u=fastboot.bin
-    ```
-
-  * Generate partition table for aosp. The eMMC capacity is either 4GB or 8GB. Just change "aosp-4g" to "linux-4g" for debian.
-    ```shell
-    $PTABLE=aosp-4g SECTOR_SIZE=512 bash -x generate_ptable.sh
-    ```
-
-
-3. Setup Console
-----------------
-
-  * Install ser2net. Use telnet as the console since UEFI fails to display Boot Manager GUI in minicom. __If you don't need Boot Manager GUI, just ignore this section.__
-    ```shell
-    $sudo apt-get install ser2net
-    ```
-
-  * Configure ser2net.
-    ```shell
-    $sudo vi /etc/ser2net.conf
-    ```
-
-    Append one line for serial-over-USB in below.
-    _#ser2net.conf_
-    ```shell
-    2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner
-    ```
-
-  * Open the console.
-    ```shell
-    $telnet localhost 2004
-    ```
-
-    And you could open the console remotely, too.
-
-
-4. Flush images in recovery mode
------------------------------
-
-  * Make sure Pin3-Pin4 on J15 are connected for recovery mode. Then power on HiKey.
-
-  * Remove the modemmanager package. This package may cause the idt tool failure.
-    ```shell
-    $sudo apt-get purge modemmanager
-    ```
-
-  * Run the command to download l-loader.bin into HiKey.
-    ```shell
-    $sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 l-loader.bin
-    ```
-
-  * Update images. All aosp or debian images could be fetched from [link](https://builds.96boards.org/).
-    ```shell
-    $sudo fastboot flash ptable prm_ptable.img
-    $sudo fastboot flash fastboot fip.bin
-    $sudo fastboot flash boot boot.img
-    $sudo fastboot flash cache cache.img
-    $sudo fastboot flash system system.img
-    $sudo  fastboot flash userdata userdata.img
-    ```
-
-
-5. Boot UEFI in normal mode
------------------------------
-
-  * Make sure Pin3-Pin4 on J15 are open for normal boot mode. Then power on HiKey.
-
-  * Reference [link](https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md)

docs/plat/nvidia-tegra.md

-Tegra SoCs - Overview
-======================
-
-* T210
--------
-
-T210 has Quad ARM® Cortex®-A57 cores in a switched configuration with a
-companion set of quad ARM Cortex-A53 cores. The Cortex-A57 and A53 cores
-support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
-including legacy ARMv7 applications. The Cortex-A57 processors each have
-48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared
-Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction
-and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache.
-
-* T132
--------
-
-Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
-fully ARMv8 architecture compatible.  Each of the two Denver cores
-implements a 7-way superscalar microarchitecture (up to 7 concurrent
-micro-ops can be executed per clock), and includes a 128KB 4-way L1
-instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2
-cache, which services both cores.
-
-Denver implements an innovative process called Dynamic Code Optimization,
-which optimizes frequently used software routines at runtime into dense,
-highly tuned microcode-equivalent routines. These are stored in a
-dedicated, 128MB main-memory-based optimization cache. After being read
-into the instruction cache, the optimized micro-ops are executed,
-re-fetched and executed from the instruction cache as long as needed and
-capacity allows.
-
-Effectively, this reduces the need to re-optimize the software routines.
-Instead of using hardware to extract the instruction-level parallelism
-(ILP) inherent in the code, Denver extracts the ILP once via software
-techniques, and then executes those routines repeatedly, thus amortizing
-the cost of ILP extraction over the many execution instances.
-
-Denver also features new low latency power-state transitions, in addition
-to extensive power-gating and dynamic voltage and clock scaling based on
-workloads.
-
-Directory structure
-====================
-
-* plat/nvidia/tegra/common - Common code for all Tegra SoCs
-* plat/nvidia/tegra/soc/txxx - Chip specific code
-
-Trusted OS dispatcher
-=====================
-Tegra supports multiple Trusted OS', Trusted Little Kernel (TLK) being one of
-them. In order to include the 'tlkd' dispatcher in the image, pass 'SPD=tlkd'
-on the command line while preparing a bl31 image. This allows other Trusted OS
-vendors to use the upstream code and include their dispatchers in the image
-without changing any makefiles.
-
-Preparing the BL31 image to run on Tegra SoCs
-===================================================
-```shell
-CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf- make PLAT=tegra \
-TARGET_SOC=<target-soc e.g. t210|t132> SPD=<dispatcher e.g. tlkd> bl31
-```
-
-Platforms wanting to use different TZDRAM_BASE, can add `TZDRAM_BASE=<value>`
-to the build command line.
-
-The Tegra platform code expects a pointer to the following platform specific
-structure via 'x1' register from the BL2 layer which is used by the
-bl31_early_platform_setup() handler to extract the TZDRAM carveout base and
-size for loading the Trusted OS and the UART port ID to be used. The Tegra
-memory controller driver programs this base/size in order to restrict NS
-accesses.
-
-typedef struct plat_params_from_bl2 {
-	/* TZ memory size */
-	uint64_t tzdram_size;
-	/* TZ memory base */
-	uint64_t tzdram_base;
-	/* UART port ID */
-	int uart_id;
-} plat_params_from_bl2_t;
-
-Power Management
-================
-The PSCI implementation expects each platform to expose the 'power state'
-parameter to be used during the 'SYSTEM SUSPEND' call. The state-id field
-is implementation defined on Tegra SoCs and is preferably defined by
-tegra_def.h.
-
-Tegra configs
-=============
-
-* 'tegra_enable_l2_ecc_parity_prot': This flag enables the L2 ECC and Parity
-   Protection bit, for ARM Cortex-A57 CPUs, during CPU boot. This flag will
-   be enabled by Tegrs SoCs during 'Cluster power up' or 'System Suspend' exit.